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

Explanation:

Why:
Experience Cloud supports dynamic branding via the experience ID (expid) URL parameter. You can include expid in the promotional links sent by marketing; when users click those links, the site renders the matching branding set (new sportswear brand). If a user lands without an expid, they’ll see your default NTO-branded experience. This requires no new licenses—just configuration and light development to read expid and route/brand accordingly.

Why not the others:
A. Full sandbox clone — Doesn’t solve dynamic, per-link branding in production; it’s just an environment.
C. Heroku brand site — Overkill and adds extra hosting/maintenance; you already have Experience Cloud and identities.
D. Additional community site — Possible, but heavier setup, more URLs, and unnecessary when dynamic branding on the same site achieves the goal quickly.

Helpful implementation notes:
Create/adjust Branding Sets in Experience Builder; map each to an expid.
If using a custom login/landing page, read the expid query param and apply the right branding (Salesforce provides controller examples).
You can also pass expid through auth provider flows if SSO is involved.

Explanation:

Northern Trail Outfitters (NTO) uses Active Directory (AD) groups (CRM_SuperUser, CRM_Reporting_SuperUser) to manage permissions, which need to map to Salesforce permission sets (SuperUser, Reporting_SuperUser) during SAML-based SSO, with Salesforce as the Service Provider (SP). The best approach is to use an Apex Just-in-Time (JIT) handler to process custom SAML attributes containing AD group memberships and assign the corresponding permission sets.

Why B:
A custom Apex JIT handler (Auth.SamlJitHandler) can parse custom SAML attributes (e.g., groups=CRM_SuperUser,CRM_Reporting_SuperUser) sent by the IdP and assign permission sets dynamically during SSO login. This ensures AD groups are accurately reflected in Salesforce without manual setup.

Why Not A:
Standard SAML attributes (e.g., NameID, email) don’t include AD group memberships, which are custom attributes, so this approach fails to meet the requirement.
Why Not C or D:
Login Flows are for post-login actions (e.g., redirects, MFA) and cannot directly process SAML attributes or handle provisioning like JIT handlers. Standard attributes (D) also don’t include group data.

Implementation:
Configure the IdP to send custom groups attributes in the SAML assertion, enable JIT in Salesforce’s SAML settings, and use an Apex handler to map groups to permission sets.

Reference:
Salesforce Help: Just-in-Time Provisioning for SAML.

Explanation:

To understand the roles, let's trace the user's login journey:
The user wants to access a third-party application (e.g., Workday).
The third-party application (the Service Provider - SP) redirects the user to its configured Identity Provider (IdP) for authentication. In this case, the configured IdP is Salesforce Identity.
The user arrives at Salesforce. However, Universal Containers uses an enterprise SSO solution (like Okta or Azure AD) as its master identity source.
Therefore, Salesforce (acting as an IdP for the third-party app) must now itself become a Service Provider (SP) and redirect the user to the enterprise SSO system (which is the true Identity Provider - IdP in this chain).
The user authenticates with the enterprise SSO.
After successful authentication, the enterprise SSO sends a SAML assertion back to Salesforce.
Salesforce validates the assertion, creates a session, and then provides its own SAML assertion back to the original third-party application.
The user is logged into the third-party app.

In the specific relationship between Salesforce and the enterprise SSO system, Salesforce is the entity consuming the authentication service. Therefore, in this relationship:
Salesforce Identity acts as the Service Provider (SP).
The Enterprise SSO System acts as the Identity Provider (IdP).
This pattern is known as Identity Brokering or IdP Chaining. Salesforce is brokering the authentication request from the third-party app to the enterprise IdP.

Why the other options are incorrect:
A. Identity Provider (IdP): Salesforce acts as an IdP, but in its relationship with the third-party application, not with the enterprise SSO system. The question specifically asks for the role "in its relationship with the enterprise SSO system."
B. Resource Server: This is an OAuth 2.0 term for an API server that protects its resources using OAuth tokens. It is not relevant to this SAML-based SSO flow.
D. Client Application: A client application is typically a web or mobile app that uses OAuth to gain access to a resource server. This is not the role Salesforce is playing in this SAML federation scenario.

Reference
Salesforce Architect: Identity and Access Management Specialist Guide - Diagrams and explains the concept of identity brokering, where Salesforce can act as a Service Provider to a corporate IdP while also acting as an Identity Provider to downstream applications.

In summary,
when integrating with an enterprise SSO system, Salesforce acts as the Service Provider (SP).

Explanation:

Why these are correct?

B. UC will be required to develop and support a custom SOAP web service.
Delegated Authentication (DA) works by having Salesforce call your authentication endpoint. Salesforce’s guidance is to “wrap your authentication method in a web service that Salesforce can consume” (implemented via SOAP for DA), which you must build, host, and maintain.
C. Salesforce users will be locked out of Salesforce if the web service goes down.
If DA is the sole login path and your DA endpoint is unavailable, Salesforce can’t validate credentials—users with DA enforced can’t log in. This is why it’s common to exclude at least a break-glass admin from DA so they can still log in if SSO/DA is down.

Why the others are not correct
A. Delegated Authentication is enabled or disabled for the entire Salesforce org.
You enable the DA feature at the org level, but whether a user is actually forced to use DA is controlled per user (profile/permission set) via the “Is Single Sign-On Enabled” permission. So it isn’t an all-or-nothing user impact.
D. The web service must reside on a public cloud service, such as Heroku.
There’s no such hosting requirement. Salesforce only requires that it can reach your DA web service; it can be hosted on-prem or in any cloud. The setup docs simply say to provide a web service endpoint—no mandate for Heroku or any specific provider.

References:
Salesforce Help: Delegated Authentication overview & setup (“wrap your authentication method in a web service…”, user-level control via permissions).
Ping Identity support example of DA outage error (“Your company’s authentication service is currently down”).
Salesforce StackExchange best practice to keep an admin able to log in if SSO/DA is down.

Explanation:

Why it’s correct:
The JWT (JSON Web Token) Bearer Token flow is designed for server-to-server integrations where one system (the legacy system) authenticates to Salesforce without requiring user interaction or storing sensitive credentials like usernames, passwords, client secrets, or refresh tokens. In this flow:
The legacy system generates a JWT signed with a private key (from a certificate uploaded to Salesforce).
The JWT is sent to Salesforce’s OAuth token endpoint, which verifies the token using the corresponding public key.
Salesforce issues an access token for API calls without needing to store credentials or refresh tokens, as the JWT can be generated on-demand using the certificate.
This flow is stateless on the client side (no need to store refresh tokens), and the client secret is not required if the connected app is configured appropriately.
Why it fits the requirements:
The JWT Bearer Token flow avoids storing credentials (username/password), client secrets, or refresh tokens, as authentication relies on the certificate-based JWT. It’s ideal for real-time, automated updates from the legacy system to Salesforce. Reference: Salesforce documentation on the JWT Bearer Token flow states: “This flow is useful for integrations that need to access Salesforce without user interaction… no user credentials or client secret are sent in the request” (Salesforce Help: OAuth 2.0 JWT Bearer Token Flow).

Option A: Web Server flow
Why it’s incorrect: The Web Server flow (also known as the Authorization Code flow) is designed for web applications where a user is involved in the authentication process. It requires:
A user to log in via a browser to authorize the application.
The client application to store a client secret to exchange an authorization code for an access token and refresh token.
Storage of the refresh token for ongoing access.
This flow involves user interaction and storage of a client secret and refresh token, which violates UC’s requirement to avoid storing such data. It’s unsuitable for server-to-server, real-time integration without user involvement.

Option C: Username-Password flow
Why it’s incorrect: The Username-Password flow requires the client application (the legacy system) to send a username and password (and optionally a client secret) to Salesforce’s OAuth token endpoint to obtain an access token. This flow:
Explicitly requires storing user credentials, which UC wants to avoid.
Is less secure and not recommended for server-to-server integrations, as it involves hardcoding or storing sensitive credentials.
May also involve storing refresh tokens for ongoing access, further violating the requirements.

Option D: User Agent flow
Why it’s incorrect: The User Agent flow (also known as the Implicit flow) is designed for client-side applications (e.g., single-page web apps or mobile apps) running in a user’s browser. It requires:
User interaction to authenticate via a browser, redirecting to Salesforce’s login page.
No client secret is used, but an access token is returned directly, which the client must handle.
This flow is unsuitable for server-to-server integration, as it requires user interaction and is not designed for automated, real-time updates from a legacy system. While it avoids storing a client secret, it still involves managing access tokens and doesn’t meet the server-to-server requirement.

Summary:
The JWT Bearer Token flow (B) is the best choice for UC’s use case. It enables the legacy system to authenticate to Salesforce for real-time order status updates without storing credentials, client secrets, or refresh tokens. The flow uses a certificate-based JWT for secure, stateless authentication, aligning perfectly with the requirements.

Explanation:

The question is about controlling the authorization level—specifically, the "types of resources" and the actions a mobile app can perform—after a user has authenticated. In the OAuth 2.0 framework, this is the precise purpose of scopes.

Why D is correct (Scopes):
Scopes are parameters that define the granular permissions being requested by the application. During the OAuth authorization process, the custom mobile app will request specific scopes. The user (or an admin, depending on the policy) must grant these permissions. Salesforce then issues an access token that is limited to the granted scopes.
Examples:
A scope of api allows access to the REST API, refresh_token allows the app to get a new access token, wave allows access to Einstein Analytics, and full provides full access. By requesting only the necessary scopes (e.g., api and refresh_token), you inherently restrict the app from accessing resources outside those permissions.

Why A is incorrect (Access Tokens):
An access token is the result of a successful OAuth flow. It is the key that the app uses to access resources, but it is not the mechanism used to define or restrict what those resources are. The restrictions are determined by the scopes that were granted when the token was issued.
Why B is incorrect (Mobile pins):
Mobile Pins are a feature related to Two-Factor Authentication (2FA) in the Salesforce mobile app. They are used to verify a user's identity and have nothing to do with OAuth or restricting API resource access for a custom application.
Why C is incorrect (Refresh Tokens):
A refresh token is a credential used to obtain a new access token when the current one expires. It is a mechanism for maintaining long-lived sessions but does not control or define the permissions of the application. The new access token obtained via a refresh token will have the same scopes as the original one.

Reference:
Salesforce Help - OAuth 2.0 Scopes and Supported Flows
This documentation lists the available OAuth scopes in Salesforce and explains that they "specify what data the connected app can access." This directly aligns with the goal of restricting the types of resources mobile users can access.

Explanation:

When an architect decides to use self-signed certificates for a system-to-system integration, they must understand the key difference between these and certificates issued by a trusted Certificate Authority (CA). A certificate from a trusted CA is already included in the truststore of most operating systems and browsers, which means the trusting party automatically trusts the certificate.

However, a self-signed certificate has no external verification. The entity creating the certificate is both the issuer and the subject. Therefore, the trusting party (e.g., a Salesforce org, an application server, etc.) must manually obtain and install a copy of this specific self-signed certificate into its own truststore so it knows to trust it.

This manual process introduces significant maintenance overhead:
Initial Setup: The architect must ensure that the certificate is securely transferred and correctly installed on every system that needs to trust the service.
Expiration Management: Unlike CA-issued certificates that have a clear lifecycle, self-signed certificates require the administrator to manually track their expiration and ensure they are replaced and re-distributed before they expire.
Scale and Distribution: In a large or distributed environment, this manual process becomes unmanageable and error-prone, making it a poor choice for large-scale deployments.

Why Other Options Are Incorrect ❌
A. Use of self-signed certificate leads to lower maintenance for trusted party because multiple self-signed certs need to be maintained. This is incorrect. The trusted party (the one issuing the self-signed cert) still has to manage the certificates and ensure they are updated. The fact that multiple certificates might be needed for different trusting parties can increase, not lower, maintenance.
B. Use of self-signed certificate leads to higher maintenance for trusted party because they have to act as the trusted CA. While the trusted party technically acts as its own CA by signing the certificate, this doesn't inherently lead to higher maintenance in the same way it does for the trusting party. The trusting party bears the burden of manual trust management on their end.
C. Use of self-signed certificate leads to lower maintenance for trusting party because there is no trusted CA cert to maintain. This is the opposite of the truth. The trusting party has to perform a manual maintenance task (adding the certificate to its truststore) that it would not have to do if the certificate was signed by a publicly trusted CA.

Explanation:

A. Use the Salesforce Authenticator mobile app with two-step verification:
This is the most effective solution for combating phishing scams. Phishing attacks typically trick users into giving up their username and password. Multi-factor authentication (MFA), which is what two-step verification provides, adds a second layer of security that the attacker cannot easily steal. Even if a user provides their password on a fraudulent site, the attacker cannot log in without also having the user's mobile device to approve the login request. The Salesforce Authenticator app is a Salesforce-native solution for this.

Why the Other Options are Incorrect
B. Lock sessions to the IP address from which they originated:
While a good security practice, this is an insufficient defense against phishing. An attacker can still gain access to the user's password. This control prevents session hijacking after a user has successfully logged in, but it does not prevent a successful phishing attempt from the user's legitimate IP address or a compromised device on the same network. It also doesn't prevent a fraudulent login from a different location if the attacker has the user's credentials.
C. Increase Password complexity requirements in Salesforce:
This is a standard security practice that makes passwords harder to guess or crack. However, it does not stop a phishing attack. Phishing relies on social engineering to get the user to voluntarily type their complex password into a malicious website. Once the password is stolen, its complexity becomes irrelevant.
D. Implement Single Sign-on using a corporate Identity store:
Implementing SSO centralizes authentication and can improve security by allowing an organization to enforce stronger policies (like MFA) at the identity provider level. However, if the identity provider itself is not protected by MFA, it remains vulnerable to phishing. Phishing attacks can target the SSO login page just as easily as the Salesforce login page. Therefore, SSO alone is not the direct solution to the phishing problem; it's a mechanism that can enable a solution like MFA.

References:
Salesforce Multi-Factor Authentication (MFA): Salesforce highly recommends and, in many cases, requires MFA to be enabled for all users. The Salesforce help documentation and Trailhead modules on identity and access management explicitly state that MFA is a critical defense against phishing, credential stuffing, and account takeovers.
Salesforce Security Best Practices: The Salesforce Security site and various blog posts consistently highlight the importance of MFA as the most effective control for protecting against threats that rely on compromised credentials.

Explanation:

A. Refresh Token is valid until revoked
This setting allows long-lived refresh tokens, meaning users don’t need to re-authenticate frequently. It reduces login friction and minimizes administrative overhead by avoiding repeated token renewal processes. Especially useful for mobile apps where persistent sessions are preferred.
C. All users may self-authorize
This enables users to authorize the Connected App without admin intervention, streamlining deployment across large user bases — including internal users and Community users. It’s ideal when UC wants to avoid manually assigning permissions or managing approval flows.

❌ Why the other options are less suitable:
B. Enforce IP restrictions
This increases security but adds administrative complexity, especially for mobile users who may connect from varying networks. It’s not ideal when the goal is to reduce overhead.
D. High Assurance session required
This setting enforces stricter session requirements (e.g., MFA), which may be necessary for sensitive apps but adds friction and complexity. It’s not aligned with the goal of minimizing overhead for broad deployment.

🔗 References:
Salesforce Help: Connected App Settings
Salesforce Developer Guide: OAuth and Connected Apps

Explanation:

Why:
That specific error usually appears when the Connected App’s Permitted Users policy is set to “Admin approved users are pre-authorized.” In that mode, only users who are on the app’s pre-authorized Profiles/Permission Sets list can use it. If a user who isn’t pre-authorized tries to sign in, Login History shows “Failed: Not approved for access.” Adding the appropriate profile or permission set (or switching Permitted Users to “All users may self-authorize,” if appropriate) resolves it.

Why the others are unlikely:
A. If “All users may self-authorize” is enabled, users can approve access themselves—this reduces the chance of that error. Salesforce
B. Revoking OAuth would force re-authorization; it doesn’t produce the “Not approved for access” status by itself.
D. Requiring High Assurance (MFA) would prompt users to elevate their session; Salesforce documents and UI refer to raising session to high assurance rather than “Not approved for access.”

References:
Salesforce Help: ‘Failed: Not approved for access’ error (includes fix via Profiles/Permission Sets).
Salesforce Help: Manage OAuth Access Policies for a Connected App (explains “Admin approved users are pre-authorized” vs. “All users may self-authorize”).
Salesforce Help: Manage Session Policies for a Connected App (high-assurance behavior for contrast).