Free Salesforce Identity-and-Access-Management-Architect Practice Exam with Questions & Answers | Set: 3

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.

For Experience Cloud self-registration with Person Accounts, Salesforce requires the org and site configuration to line up with how external users are created. Person Accounts must first be enabled at the org level. On the site, the default account field must be left blank so the self-registration process doesn’t force users into a shared business account model. Public access settings also need access to the relevant Person Account and business account record types so the registration process can create the right record. This is the documented pattern when self-registration is meant to create people as customers rather than contacts under a standard account. The key idea is that registration must be allowed to create the correct account model from the start. This is why options B, C, D work together as the correct solution.

For a website that doesn’t natively speak SAML or OAuth but still wants Salesforce-backed social sign-in, the architecture typically combines authentication providers with Embedded Login, and the integration is supported through the connected app framework around Salesforce Identity. Authentication providers establish trust with the social sources, while Embedded Login brings the Salesforce-controlled sign-in experience into the existing site. Delegated Authentication is for username/password validation against an external system and doesn’t provide social sign-in. Identity Connect is also unrelated because it is aimed at directory synchronization. The key architectural move is to let Salesforce handle the identity transaction and present that capability inside the existing website, rather than trying to make the legacy site implement standards it doesn’t already support. This is why options A, B, D work together as the correct solution.

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.

For real-time visibility into login events and other security-relevant user activity, Salesforce Event Monitoring is the purpose-built monitoring feature. Event Monitoring and Event Log Files give security and identity teams access to detailed telemetry about login behavior, session activity, API usage, and other actions that matter for threat detection and investigation. Profiles and encryption settings do not provide operational monitoring, and Data Loader is unrelated. The architectural distinction is between preventive controls and detective controls. Event Monitoring is a detective control: it helps the organization observe behavior, identify anomalies, and react quickly. When the requirement mentions unusual login patterns, security incidents, or real-time monitoring, Salesforce documentation points architects toward Event Monitoring rather than ordinary administrative setup screens. This is why option A 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.

In delegated authentication, Salesforce hands off password validation to the external system that owns the credentials. Because the password is not managed by Salesforce, the user must change that password in the enterprise authentication source, such as the LDAP or SSO portal. Salesforce reset links and in-app change-password pages are not authoritative in that model. This is a common exam theme: once credential management is delegated, the downstream service does not become the place where users administer those credentials. The architectural boundary matters. Salesforce still consumes the authentication result, but the source system retains responsibility for password storage, password policy, and password changes. Therefore the end-user password-management experience belongs to the external identity store. This is why option A is the best answer in Salesforce terms.

When customers sign in to an Experience Cloud site with Facebook or LinkedIn credentials, Salesforce is consuming identity from those providers. In federation terms, that means Salesforce is the service provider and the social platforms are acting as the identity providers. This is a foundational identity concept and helps explain why the configuration happens through authentication providers in Salesforce. Salesforce is not issuing the social credential; it is trusting the identity assertion or token from the external provider and then creating or locating the user locally. Understanding that role assignment is important because it determines where trust is configured, where profile data originates, and how the registration handler fits into the login process. This is why option C is the best answer in Salesforce terms.

When an external brand such as Amazon supports OpenID Connect and the requirement is to let customers use those credentials to sign in to Experience Cloud, the straightforward Salesforce approach is to configure an OpenID Connect authentication provider. A connected app represents an app trust relationship, not the external identity source for community login. A predefined provider can be used only when Salesforce offers that exact template; otherwise standards-based OIDC is the general answer. Building a custom provider would be unnecessary if the external source already speaks OpenID Connect. The architectural decision is simply to use the standard protocol that the provider supports and let Salesforce consume that identity through an authentication provider. This is why option C 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.