Free Salesforce-Platform-Identity-and-Access-Management-Architect Practice Test Questions (2026)

Explanation:

Let’s analyze each option:

Option D - Activations Feature (Correct): The Activations feature in Salesforce Identity provides a centralized way to manage and track user devices. Specifically, it allows:

Tracking device information: When users log in, their device (browser, mobile app, etc.) is registered as an "activation." The administrator can view all activations, including details like device type, browser, operating system, IP address, and login timestamps.

Revoking devices: Administrators can remotely revoke or deactivate a specific device/activation, which logs the user out from that device and prevents further access until re-authentication. This directly fulfills both the compliance tracking and device revocation requirements.

Option A - MFA (Incorrect): Multi-factor authentication adds an extra layer of security during login but does not inherently track or manage device information for administrative review and device revocation. MFA is about authentication, not device lifecycle management.

Option B - Login History Object (Incorrect): The Login History object captures login events, including IP address, browser, and login time. However, it is primarily read-only and does not provide the ability to revoke a device or user session. It tracks logins but doesn't directly support the admin action of revoking a device.

Option C - Login Flows (Incorrect): Login Flows are used to add custom business logic during the login process (e.g., capture additional information, enforce step-up authentication). While you could theoretically capture device information in a custom object via a Login Flow, this requires custom development and still does not provide the built-in, admin-friendly ability to revoke a device from the UI. The Activations feature performs both tasks natively without custom code.

Summary
The Activations feature is the purpose-built Salesforce Identity capability designed for this exact compliance scenario: it provides visibility into user devices and gives administrators the power to revoke device access directly from the Setup menu. No custom code or workarounds are required.

Reference
Salesforce Help: Activations — "View and manage user activations, including information about the devices users use to access Salesforce. You can revoke a user activation to log them out and prevent future access from that device until they log in again."

Salesforce Identity: Device Activation Management — Enables tracking all devices associated with user identity, supporting compliance and security requirements.

Explanation:

This question is testing which Salesforce feature helps investigate authentication and login failures. For issues involving SSO, federation, or user sign-in problems, Login History is the built-in place to review failed login attempts, timestamps, source IP, and error details tied to the user’s login activity.

Option A
❌ News Legs
This is not a Salesforce feature for troubleshooting authentication issues. It does not provide login attempt details, error codes, or identity-provider-related failure information, so it cannot help debug SSO login problems.

Option B
❌ Web Apps Audit Trail
Audit trail tracks configuration changes made by administrators, not user login failures. It may help identify setup changes affecting SSO, but it does not show individual authentication errors when users try to sign in.

Option C
✔️ Login History
Login History is the correct feature because it records login attempts and failures, including the reason a login was blocked or rejected. This makes it the best place to debug SSO-related user access issues in Salesforce.

Option D
❌ About Exception Email
Exception emails are used for system or code errors, such as Apex exceptions, not for end-user authentication troubleshooting. They do not provide the login failure visibility needed for this scenario.

🔧 Reference:
→ Resolve User Login Problems
— Confirms Salesforce login issues can be investigated through login-related records and error details.

Explanation:
To enable self-registration using Person Accounts on an Experience Cloud B2C portal, Person Accounts must first be enabled org-wide. The self-registration flow must be configured to create Person Accounts instead of business accounts with separate contacts. This requires correct settings in Login & Registration and proper record type access for unauthenticated users.

Correct Options:

B. Enable person accounts in the Setup page.
Person Accounts are not enabled by default in Salesforce. The administrator must first enable Person Accounts under Company Information Settings. This is a prerequisite for any solution using Person Accounts, including B2C self-registration portals.

C. Under Login and Registration settings, ensure that the default account field is empty.
In Experience Cloud Login & Registration settings, the "Default Account" field must be empty when using Person Accounts. If a default business account is specified, the self-registration flow will create a Contact under that business account instead of a Person Account. Leaving it empty triggers Person Account creation.

D. Enable access to person and business account record types under Public Access Settings.
The Guest User profile (public access) needs access to both Person Account and Business Account record types. If Person Account record type is not enabled for the guest user, self-registration will fail because the flow cannot create a Person Account. Business account access is also required for potential mixed scenarios.

Incorrect Options:

A. Enable business accounts in the Setup page.
Business Accounts are always enabled in Salesforce by default. There is no specific "enable business accounts" step. This option is irrelevant and incorrect because enabling Person Accounts does not require toggling anything for business accounts.

E. Set organization-wide default sharing for Contact to Public Read Only.
Organization-wide sharing defaults for Contact are not directly related to Person Account self-registration. Person Accounts have their own sharing rules (Account object with Person Account flag). Setting Contact OWD to Public Read Only does not enable or disable registration flows.

Reference:

Salesforce Help Article: "Enable Person Accounts for Experience Cloud Self-Registration"

Trailhead: "Person Accounts for B2C Sites" – Unit on "Self-Registration Configuration"

Salesforce Architect Documentation: "Experience Cloud Registration with Person Accounts"

Explanation:
To enable social sign-on with providers like Facebook and Google (supporting OpenID Connect) in Salesforce, an Authentication Provider must be configured for each provider. Additionally, a Registration Handler (an Apex class) is required to map the external user's identity to an existing or new Salesforce user account, controlling how users are linked or created.

Correct Option:

C. configure an authentication provider and a registration handler for each social sign-on provider.
An Authentication Provider defines the connection details (client ID, secret, endpoints) for each social provider. A Registration Handler is an Apex class that implements the Auth.RegistrationHandler interface. It controls linking logic—whether to create a new user, link to an existing contact, or update user attributes. Both are mandatory for a complete social sign-on implementation.

Incorrect Option:

A. configure a single sign-on setting and a JTT handler for each social sign-on provider.
There is no "JTT handler" in Salesforce Identity terminology. SSO settings are for SAML, not for OIDC social providers. Social sign-on requires Authentication Providers, not SAML SSO configurations.

B. configure an authentication provider and an Auto-Time Unit handler for each social sign-on provider.
"Auto-Time Unit handler" is not a real Salesforce component. The correct component is a Registration Handler. This option uses fabricated terminology and would not work.

D. configure a single sign-on setting and a registration handler for each social sign-on provider.
SAML SSO settings are not used for social providers like Google or Facebook. Social sign-on uses OAuth 2.0/OIDC with Authentication Providers. A Registration Handler alone without the Authentication Provider is useless because there is no connection to the external IdP.

Reference:

Salesforce Help Article: "Set Up Social Sign-On for External Users"

Trailhead: "Social Sign-On" – Unit on "Configure Authentication Providers and Registration Handlers"

Salesforce Developer Guide: "Auth.RegistrationHandler Interface"

Explanation:
NTO requires guests to self-register without being automatically assigned to a contact record until verification is complete. An external identity license allows user-only creation. The solution must use a customizable registration handler and the configurable self-registration page, while selecting the appropriate registration type for new customers.

Correct Options:

A. Customize the self-registration Apps handler to create only the user record.
The standard registration handler creates both a user and a contact. To prevent automatic contact assignment until verification, the architect must customize the registration handler (Auth.RegistrationHandler) to create only the user record initially. The external identity license supports user-only records without associated contacts.

B. Select the “Configurable Self-Reg Page” option under Login & Registration.
This setting enables the use of a custom self-registration page with Apex handlers. Without selecting this option, the standard registration flow forces immediate contact creation. Configurable Self-Reg Page allows the architect to plug in the customized handler that creates only the user record.

D. Select new customers and partners to self-register.
Under Login & Registration settings, the registration type must be set to allow "New customers and partners to self-register." This enables the self-registration link on the login page and permits external users to initiate the registration process. The other option ("No users can register") would block the flow.

Incorrect Options:

C. Set up an external login page and call Salesforce APIs for user creation.
This option is unnecessarily complex and incorrect. Experience Cloud provides native self-registration pages. Building an external login page with API calls bypasses built-in security, validation rules, and standard flows. The requirement can be met entirely within Experience Cloud using a custom handler.

E. Customize the self-registration Apps handler to temporarily associate the user to a shared single contact record.
This violates the requirement that guests should not be assigned to a contact record until after verification. Assigning a shared contact is still assignment. The requirement explicitly states "be unable to automatically be assigned to a contact record until verified." Only creating the user (without any contact) satisfies this.

Reference:

Salesforce Help Article: "Customize Self-Registration with Apex"

Trailhead: "Identity for External Users" – Unit on "Registration Handlers"

Salesforce Developer Guide: "Auth.RegistrationHandler Interface – Creating Users Without Contacts"

Explanation:

This question tests knowledge of the OAuth 2.0 User-Agent Flow (Implicit Grant Type) as implemented by Salesforce Identity for mobile applications. In this flow, the access token is returned directly to the client without an intermediate authorization code. Understanding which OAuth concepts participate in this flow is key.

✅ A. Refresh Token
In Salesforce's implementation, a refresh token can be returned in the user-agent flow if the refresh_token scope is explicitly included and the connected app is configured to allow it. This lets the app obtain new access tokens without re-prompting the user for credentials again.

✅ B. Client ID
The Client ID (Consumer Key) is a mandatory parameter in the user-agent flow. It identifies the connected app making the authorization request to Salesforce. Without it, Salesforce cannot recognize or validate the requesting application during the OAuth handshake.

✅ E. Scope
Scope defines the level of access the mobile application is requesting — such as api, openid, or refresh_token. It is a required parameter in the authorization request URL and controls what resources and data the issued token can access on behalf of the user.

❌ C. Verification Code
A Verification Code is not part of the standard OAuth 2.0 user-agent (implicit) flow. It belongs to device authentication flows or PKCE, not the implicit grant type. It plays no role in how tokens are requested or returned in this flow.

❌ D. Authorization Code
The Authorization Code belongs exclusively to the OAuth 2.0 Authorization Code Flow. In the implicit/user-agent flow, the access token is returned directly in the URL fragment — no intermediate authorization code is issued or exchanged at any stage.

🔧 Reference:
→ OAuth 2.0 User-Agent Flow – Salesforce Help
Confirms Client ID, Scope, and Refresh Token as key parameters used in the implicit grant flow and token response behavior.

Explanation:
The requirement is to show personalized alert messages to users before they land on the Experience Cloud homepage, with the least customization. Login Flows (formerly known as Login Discovery or Authentication Flows) allow administrators to add screens with custom logic and messages after authentication but before the user accesses the site, without writing Apex or building components.

Correct Option:

B. Use Login Flows to add a screen that shows personalized alerts.
Login Flows are a declarative, point-and-click feature in Salesforce. An administrator can create a Login Flow that triggers after successful authentication but before the user reaches the Experience Cloud homepage. The flow can include conditional logic to show different alert messages based on user profile, attributes, or time of day. This requires no Apex, LWC, or custom metadata, making it the least customization option.

Incorrect Option:

A. Customize the registration handler Apex class to create a routing logic navigating to different home pages based on the user profile.
This requires writing Apex and custom navigation logic, which is not "least customization." Registration handlers are designed for user provisioning during registration, not for post-login alerts before homepage rendering. This approach is overly complex and misaligned.

C. Create custom metadata that stores user alerts and use a LWC to display alerts.
Building a custom Lightning Web Component plus custom metadata types requires development effort. The alert would display on the homepage, not before landing on it. This does not meet the "before they land on the homepage" requirement and involves significant customization.

D. Build a Lightning Web Component (LWC) for a homepage that shows custom alerts.
Similar to option C, this displays alerts on the homepage, not before it. Users would first see the homepage, then the alert. Additionally, building an LWC requires development and deployment, which is far more customization than a declarative Login Flow.

Reference:

Salesforce Help Article: "Login Flows – Add Screens Before Users Access an Experience Cloud Site"

Trailhead: "Identity and Access Management for Architects" – Unit on "Login Discovery and Login Flows"

Salesforce Architect Documentation: "Login Flows for Experience Cloud"

Explanation:

The question tests knowledge of external authentication methods in Salesforce when regulatory rules require that all password storage and validation occur outside Salesforce. The key constraint is that authentication requests must be handled by a customer-owned system accessible only via SOAP webservice.

✔️ Correct Option:

B. Delegated Authentication
Delegated Authentication is designed for this exact use case. Salesforce sends the username and password entered on the login page to an external SOAP endpoint you host. Your service validates the credentials and returns true/false. Salesforce never stores or manages passwords, meeting the CIO’s requirement for external control via SOAP.

❌ Incorrect options:

A. Just-in-Time Provisioning
JIT handles automatic creation or updates of user records in Salesforce when a user logs in via SAML or an Auth Provider. It manages user provisioning attributes, not real-time password validation against an external SOAP service. So it doesn’t satisfy the requirement to externalize authentication requests.

C. Security Assertion Markup Language (SAML) Single Sign On
SAML SSO uses assertions from an identity provider to log users in without sending passwords to Salesforce. It bypasses the Salesforce login page and doesn’t invoke a customer SOAP webservice for password checks. Therefore it cannot meet the stated SOAP-based validation requirement.

D. OAuth Web-Server Flow
This OAuth flow is for authorizing external apps to access Salesforce APIs on behalf of a user and issues access tokens. It’s not used for direct user login to the Salesforce UI and does not delegate password verification to an external SOAP endpoint as required.

🔧 Reference:
→ Delegated Authentication – Confirms Salesforce calls an external SOAP web service to authenticate users and does not validate or store passwords internally.

Explanation:
The agency needs new user registration capturing first name, last name, and phone number, with phone number used for passwordless login. Login Discovery (specifically the Login Flow feature) allows a no-code flow that presents registration screens conditionally, collects user attributes, and can trigger phone-based verification (OTP) without a custom component or external IdP.

Correct Option:

B. Use Login Discovery
Login Discovery (via Login Flows) enables administrators to create a screen flow that runs before a user is fully authenticated. It can collect name and phone number, verify the phone via SMS OTP, and then either register a new user or authenticate an existing one using passwordless login. This meets all requirements declaratively without custom code or external integrations.

Incorrect Option:

A. Integrate with social websites (Facebook, LinkedIn, Twitter)
Social login integrates existing social identities but does not natively capture phone number for passwordless login. Social providers typically return email, not phone. Additionally, this adds complexity and an external dependency, with no native phone verification flow tied to registration.

C. Create a custom Lightning Web Component
An LWC could be built to capture these fields, but that requires development, testing, and maintenance. Login Discovery provides a declarative, supported alternative with built-in phone verification actions. The question asks for a feature recommendation, not a custom coding approach.

D. Use an external Identity Provider
An external IdP (e.g., Okta, Auth0) could handle phone-based passwordless login, but this adds cost and integration effort. Salesforce Identity can natively achieve the same using Login Discovery with phone verification. An external IdP is unnecessary and violates choosing the simplest in-platform solution.

Reference:

Salesforce Help Article: "Login Flows for Phone Verification and Passwordless Login"

Trailhead: "Identity and Access Management for Architects" – Unit on "Login Discovery"

Salesforce Architect Documentation: "Passwordless Login Using Login Flows"

Explanation:

This question tests knowledge of OpenID Connect standards within Salesforce Identity. Token introspection is a standard OAuth 2.0 / OpenID Connect endpoint that allows a client or resource server to check the active state, expiration, and metadata of an access token. This is exactly what is needed to retrieve the access token status.

✔️ Correct Option:

✔️ A. Leverage OpenID Connect Token Introspection.
Token Introspection (RFC 7662) provides a standard endpoint (/services/oauth2/introspect) that accepts an access token and returns its active status, scope, client ID, expiration, and other metadata. This allows the mobile app to programmatically validate whether an access token is still valid, without attempting to use it.

❌ Incorrect options:

❌ B. Query using OpenID Connect discovery endpoint.
The discovery endpoint (/.well-known/openid-configuration) returns metadata about the IdP's endpoints and capabilities. It does not retrieve the status of a specific access token. It is used for configuration, not token validation.

❌ C. Enable cross-origin resource sharing (CORS) for the /services/oauth2/token endpoint.
CORS allows web applications from different domains to call Salesforce APIs. It does not provide token status information. CORS is a browser security mechanism, not a method to inspect token validity or metadata.

❌ D. Create a custom OAuth scope.
Custom OAuth scopes control which resources or permissions a token grants access to. Scopes do not retrieve token status or introspection data. They define authorization boundaries, not token validation capabilities.

🔧 Reference:
→ Salesforce Help: Introspect an Access Token with OpenID Connect Token Introspection
Confirms that the /services/oauth2/introspect endpoint returns the active status and metadata of an access token for OpenID Connect connections.