The Salesforce Certified Platform Identity and Access Management Architect (Plat-Arch-203) (Identity-and-Access-Management-Architect)

When an architect needs to enforce IP restrictions, session timeouts, or related access controls for a connected app, the place to do that is the connected app’s OAuth policies. Those policies let Salesforce administrators shape how the app can be used, from permitted-user policy to IP relaxation behavior and session-related restrictions. Login IP ranges on profiles are broader user controls, while custom permissions don’t govern the connected app’s OAuth runtime behavior. The important architecture distinction is that connected-app security should be controlled where the app trust is defined. Salesforce puts those controls in the connected app’s policy layer, which is why OAuth policies are the right answer for app-specific session and network enforcement. This is why option D is the best answer in Salesforce terms.

If an organization has multiple regional ADFS systems and wants one Salesforce org without buying an additional federation broker, Salesforce can be configured with multiple SAML SSO settings so users choose the appropriate identity provider at sign-in. That satisfies the “no additional application investment” constraint more directly than introducing a new central identity broker. Identity Connect is not the solution here because it focuses on AD user synchronization, not on federating multiple ADFS realms into Salesforce login. The architectural compromise is user choice at the login screen, but it keeps the design standards-based and avoids extra infrastructure. For a single-org deployment with multiple existing enterprise IdPs, exposing multiple SSO configurations is the practical native approach. This is why option B is the best answer in Salesforce terms.

For a mobile app using the user-agent flow, two connected-app controls work together when the business wants a long-lived session without repeated approval prompts. First, the app should be set to Admin Approved Users Are Pre-Authorized so users are not asked to approve API access inside the mobile experience. Second, the refresh-token policy should be configured for the required lifetime, such as three months, so the app can keep renewing access without forcing the user to log in again. A session timeout controls the UI session but not the refresh-token lifecycle in the same way. The architectural point is that user consent suppression and durable reauthentication behavior are governed by separate connected-app policies. This is why options C, D work together as the correct solution.

Dynamic branding in Experience Cloud relies on the Experience ID, sometimes carried as the expid parameter or equivalent placeholder in the URL, so Salesforce can render the right login experience for the selected brand. This is the scalable way to vary the look and feel without duplicating entire identity stacks. The community template choice can matter because not every template exposes branding capabilities the same way, but the central concept is still the Experience ID. External CMS tools are not required just to route the login experience by brand. From an architecture standpoint, this keeps the login framework centralized while letting the entry experience adapt to whichever brand, campaign, or sub-experience the user selected before authentication. This is why option D is the best answer in Salesforce terms.

When a third-party enterprise identity provider already validates users against LDAP and the organization wants employees to remember as few passwords as possible, Salesforce should be configured as the service provider. That lets the existing IdP remain the authoritative login system while Salesforce trusts the resulting assertion. Salesforce Connect is unrelated to password synchronization, and making Salesforce the IdP would invert the current enterprise architecture. This is a classic workforce SSO pattern: the corporate identity layer owns credentials, and Salesforce consumes that identity through federation. The architectural win is reduced password sprawl. Users authenticate once against the enterprise identity provider and then reach Salesforce without maintaining a separate Salesforce password. This is why option D is the best answer in Salesforce terms.

Salesforce documents token introspection as the standards-based way to ask the authorization server about the current state of an OAuth token after it has been issued. That is exactly what this scenario requires: checking whether an OpenID Connect access token is still active, expired, or revoked. The discovery document only advertises endpoints and capabilities; it does not return runtime token status for a specific token. Likewise, enabling CORS on the token endpoint affects browser access patterns, not token validation, and creating a custom scope changes authorization boundaries rather than token-state lookup. In other words, when the requirement is “retrieve token status,” token introspection is the platform feature designed for that purpose. This is why option A is the best answer in Salesforce terms.

Dynamic branding in Experience Cloud relies on the Experience ID, sometimes carried as the expid parameter or equivalent placeholder in the URL, so Salesforce can render the right login experience for the selected brand. This is the scalable way to vary the look and feel without duplicating entire identity stacks. The community template choice can matter because not every template exposes branding capabilities the same way, but the central concept is still the Experience ID. External CMS tools are not required just to route the login experience by brand. From an architecture standpoint, this keeps the login framework centralized while letting the entry experience adapt to whichever brand, campaign, or sub-experience the user selected before authentication. This is why options B, D work together as the correct solution.

Salesforce’s user-agent flow implements the OAuth 2.0 implicit grant model for browser-based or mobile applications that obtain authorization through a browser. In that flow, the client uses a client ID and requests specific scopes. The user authorizes the app, and the resulting token is delivered through the browser-based redirect. In Salesforce identity examples, refresh-related behavior is often part of the mobile discussion, while an authorization code is not a characteristic of the implicit model. That is the key concept to remember: implicit or user-agent flow is centered on browser-mediated authorization without a back-end code exchange. So the valid concepts align with client identity and requested access, not with the server-side authorization-code step used in the web server flow. This is why options A, B, E work together as the correct solution.

For a portal that wants users to enter a phone number or email address first and then receive a one-time verification code, Salesforce’s recommended pattern is a Login Discovery page backed by a Login Discovery handler. This supports identifier-first authentication and lets the org decide how to route or verify the user once the identifier is known. Building a custom login page and controller can work, but it bypasses the purpose-built experience Salesforce provides for this exact passwordless entry pattern. Authentication providers and login flows solve different phases of the login journey. The architectural advantage of Login Discovery is that it cleanly supports phone-or-email identification before the platform or handler triggers the verification step. This is why option C is the best answer in Salesforce terms.