Salesforce-Platform-Identity-and-Access-Management-Architect Practice Test Questions

Explanation:

In Salesforce OAuth architecture, scopes are used to define and restrict the level of access a connected app has to Salesforce resources. When Universal Containers builds a custom mobile app and wants to limit what data or functionality mobile users can access, scopes are the key feature to implement.

✅ What scopes do:
Control which APIs and data sets the app can access
Limit access to specific objects, permissions, or identity features
Prevent overexposure of sensitive data by enforcing least privilege
For example:
api → Grants access to the REST API
refresh_token → Allows the app to obtain new access tokens
openid → Enables OpenID Connect identity features
custom_permissions → Restricts access based on custom permission sets

📚 Reference:
Salesforce Help – OAuth Scopes

❌ Why the other options are incorrect:
A. Access Tokens
These are the result of an OAuth flow, not a mechanism for restricting access. They carry the scopes but don’t define them.
B. Mobile Pins
Related to mobile security policies, not OAuth. Used for enforcing device-level security, not API access control.
C. Refresh Tokens
Allow apps to renew access tokens without re-authentication. They extend session duration but don’t restrict access types.

Explanation:

JWT Bearer Token Flow: This OAuth 2.0 flow is designed specifically for server-to-server integrations where end-user interaction isn't required after initial setup.
Seamless Integration: The flow is seamless for the end user because the desktop application (the client) authenticates itself using a JSON Web Token (JWT) that has been signed with a digital certificate. This avoids repeated login prompts for the user and allows the integration to happen automatically in the background.
Security: A digital certificate, uploaded to the connected app in Salesforce, is used to establish a secure, trusted relationship. Salesforce validates the digital signature on the JWT before granting an access token, ensuring that the request is legitimate.

Explanation of the Incorrect Answers
B. Web Server Authentication Flow: This flow requires user interaction via a web browser to grant an authorization code. This is not "seamless" for a desktop application that primarily works offline, as it would force the user to log in through a browser repeatedly.
C. User Agent Flow: This flow is not suitable for desktop applications because it is less secure. It's designed for clients (like single-page applications) that cannot protect their client secret and receive access tokens via a URL redirect in the user's browser. This is not appropriate for a desktop application that needs to securely create leads in the background.
D. Username and Password Flow: This flow is a legacy option that Salesforce strongly advises against for security reasons, especially in production environments. It requires the application to store and transmit a user's plain-text credentials, making them vulnerable to interception.

Explanation

Why these:
A. Key logging attacks — Even if a keystroke logger steals the password, the attacker still lacks the second factor.
C. Phishing attacks — 2FA adds a barrier when credentials are phished; the attacker also needs the one-time code or possession factor. (Not perfect, but it meaningfully reduces risk; phishing-resistant methods like FIDO/WebAuthn are strongest.)
D. Dictionary attacks — Guessing passwords alone isn’t enough; the attacker must also pass the second factor, which typically stops automated password-guess attempts from succeeding.

Why not these:
B. Network perimeter attacks — Firewalls, segmentation, and patching address these; 2FA doesn’t meaningfully protect network infrastructure itself.
E. Man-in-the-middle attacks — Some OTP-based 2FA can be intercepted or relayed by an active MITM; only phishing-resistant, cryptographic methods (e.g., FIDO2/WebAuthn with origin binding) offer strong MITM protection.

Explanation:

Universal Containers (UC) wants to enable Single Sign-On (SSO) between their existing Active Directory (AD) infrastructure and Salesforce, with user management centralized in AD. They aim to avoid manual user setup in Salesforce, including the assignment of profiles, roles, and groups. This requires a solution that provisions users from AD to Salesforce automatically, including their attributes, and supports SSO. The two optimal solutions are Identity Connect and an AppExchange product designed for AD-Salesforce synchronization. Below, we analyze why B and D are correct and why A and C are not optimal.

B. Use an AppExchange product to sync users from Active Directory to Salesforce. (Correct)
Why Optimal: AppExchange offers third-party tools (e.g., Okta, OneLogin, or Ping Identity’s Salesforce connectors) that provide robust, out-of-the-box solutions for syncing users from AD to Salesforce and enabling SSO. These tools:
Automate user provisioning and deprovisioning by syncing AD user attributes (e.g., username, email, group memberships) to Salesforce User records, including profiles, roles, and permission sets.
Support Just-In-Time (JIT) provisioning, where users are created or updated in Salesforce during their first SSO login, based on AD attributes (e.g., mapping AD groups to Salesforce profiles or roles).
Enable SSO via SAML or OpenID Connect, integrating seamlessly with AD through protocols like LDAP or Kerberos.
Offer prebuilt connectors, reducing setup complexity compared to custom development, and provide additional features like MFA, user lifecycle management, and reporting.
Fit for Scenario: An AppExchange product is ideal for UC because it minimizes custom coding, supports automatic user provisioning (avoiding manual setup), and maps AD groups to Salesforce roles/profiles. It’s a scalable, enterprise-grade solution that aligns with IT’s preference to manage users in AD.
Implementation: Install an AppExchange product (e.g., Okta for Salesforce), configure the AD connector to sync user data, map attributes (e.g., AD group to Salesforce profile), and set up SAML-based SSO. Test in a sandbox to ensure proper user creation and role assignment.
Reference: Salesforce AppExchange: Identity Management Solutions; Salesforce Help: External Identity Solutions.

D. Use Identity Connect to sync users from Active Directory to Salesforce. (Correct)
Why Optimal: Salesforce Identity Connect is a purpose-built tool for integrating Salesforce with Microsoft Active Directory to enable SSO and user provisioning. It:
Synchronizes user data from AD to Salesforce, creating or updating User records based on AD attributes (e.g., email, name, group memberships).
Supports automatic mapping of AD groups to Salesforce profiles, roles, or permission sets, meeting UC’s requirement to avoid manual setup of these attributes.
Enables SSO using SAML, allowing users to authenticate via AD credentials and access Salesforce seamlessly.
Provides bidirectional sync (e.g., updating AD when Salesforce attributes change) and supports real-time or scheduled provisioning.
Fit for Scenario: Identity Connect is tailored for AD-Salesforce integration, making it an optimal choice for UC’s IT team to manage users centrally in AD while automating Salesforce user provisioning and SSO. It’s a Salesforce-native solution, ensuring tight integration and support.
Implementation: Install Identity Connect on a server with AD access, configure LDAP mappings to Salesforce User fields, set up group-to-profile/role mappings, and enable SAML SSO. Test user creation and updates in a sandbox.
Reference: Salesforce Help: Identity Connect Overview; Identity Connect Setup.

A. Use the Salesforce REST API to sync users from Active Directory to Salesforce. (Incorrect)
Why Not Optimal: While the Salesforce REST API can be used to create and update User records programmatically (e.g., syncing AD users to Salesforce), it requires custom development to:
Integrate with AD (e.g., via LDAP queries or an AD connector).
Map AD attributes to Salesforce fields (e.g., profiles, roles).
Handle ongoing synchronization, error handling, and security (e.g., OAuth or API authentication).
This approach is time-consuming, error-prone, and requires ongoing maintenance compared to prebuilt solutions like Identity Connect or AppExchange products. It doesn’t align with UC’s goal of avoiding manual setup, as custom code still requires significant configuration and testing.
Clarification: The REST API is better suited for one-off integrations or scenarios where no commercial tools are available, not for enterprise-grade AD-Salesforce sync with SSO.
Reference: Salesforce Developer: REST API User Management.

C. Use Active Directory Federation Services to sync users from Active Directory to Salesforce. (Incorrect)
Why Not Optimal: Active Directory Federation Services (ADFS) is primarily a SAML-based identity provider for SSO, allowing users to authenticate to Salesforce using AD credentials.
However, ADFS does not natively handle user provisioning (e.g., creating or updating Salesforce User records with profiles and roles). While ADFS supports JIT provisioning with SAML assertions to create users on login, it requires additional configuration (e.g., custom attribute mappings) and may not fully automate role/group assignments as seamlessly as Identity Connect or AppExchange products. ADFS focuses on authentication, not full user lifecycle management.
Clarification: ADFS could be part of the SSO solution but doesn’t fully meet UC’s provisioning requirements without additional tools or custom logic.
Reference: Salesforce Help: ADFS for SSO.

Additional Notes

Implementation Steps:
For Identity Connect (D):
Install Identity Connect on a server with AD access.
Configure LDAP queries to pull user data and group memberships.
Map AD attributes to Salesforce fields (e.g., sAMAccountName to Username, AD group to ProfileId or RoleId).
Enable SAML SSO and test user sync and login in a sandbox.

For AppExchange Product (B):
Choose a product like Okta or Ping Identity from AppExchange.
Install and configure the AD connector to sync users and groups.
Set up SAML or OpenID Connect for SSO and JIT provisioning.
Test attribute mappings (e.g., AD group to Salesforce role) and user creation.
SSO Setup: For both solutions, configure Salesforce as the Service Provider (SP) with My Domain enabled and set up SAML SSO settings to trust the AD-based IdP (e.g., ADFS or the AppExchange tool’s IdP).

Architectural Considerations:
Both solutions support JIT provisioning, creating users on first login if real-time sync isn’t needed.
Ensure AD group structures align with Salesforce profiles/roles for accurate mapping.
Monitor sync performance and API limits (for AppExchange tools using Salesforce APIs).

Security Considerations:
Enable MFA for SSO users to enhance security (supported by both solutions).
Use secure LDAP (LDAPS) for AD communication and HTTPS for SAML.
Validate attribute mappings to prevent duplicate users or incorrect role assignments.
Trailhead Reference: Trailhead: Identity Management Basics; External Identity for Provisioning.

Explanation:

To allow Salesforce profiles to be managed from a central system of record, the architect should recommend to implement JIT provisioning on the SAML IDP that will pass the profile ID in each assertion. JIT provisioning is a process that creates or updates user accounts on Salesforce based on information sent by an external identity provider (IDP) during SAML authentication. By passing the profile ID in each assertion, the IDP can control which profile is assigned to each user.

Option B is not a good choice because creating an Apex scheduled job in one org that will synchronize the other orgs profile may not be scalable, reliable, or secure.

Option C is not a good choice because implementing Delegated Authentication that will update the user profiles as necessary may not be feasible, as Delegated Authentication only verifies the user’s credentials against an external service, but does not pass any other information to Salesforce.

Option D is not a good choice because implementing an OAuth JWT flow to pass the profile credentials between systems may not be suitable, as OAuth JWTflow is used for server-to-server integration, not for user authentication.

References: Authorize Apps with OAuth, [Identity Management Concepts], [User Authentication]

Explanation:

When using a social authentication provider (like Facebook) with Salesforce, the process of creating and updating the corresponding Salesforce user is handled by an Apex class called a Registration Handler. This class implements the Auth.RegistrationHandler interface, which contains two key methods:

createUser(): Called when a user logs in for the first time to create their Salesforce user record.
updateUser(): Called on every subsequent login after the first.

The updateUser() method is the mechanism designed specifically for this requirement. It receives two parameters:

userId: The ID of the existing Salesforce user.
provderData: An object containing the latest user profile information (e.g., first name, last name, email, location) fetched from the identity provider (Facebook) during the current login.

Therefore, by implementing logic within the updateUser() method of the custom Registration Handler, Universal Containers can compare the incoming data from Facebook with the existing data on the Salesforce User record and update the record accordingly. This ensures that any changes made on Facebook are reflected in Salesforce the next time the user logs in.

Why the other options are incorrect:
A. Use SAML Just-In-Time Provisioning between Facebook and Salesforce. This is incorrect because social sign-on with providers like Facebook uses the OpenID Connect (OIDC) protocol, not SAML. While the concept of JIT provisioning applies, it is implemented through the Registration Handler in the OIDC flow, not through a SAML configuration.
B. Use information in the Signed Request that is received from Facebook. A "Signed Request" is a specific concept related to Facebook Canvas apps or pages embedded within Facebook. It is not the standard mechanism for passing user profile data during a standalone OIDC-based login flow to an external site like a Salesforce Community. The standard mechanism is the providerData object passed to the Registration Handler.
C. Develop a scheduled job that calls out to Facebook on a nightly basis. This is a poor solution for several reasons. It is inefficient (polling for changes for all users daily, even if they haven't logged in), complex (requiring to store Facebook access tokens securely), and not real-time. The updateUser() method is a event-driven, real-time solution that updates data only when a user actually authenticates, which is the optimal and intended approach.

Reference
Salesforce Help: Create a Registration Handler Class - This documentation explicitly describes the purpose of the updateUser method: "This method is called each time a user logs in. You can add logic to this method to update the user’s record in Salesforce when attributes, such as email or last name, change in the external system."

In summary,
the built-in, event-driven way to keep user data synchronized upon login is by implementing the logic within the updateUser() method of the custom Registration Handler class.

Explanation:

When you want to grant an external application the ability to act on behalf of a user to access Salesforce's standard UI, the web scope is the most appropriate choice.
Accessing the UI:
The problem states that users should be "redirected to salesforce, authenticated, and presented with relevant pages." This implies that the application isn't just making API calls in the background; it's facilitating a user's browser-based session within Salesforce.
The purpose of web:
The web scope specifically enables the use of the access token on the web, which allows the application to directly log in and redirect the user to a Salesforce session. It's designed for use in web applications that interact with Salesforce's user interface. It also implicitly includes the visualforce scope, allowing access to custom Visualforce pages.
The "Frontdoor" URL:
After the OAuth flow completes, the access token can be used to construct a special "Frontdoor" URL. This URL, when visited by the user's browser, automatically logs the user in and redirects them to the desired page within Salesforce, such as the "Ideas" page.

Why the other options are incorrect:

B. Full:
This scope grants the client application full access to all data and functionality that the authenticated user can access. While it would work, it violates the principle of least privilege. The application only needs to launch a web session, so granting full access is unnecessary and a security risk.
C. API:
The api scope grants access to the standard Salesforce REST and SOAP APIs. This allows an application to make data-related calls (e.g., creating a lead or a case) in the background. It does not, however, grant the ability to launch a user-facing web session in Salesforce.
D. Visualforce:
This scope is a subset of the web scope and only allows access to customer-created Visualforce pages. It would not enable the application to launch a session to a standard Salesforce page like "Ideas."

Explanation:

The key deciding factor between SAML and OpenID Connect (OIDC) is the type of interaction required after authentication:

✅ OpenID Connect (OIDC):
Built on OAuth 2.0, which supports access tokens and refresh tokens
Enables the Service Provider (SP) to make API calls on behalf of the user
Ideal for modern web and mobile applications that need both authentication and delegated authorization

❌ SAML:
Designed for authentication only
Does not support API access or token-based authorization
Best suited for SSO into web applications where no further API interaction is needed
So, if the SP needs to call Salesforce APIs after login, OIDC is the correct choice because it provides the necessary tokens and scopes.

📚 Reference:
Salesforce Help – OpenID Connect
Salesforce Help – SAML Overview

❌ Why the other options are incorrect:

A. OIDC is more secure than SAML
Security depends on implementation. Both protocols are secure when properly configured.
C. Session reuse in Salesforce
Both SAML and OIDC can support SSO and session reuse. This is not a deciding factor.
D. They are equivalent protocols
They serve different purposes: SAML for authentication, OIDC for authentication plus authorization.

Explanation:

A is correct because requiring users to provide their RSA token along with their credentials is a form of two factor authentication. An RSA token is a hardware device that generates a one-time password (OTP) that changes every few seconds. The user needs to enter both their password and the OTP to log in to Salesforce.

D is correct because requiring users to use a biometric reader as well as their password is another form oftwo￾factor authentication. A biometric reader is a device that scans a user’s fingerprint, face, iris, or other physical characteristics to verify their identity. The user needs to provide both their password and their biometric data to log in to Salesforce.

B is incorrect because requiring users to supply their email and phone number, which gets validated, is not a form of two-factor authentication. This is a form of identity verification, which is used to confirm that the user owns the email and phone number they provided. However, this does not add an extra layer of protection beyond their password when they log in to Salesforce.

C is incorrect because requiring users to enter a second password after the first authentication is not a form of two-factor authentication. This is a form of single-factor authentication, which only relies on something the user knows (their passwords). This does not increase security against unauthorized account access.

References:
4: Multi-Factor Authentication - Salesforce
5: Salesforce Multi-Factor Authentication
6: Two Factor Authentication - Salesforce India
7: Customer 360 | Increase Productivity - Salesforce UK
8: Secure Salesforce Login Using Two-Factor Authentication and Salesforce …

Explanation:

Why:
UC will use Salesforce as the enterprise IdP while continuing to keep employees in Active Directory. To make this work at scale:
Employees who don’t need CRM data but do need SSO to cloud apps (Workday, SAP HANA, etc.) should have the Salesforce Identity (Identity Only) user license.
Employees who do need Salesforce functionality should have a Salesforce user license.
In both cases, because the source of truth is AD, you use Identity Connect (its license/entitlement) to synchronize AD users and attributes into Salesforce, so they can authenticate via Salesforce and launch third-party apps with SSO.

Eliminate the others
A. Company Community + Identity — Company Community (legacy/internal community) isn’t the right fit for enterprise IdP and SSO to third-party apps.
C. Chatter Only + Identity — Chatter Only is a collaboration-limited license; it’s not the standard path for enterprise IdP + SSO and doesn’t replace Identity Connect for AD sync.