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

When an external directory service is intended to remain the central source for authentication and authorization across systems, the right architecture to evaluate is federation rather than password synchronization or database sharing. SAML is one of the standard ways Salesforce establishes that federated trust with an enterprise identity system. Email verification and IP restrictions can complement security, but they do not create single sign-on or shared identity trust. A shared credential table is also not an acceptable identity architecture. The important design principle is that Salesforce should trust the external identity service through standards-based federation and allow that system to remain authoritative for authentication. That is precisely the problem SAML-based federation is designed to solve. This is why option D is the best answer in Salesforce terms.

Contactless users in Experience Cloud are tied to a narrower external identity model than full community users associated with contacts. That is the important architectural tradeoff. The feature can reduce overhead for certain external identity scenarios, but it also limits what license model and functionality are available. In practice, architects need to recognize that contactless users are associated with External Identity use cases rather than the richer Experience Cloud collaboration capabilities that depend on account-contact relationships. That is why the decision affects portal design, entitlement options, and downstream business processes. The right answer focuses on the license and capability limitation, not on speculative behavior about passwordless login or automatic contact creation during a later license change. This is why option C is the best answer in Salesforce terms.

When some users sign in through Salesforce credentials and others through an external IdP that already performs MFA, the goal is to avoid prompting everyone twice while still requiring MFA-strength assurance. Salesforce handles that through session security levels. By requiring High Assurance at login and recognizing the corporate identity provider as satisfying High Assurance, the org can accept the IdP’s MFA result while still enforcing stronger authentication for direct Salesforce logins. Enabling the generic “MFA for UI Logins” control alone can force an extra challenge on top of the IdP’s MFA. The architecture lesson is that assurance level mapping is what prevents duplicate prompts across mixed authentication paths. This is why option D is the best answer in Salesforce terms.

Salesforce Embedded Login exists specifically to place a Salesforce-backed login experience inside another application or service provider, which makes it the right feature to consider for a seamless sign-in widget. However, the architectural caveat is browser behavior. Embedded login can rely on third-party cookies, and modern browser privacy controls can affect how that experience behaves. That dependency is often the deciding consideration before recommending it. REST APIs and generic OAuth flows are part of the broader identity toolbox, but they don’t answer the executive sponsor’s question about embedding a login widget directly into another application. The recommendation should therefore focus on Embedded Login and on whether the target browser landscape will tolerate the cookie model it depends on. 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.

My Domain is a prerequisite for many modern Salesforce identity capabilities because it gives the org a unique and predictable login domain. In multi-org environments, that matters when users click record links from emails and must be routed into the correct instance and authentication path. Without My Domain, identity routing and branded login behavior become harder to control, especially when multiple orgs and external identity providers are involved. MFA and Identity Provider settings address other aspects of security, but they do not provide the unique domain-level entry point required here. The architectural role of My Domain is both technical and user-facing: it standardizes the login endpoint and helps ensure that generated links take users to the proper org context. This is why option B is the best answer in Salesforce terms.

The OAuth 2.0 Device Flow is intended for devices that have limited input or display capabilities and therefore cannot easily support a standard browser-based login interaction. Instead of collecting full credentials on the device, the user completes authorization on a secondary device using a verification code and URL. That is why Salesforce recommends device flow for TVs, appliances, kiosks, and similarly constrained hardware. Asset Token Flow solves a different problem: it authorizes a registered asset or device to call Salesforce as a connected thing. Here the requirement is about registration and user authorization from a constrained device, so the device flow is the correct match. The design distinction is between human sign-in on limited hardware and secure machine identity for an asset. This is why option D is the best answer in Salesforce terms.

If the organization wants users to sign in only through SSO and not by entering credentials at login.salesforce.com, two standard controls are used together. My Domain can be configured to prevent login from the generic Salesforce login page, forcing users onto the org-specific authentication entry point. In addition, the user can be marked as “Is Single Sign-On Enabled,” which prevents password-based Salesforce login for that user. Those two controls reinforce each other: one redirects the entry point, and the other removes the fallback credential path. Delegated authentication is not required just to enforce SSO, and simply enabling SSO never means Salesforce credentials stop working automatically. The architecture goal is to remove non-SSO login paths deliberately. This is why options A, D work together as the correct solution.

When customers are invited into an Experience Cloud site rather than self-registering, the normal Salesforce pattern is to create them as contacts, add them to the site, and enable the welcome email so they can establish their own password from the invitation. Login flows are not the primary mechanism for initial password setup, and updating site membership through an API does not replace the standard invitation process. The important architectural idea is that the user lifecycle begins with site membership and an activation journey, not with self-service reset logic. Salesforce’s welcome-email flow is specifically designed for this moment: it gives the invited external user a secure path to activate access and define their password for the community. This is why options A, D work together as the correct solution.