Free Practice Questions for Salesforce Identity-and-Access-Management-Architect Exam

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.

Salesforce Activations gives administrators visibility into the devices that users have activated for certain trusted access experiences and the ability to revoke those device activations when necessary. That aligns directly with compliance requirements to track devices used for login and to invalidate a device if it should no longer be trusted. Login History shows session data but not the same activation-management control plane. A custom object plus login flow would create a partial record, but it would not provide the built-in revocation semantics the requirement asks for. The important distinction is between observing a login event and managing device trust. Activations addresses device trust management, which is why it is the better fit here. This is why option D is the best answer in Salesforce terms.

The requirements call for two distinct capabilities: federation for sign-in and standards-based lifecycle management for provisioning. In Salesforce terms, that means Salesforce should act as a SAML service provider for authentication while SCIM handles create, update, and deactivate operations from the central IAM system. Just-in-Time provisioning alone is not enough here because the requirement includes provisioning and deprovisioning triggered by user status changes in the central identity service, not just first-login user creation. Identity Connect is aimed at Active Directory synchronization and is not the general answer for cloud IAM-to-Salesforce lifecycle management. Pairing SAML for SSO with SCIM for provisioning is the clean standards-based architecture when identity governance happens outside Salesforce. This is why option C is the best answer in Salesforce terms.

When an organization operates many brands, duplicating communities or orgs just to achieve branded login becomes expensive to build and maintain. Salesforce’s scalable answer is to use the Experience ID so the login journey can render the correct branding dynamically for each sub-brand. This preserves a centralized identity service while allowing multiple brand experiences across the same platform. Audiences are useful for content targeting after authentication, but they are not the core mechanism for routing a multi-brand login experience. The architecture principle is to separate identity infrastructure from visual brand presentation. Experience ID lets the organization keep one identity backbone and many branded entry experiences, which is exactly the type of scalability the requirement calls for. This is why option B is the best answer in Salesforce terms.

When Salesforce receives a SAML assertion and needs to translate external directory group membership into Salesforce entitlements at login, Apex Just-in-Time provisioning is the right hook. A JIT handler can read custom SAML attributes, interpret the incoming group values, and then create or update the user record and assign the appropriate permission sets. Login flows run after authentication and are not the normal mechanism for parsing assertion content into provisioning logic. Standard SAML attributes also don’t carry every organization-specific group mapping, which is why custom attributes are typically used for permission translation. The design goal is to make access decisions based on identity-provider claims at sign-in, and the JIT Apex handler is where Salesforce expects that provisioning and entitlement logic to be implemented. This is why option A is the best answer in Salesforce terms.

Salesforce supports dynamic branding for Experience Cloud login journeys through the Experience ID parameter. The Experience ID tells Salesforce which branded experience to render, allowing a single identity implementation to serve multiple brands or sub-brands without building separate authentication stacks. This is more scalable than asking users to pick a brand after arrival or inventing custom parameters and branding logic outside the standard experience framework. It also works cleanly with OAuth and SAML-based sign-in patterns, which is why it is commonly recommended in multi-brand CIAM designs. When the requirement is to reliably present the correct branded Salesforce experience during login, the Experience ID is the built-in mechanism intended for that routing and presentation layer. This is why option B is the best answer in Salesforce terms.

Salesforce’s JWT bearer flow is intended for server-to-server or noninteractive scenarios where a signed assertion is exchanged for an access token. Because the assertion is signed, the connected app must be configured to use a digital signature. The integration also needs the api scope so that the resulting token can call Salesforce APIs. Other scopes, such as generic web access, do not address the core requirement of API access through a JWT assertion. The design principle behind this flow is that no user is present to approve access interactively, so trust is established through certificate-based signing and the connected app’s policy configuration. That is why the digital signature setting is essential, not optional, in a JWT-based Salesforce integration. This is why options A, C work together as the correct solution.

Delegated Authentication is the Salesforce mechanism intended for organizations that must keep password validation and authentication processing in an external system reachable through a web service. In this model, Salesforce sends the authentication request outward and relies on the external service to decide whether the credentials are valid. That is a strong fit when regulations or internal policy require the external system to remain authoritative for passwords and authentication logic. JIT provisioning and SAML SSO solve adjacent problems, but they do not match the stated SOAP-based password-validation requirement. The important architecture cue is the external SOAP web service: that points directly to delegated authentication rather than to token-based federation or user-provisioning features. This is why option B is the best answer in Salesforce terms.

The OAuth 2.0 Asset Token Flow is Salesforce’s purpose-built answer for connected devices and IoT-style integrations. It is designed for assets that need to act on behalf of a physical device or asset record rather than a human user. That makes it the correct fit for sensors, GPS trackers, or smart devices that must securely post telemetry or create service actions in Salesforce. User-agent, web-server, or username-password flows are built around user identity or generic application access, not around a registered device/asset relationship. The architectural advantage of the asset token model is that it ties the authorization context back to the asset, which is exactly what you want when the platform must know which device generated the event or maintenance alert. This is why option C is the best answer in Salesforce terms.

If users must log in to the Salesforce mobile app with their Active Directory credentials and cannot rely on a mobile VPN, the architecture usually combines Salesforce Identity Connect with the appropriate Active Directory authentication plug-in or federation integration that allows Salesforce to honor those AD credentials without direct VPN dependency. Identity Connect helps bridge AD user management into Salesforce, while the directory-side authentication component handles password validation against Active Directory. Custom triggers or load balancers do not solve the identity problem. The important architecture idea is that workforce users should continue using their corporate directory password, and Salesforce should trust that directory-driven authentication path in a mobile-friendly way. This is why options A, B work together as the correct solution.