# Free Salesforce Identity and Access Management Architect Practice Questions

*Last updated September 2026 · https://www.certifyforce.com/salesforce-identity-access-management-architect-practice-exam/free-questions*

18 free Identity and Access Management Architect practice questions from the CertifyForce bank of 300 reviewed questions, spread across the 6 official exam sections in proportion to their weight. Each has the correct answer, an explanation, and the official documentation it was verified against.

## Identity Management Concepts (17%)

### Question 1

Cloud Kicks runs an Experience Cloud site for its dealer network with SAML single sign-on. Dealerships are accounts identified by a custom Dealer_Code__c field, and Account Number isn't populated. The first time a dealer employee logs in, Salesforce must provision the person under the account whose Dealer_Code__c matches the code the identity provider sends. If no dealership matches, the login must fail instead of creating an account. What should the identity architect recommend?

- A. Use Custom SAML JIT with Apex handler, with a class that finds the account by Dealer_Code__c, creates the contact and user, and rejects unknown codes
- B. Use Standard JIT, and send the dealer code in an Account.Dealer_Code__c attribute so that Salesforce matches the existing account on that field
- C. Use Standard JIT, load the dealer codes into Account Number, and send Account.AccountNumber, because Standard JIT stops when no account has that number
- D. Use Standard JIT with only User attributes, and let a record-triggered flow move each new user under the right dealership account afterward

**Correct answer:** A. Use Custom SAML JIT with Apex handler, with a class that finds the account by Dealer_Code__c, creates the contact and user, and rejects unknown codes

**Explanation:** Standard JIT for Experience Cloud matches accounts only by Contact.Account or Account.AccountNumber, and when no account matches it inserts a new account, contact, and user, which breaks the requirement to fail on unknown codes. It also doesn't support custom fields for accounts or contacts, so it can't match on Dealer_Code__c. A class that implements Auth.SamlJitHandler must perform the creation logic itself, including any associated account and contact records, so it can look up the dealership by the custom field and refuse the login when there's no match. Sending only User attributes gives Standard JIT no contact or account details for a site user, and fixing the account afterward doesn't satisfy provisioning under the right dealership at first login.

**Sources:** [Just-in-Time SAML Assertion Fields for Experience Cloud](https://help.salesforce.com/s/articleView?id=xcloud.sso_jit_community_requirements.htm&language=en_US&type=5), [SamlJitHandler Interface](https://developer.salesforce.com/docs/atlas.en-us.apexref.meta/apexref/apex_interface_Auth_SamlJitHandler.htm)

### Question 2

Universal Containers is evaluating delegated authentication so that its existing on-premises authentication service validates Salesforce logins. The CISO wants to understand how this pattern behaves. Which two statements are accurate? Choose 2 answers.

- A. For users with the Is Single Sign-On Enabled permission, Salesforce no longer enforces password policies such as expiration or minimum length; the external service does.
- B. Users who forget their password can reset it from the Salesforce login page, as usual.
- C. Salesforce sends the username, password, and source IP to the web service, which returns true or false.
- D. Salesforce keeps a hash of each password so that users can still log in if the web service is unavailable.
- E. Users are redirected to the external service's login page and then returned to Salesforce with a signed assertion.

**Correct answers:** A. For users with the Is Single Sign-On Enabled permission, Salesforce no longer enforces password policies such as expiration or minimum length; the external service does.; C. Salesforce sends the username, password, and source IP to the web service, which returns true or false.

**Explanation:** When Is Single Sign-On Enabled is assigned, control of the password moves to the external method, and the delegated authentication endpoint enforces any password policies. Salesforce passes the username, password, and source IP to the customer's web service, which checks them and returns true or false. Password reset is disabled for delegated authentication, and users who try to reset are sent to their Salesforce admin. Salesforce discards the password immediately without storing, logging, or viewing it, so no hash is kept. A redirect to an external login page with a signed assertion coming back describes federated SAML SSO, not delegated authentication.

**Sources:** [Delegated Authentication](https://help.salesforce.com/s/articleView?id=sf.sso_delauthentication.htm&language=en_US&type=5), [FAQs for Delegated Authentication](https://help.salesforce.com/s/articleView?id=xcloud.sso_delauthentication_tips.htm&language=en_US&type=5)

### Question 3

Cumulus Financial's regulator requires that changes to the Credit Limit and Risk Rating fields on Account be retained for ten years for audit. The admin has turned on standard field history tracking for both fields. What should the identity architect tell the compliance team?

- A. Standard field history is kept for 18 months (24 through the API), so turn on Field Audit Trail to retain history until it's deliberately deleted.
- B. Standard field history tracking already keeps field history indefinitely, so no further action is needed.
- C. Download Setup Audit Trail every 180 days, because it records every field value change on Account along with the user who made it.
- D. Export Login History monthly and archive it, because it records which user changed each field value and when.

**Correct answer:** A. Standard field history is kept for 18 months (24 through the API), so turn on Field Audit Trail to retain history until it's deliberately deleted.

**Explanation:** When Field Audit Trail is off, Salesforce keeps field history for up to 18 months, or 24 months through the API. That doesn't meet a ten-year requirement. When Field Audit Trail is on, field history is kept until it's manually deleted. So standard tracking by itself doesn't keep history indefinitely. Setup Audit Trail records setup and configuration changes, not record field values. Login History records login attempts, not data changes.

**Sources:** [Field History Tracking Overview](https://help.salesforce.com/s/articleView?id=xcloud.tracking_field_history.htm&language=en_US&type=5)

## Accepting Third-Party Identity in Salesforce (21%)

### Question 4

Get Cloudy Consulting's consultants all have Microsoft Entra ID (formerly Azure Active Directory) work accounts. The company wants them to log in to Salesforce with those Microsoft credentials by using one of Salesforce's predefined authentication provider types. Which provider type should the identity architect choose?

- A. Microsoft
- B. Microsoft Access Control Service
- C. Janrain
- D. Salesforce

**Correct answer:** A. Microsoft

**Explanation:** The Microsoft authentication provider type lets users log in to Salesforce with their Microsoft credentials and supports authentication with all services provided by Microsoft Azure Active Directory, and it supports both SSO and third-party data access. Microsoft Access Control Service is used with the OAuth protocol for authorization scenarios such as SharePoint Online and doesn't support SSO. Janrain is a separate identity service with its own provider type, not a way to use Microsoft work accounts directly. The Salesforce provider type sets up SSO between two Salesforce orgs.

**Sources:** [Configure a Microsoft Authentication Provider](https://help.salesforce.com/s/articleView?id=xcloud.sso_provider_microsoft_only.htm&language=en_US&type=5), [Define an Authentication Provider](https://help.salesforce.com/s/articleView?id=xcloud.sso_predefined_authentication_provider_parent.htm&language=en_US&type=5)

### Question 5

Cloud Kicks runs two production orgs, one for sales and one for service. Both trust the same corporate SAML identity provider and use standard Just-in-Time (JIT) provisioning. The identity provider team wants a single attribute mapping that works for both orgs. New users currently fail to provision, and the assertion contains User.Username, User.Email, User.LastName, and User.FederationIdentifier. What should the identity architect recommend?

- A. Add a User.ProfileId attribute that contains the profile name instead of a profile ID.
- B. Add a User.ProfileId attribute that contains the profile ID copied from the sales org.
- C. Add a User.Role attribute with the role name, so standard JIT derives the profile from it.
- D. Switch to a custom SAML JIT handler, because standard JIT can't set a user's profile.

**Correct answer:** A. Add a User.ProfileId attribute that contains the profile name instead of a profile ID.

**Explanation:** Standard JIT requires Email, LastName, ProfileId, and Username in the assertion, so the missing ProfileId is why provisioning fails. A profile ID is different in each org, even for a standard profile, and Salesforce lets the identity provider pass the profile name in the ProfileId field, which keeps one mapping valid for both orgs. A profile ID copied from the sales org doesn't exist in the service org, so provisioning there would still fail. Role is an optional field and doesn't determine the profile. A custom handler isn't needed, because standard JIT sets the profile from the ProfileId attribute.

**Sources:** [Just-in-Time SAML Assertion Fields for Salesforce](https://help.salesforce.com/s/articleView?id=sf.sso_jit_requirements.htm&language=en_US&type=5)

### Question 6

AW Computing uses its headquarters Salesforce org as the SAML identity provider for a subsidiary org. The subsidiary org's SAML single sign-on setting uses Assertion contains the Federation ID from the User object, and the subsidiary's SAML app in the headquarters org sends Federation ID as the subject. A pilot user logs in to headquarters successfully, but SSO into the subsidiary org fails because no matching user is found. What is the most likely cause?

- A. The subsidiary org must also be enabled as a SAML identity provider before it can accept assertions from another org.
- B. The headquarters org must send the user's Salesforce username as the subject, because Federation ID works only with third-party identity providers.
- C. The pilot user's record in the subsidiary org doesn't have the same Federation ID value as the user's record in the headquarters org.
- D. SAML isn't supported between two Salesforce orgs, so the subsidiary org must use delegated authentication instead.

**Correct answer:** C. The pilot user's record in the subsidiary org doesn't have the same Federation ID value as the user's record in the headquarters org.

**Explanation:** In SAML SSO between Salesforce orgs, the service provider org matches the subject of the assertion to a user by Federation ID, so the user in each org must carry the same Federation ID value to bind the two records together; a missing or different value produces a user-not-found failure. Only the hub org is enabled as the identity provider; the spoke org is configured as a service provider through its SAML single sign-on setting. Federation ID is the documented subject type for org-to-org SAML, so switching to the username isn't required. Salesforce explicitly supports hub-and-spoke SAML SSO across multiple orgs and Experience Cloud sites, so delegated authentication isn't needed.

**Sources:** [Configure SAML SSO Between Salesforce Orgs or Experience Cloud Sites](https://help.salesforce.com/s/articleView?id=xcloud.sso_between_multiple_orgs.htm&language=en_US&type=5), [Setup Inbound SSO Guide for Internal Users (Trailhead)](https://trailhead.salesforce.com/content/learn/modules/identity_login/identity_login_sso)

### Question 7

Ursa Major Solar wants homeowners to sign up on its Experience Cloud site just to save solar quotes. At first it needs only a lightweight identity directory, and it wants to preserve its limited community licenses for homeowners who become customers, who then need a contact record and full site features. Which two recommendations meet these requirements? Choose 2 answers.

- A. Have the marketing platform create registrants as contactless users through SCIM.
- B. Assign every registrant a Customer Community license at sign-up so that no later license change is needed.
- C. Use External Identity licenses and create contactless users through a custom self-registration page that calls the API.
- D. When a homeowner becomes a customer, associate a contact with the user and upgrade the user to a community license.
- E. Store registrants only as leads and create their users after their first purchase.

**Correct answers:** C. Use External Identity licenses and create contactless users through a custom self-registration page that calls the API.; D. When a homeowner becomes a customer, associate a contact with the user and upgrade the user to a community license.

**Explanation:** Contactless users, available only with the External Identity license, give a lightweight user directory without contact records; for self-registration, Salesforce says to build a custom self-registration page that creates contactless users through the API. When a user qualifies, you assign the user a contact and then upgrade them to a community license, which preserves community licenses for qualified customers. SCIM isn't supported for creating contactless users. Assigning community licenses at sign-up consumes the licenses the company wants to save. Leads have no login, so homeowners couldn't sign in to save quotes.

**Sources:** [Manage Sites with Contactless Users](https://help.salesforce.com/s/articleView?id=xcloud.external_identity_contactless_users_use_cases.htm&language=en_US&type=5), [Create Lightweight Contactless Users](https://help.salesforce.com/s/articleView?id=xcloud.external_identity_manage_create_contactless_users.htm&language=en_US&type=5)

## Salesforce as an Identity Provider (17%)

### Question 8

Northern Trail Outfitters uses Salesforce as the SAML identity provider for a loyalty rewards service provider. Employees log in through the org, and customers log in through the company's Experience Cloud site; both use the same SAML-enabled app. The service provider matches users by plain email address, so the app's Name ID Format is set to email address. Employees reach the rewards site, but the service provider rejects customers because it can't find their accounts. What should the identity architect do?

- A. Change the Name ID Format to transient so that the service provider receives a new identifier at each login
- B. Enable Just-in-Time provisioning in the org's SAML single sign-on settings for customer users
- C. Add a custom attribute that sends the user's email address, and have the service provider read that attribute
- D. Change the Subject Type to Persistent ID so that each customer gets a stable identifier

**Correct answer:** C. Add a custom attribute that sends the user's email address, and have the service provider read that attribute

**Explanation:** When the Name ID Format is email address, Salesforce sends only the email address for org users, but for Experience Cloud users it adds the org ID to the email address in the NameID. The service provider receives a value it doesn't recognize for customers, which matches the symptom, and Salesforce's guidance for service providers that accept only the email address is to create a custom attribute for it. A transient identifier changes at each login, so it can't be matched to existing accounts. Just-in-Time provisioning in a SAML single sign-on setting creates users in Salesforce when Salesforce is the service provider, so it doesn't help an external service provider. A persistent ID is calculated algorithmically and wouldn't match the email addresses that the service provider stores.

**Sources:** [Integrate Service Providers as Connected Apps with SAML 2.0](https://help.salesforce.com/s/articleView?id=xcloud.connected_app_create_saml_sso.htm&language=en_US&type=5), [Salesforce as an Identity Provider](https://help.salesforce.com/s/articleView?id=xcloud.sso_sfdc_idp_parent.htm&language=en_US&type=5)

### Question 9

Developers at a Northern Trail Outfitters partner are building OAuth 2.0 web server flow requests for their app, and they have several assumptions about scopes. The identity architect reviews them. Which two statements about Salesforce OAuth scopes are accurate? Choose 2 answers.

- A. Requesting the full scope doesn't return a refresh token unless the refresh_token scope is also requested
- B. The app must explicitly request the id scope before it can call the identity URL
- C. The api scope lets the app read records that the authorizing user can't see, as long as the app is admin-approved
- D. If the authorization request omits the scope parameter, all scopes assigned to the connected app are requested
- E. The app can request scopes that aren't assigned to the connected app, and Salesforce grants them if the user approves

**Correct answers:** A. Requesting the full scope doesn't return a refresh token unless the refresh_token scope is also requested; D. If the authorization request omits the scope parameter, all scopes assigned to the connected app are requested

**Explanation:** The full scope covers all data the logged-in user can access and encompasses the other scopes, but it doesn't return a refresh token, so refresh_token must be requested explicitly. When the scope parameter is left out of the authorization request, all scopes assigned to the connected app are requested. Scopes passed in the request must be a subset of the scopes registered for the app, so the app can't obtain unassigned scopes even with user approval. All scope values include id, so the identity URL is available without requesting id separately. The api scope gives access to the current, logged-in user's account through the APIs, so that user's own object, field, and record access still applies.

**Sources:** [OAuth Tokens and Scopes](https://help.salesforce.com/s/articleView?id=xcloud.remoteaccess_oauth_tokens_scopes.htm&language=en_US&type=5), [OAuth 2.0 Web Server Flow for Web App Integration](https://help.salesforce.com/s/articleView?id=xcloud.remoteaccess_oauth_web_server_flow.htm&language=en_US&type=5)

### Question 10

Get Cloudy Consulting's external timesheet app lets only employees with the Approve Timesheets custom permission approve entries. The app connects to Salesforce through a connected app and must be able to check, through that OAuth access, whether the signed-in user has the custom permission. Which scope should the connected app include?

- A. Access Lightning applications (lightning)
- B. Access custom permissions (custom_permissions)
- C. Perform requests at any time (refresh_token, offline_access)
- D. Manage user data via Web browsers (web)

**Correct answer:** B. Access custom permissions (custom_permissions)

**Explanation:** The custom_permissions scope allows access to the custom permissions in the org that are associated with the connected app and shows whether the current user has each one enabled. The lightning scope lets hybrid apps obtain Lightning child sessions through the hybrid app flows. The refresh_token scope lets the app get a refresh token so it can act while the user is offline, which says nothing about permissions. The web scope lets the access token be used on the web, including Visualforce pages, and doesn't report custom permissions.

**Sources:** [OAuth Tokens and Scopes](https://help.salesforce.com/s/articleView?id=xcloud.remoteaccess_oauth_tokens_scopes.htm&language=en_US&type=5)

## Access Management Best Practices (15%)

### Question 11

Cumulus Financial's identity provider authenticates every employee with a password plus an authenticator-app push and sends the AMR value mfa in each SAML response. Nonprivileged employees reach Salesforce without further prompts, but after they sign in at the identity provider, System Administrators are told to create a passkey and aren't offered another verification method. Which two actions resolve the administrators' login experience? Choose 2 answers.

- A. Have the identity provider authenticate administrators with a phishing-resistant method, such as a FIDO2 security key, and send a matching AMR or ACR value such as hwk or fido.
- B. Have the administrators register the Salesforce Authenticator app in Salesforce as their verification method.
- C. Move the SAML SSO provider to the High Assurance column of Session Security Levels in Session Settings.
- D. Have the administrators register a built-in authenticator or security key in Salesforce when they're prompted.
- E. Remove the AMR attribute from the SAML response so that Salesforce stops evaluating the strength of the MFA method.

**Correct answers:** A. Have the identity provider authenticate administrators with a phishing-resistant method, such as a FIDO2 security key, and send a matching AMR or ACR value such as hwk or fido.; D. Have the administrators register a built-in authenticator or security key in Salesforce when they're prompted.

**Explanation:** Privileged users, such as anyone with the System Administrator profile, must use phishing-resistant MFA for both direct and SSO logins. The AMR value mfa counts only as standard MFA, so Salesforce can't confirm that the administrators met the phishing-resistant requirement. The fix is either to have the identity provider use a phishing-resistant method and send a phishing-resistant signal such as hwk or fido, or to have administrators register a passkey (built-in authenticator or security key) in Salesforce. Salesforce Authenticator is a standard-tier method, so it doesn't satisfy the requirement for privileged users. The Session Security Levels columns don't change MFA-strength enforcement. Removing the AMR attribute makes Salesforce treat the SSO login as having no MFA at all.

**Sources:** [MFA Verification Method Tiers](https://help.salesforce.com/s/articleView?id=xcloud.mfa_security_tiers.htm&language=en_US&type=5), [Prepare for MFA Enforcement for All Employee Users](https://help.salesforce.com/s/articleView?id=005321561&language=en_US&type=1)

### Question 12

A Get Cloudy Consulting developer wrote a custom connected app handler that extends Auth.ConnectedAppPlugin. Its authorize method returns true only for consultants who have completed security training, and the handler is selected on the connected app with an execution user. In testing, consultants who haven't completed training can still use the app. The connected app's Permitted Users policy is All users may self-authorize. What is the cause?

- A. Salesforce doesn't invoke authorize when users can self-authorize; Permitted Users must be Admin approved users are pre-authorized.
- B. The execution user lacks the Modify All Data permission, so Salesforce ignores the value that the handler returns.
- C. The authorize method runs only during refresh token exchanges, so it doesn't run when consultants first open the app.
- D. The handler must also override customAttributes, because Salesforce runs authorize only after it evaluates the connected app's custom attributes.

**Correct answer:** A. Salesforce doesn't invoke authorize when users can self-authorize; Permitted Users must be Admin approved users are pre-authorized.

**Explanation:** The ConnectedAppPlugin authorize method authorizes a user for the connected app when the app requires admin approval, and Salesforce documents that it isn't invoked when the connected app is set for users to self-authorize. Changing Permitted Users to Admin approved users are pre-authorized makes Salesforce call the method, which receives isAdminApproved from the user's profile or permission set access. No Modify All Data requirement causes the return value to be ignored. The refresh method, not authorize, is called during refresh token exchanges. The customAttributes method is independent of authorization.

**Sources:** [ConnectedAppPlugin Class](https://developer.salesforce.com/docs/atlas.en-us.apexref.meta/apexref/apex_class_Auth_ConnectedAppPlugin.htm), [Manage OAuth Access Policies for a Connected App](https://help.salesforce.com/s/articleView?id=xcloud.connected_app_manage_oauth.htm&language=en_US&type=5)

### Question 13

Universal Containers assigned a login flow to its Operations profile. The flow checks each user's location with a geo-fencing service and logs out anyone outside approved countries. An audit shows that Operations users still connect from blocked countries through Data Loader and through a custom integration that authenticates with the SOAP API login call. What is the cause?

- A. The login flow was built in Flow Builder, and only Visualforce login flows can evaluate API logins.
- B. Login flows run only for users who log in through SAML single sign-on or an authentication provider.
- C. Login flows apply only when users log in to an Experience Cloud site, not to the internal org.
- D. Login flows can't be applied to API logins, so logins through the API bypass the flow.

**Correct answer:** D. Login flows can't be applied to API logins, so logins through the API bypass the flow.

**Explanation:** Salesforce doesn't apply login flows to API logins or to sessions passed to the UI through frontdoor.jsp from a non-UI login process, so Data Loader and SOAP API logins never enter the flow. To control those logins, the architect could use login IP ranges on the profile or, with the Event Monitoring add-on or Shield, a transaction security policy on LoginEvent, which supports the Block action. Flows built in Flow Builder and Visualforce behave the same way for API logins. Login flows support username and password, delegated authentication, SAML, and authentication provider logins, and they apply to both orgs and Experience Cloud sites.

**Sources:** [Custom Login Flows](https://help.salesforce.com/s/articleView?id=xcloud.security_login_flow.htm&language=en_US&type=5), [Transaction Security](https://help.salesforce.com/s/articleView?id=xcloud.enhanced_transaction_security_policy_types.htm&language=en_US&type=5)

## Salesforce Identity (12%)

### Question 14

Cloud Kicks has moved all user provisioning and single sign-on from Identity Connect to a new identity platform, and every user now authenticates through the new platform. What should the identity architect include in the Identity Connect decommissioning plan?

- A. Leave the Identity Connect service running in read-only mode on its server so that it can be reactivated if the new platform fails.
- B. Remove Identity Connect from every server it's installed on, delete the downloaded binaries, and remove the Identity Connect managed package from the orgs.
- C. Reassign the Identity Connect integration user to the new identity platform so that its existing permissions and data access carry over without any changes.
- D. Keep the Identity Connect managed package installed, because the Salesforce SCIM endpoints that the new platform calls depend on it.

**Correct answer:** B. Remove Identity Connect from every server it's installed on, delete the downloaded binaries, and remove the Identity Connect managed package from the orgs.

**Explanation:** Salesforce's retirement guidance says that after a new provisioning tool is selected, users are migrated, and Identity Connect is replaced, customers must remove Identity Connect from any installed server and delete downloaded binaries, and Salesforce recommends removing the Identity Connect managed package from the orgs. Leaving a retired service running as a fallback keeps an unsupported component in the environment and contradicts that guidance. Salesforce recommends using the Identity Connect integration user only for Identity Connect, and least privilege calls for a dedicated user for each integration. SCIM is Salesforce's standard REST-based provisioning implementation, available in all editions, and doesn't depend on the Identity Connect package.

**Sources:** [Identity Connect Retirement](https://help.salesforce.com/s/articleView?id=000390663&language=en_US&type=1), [Manage Salesforce User Identities with SCIM](https://help.salesforce.com/s/articleView?id=xcloud.identity_scim_overview.htm&language=en_US&type=5)

### Question 15

Ursa Major Solar works with 150 installer partner companies. Some installers have 3 site users and others have 35, and headcounts change often. Finance wants to license the partner site per partner company instead of tracking individual users, and installers need leads and opportunities. Which license should the identity architect recommend?

- A. Partner Community member-based licenses
- B. Channel Account licenses
- C. Customer Community Plus Login licenses
- D. External Identity licenses

**Correct answer:** B. Channel Account licenses

**Explanation:** Channel Account licenses are optimized for partners and let a company buy a specific number of licenses for its partner accounts; each partner account with an assigned license gets up to 40 partner users, and user licenses are pooled, so usage is based on the number of partners rather than individual users. Partner Community member-based licenses require one license per user, which finance wants to avoid. Customer Community Plus doesn't include leads and opportunities. External Identity delivers identity services and doesn't include partner sales objects.

**Sources:** [Experience Cloud User Licenses](https://help.salesforce.com/s/articleView?id=sf.users_license_types_communities.htm&language=en_US&type=5)

## Community (Partner and Customer) (18%)

### Question 16

A developer at Ursa Major Solar is writing an Apex registration handler for the OpenID Connect authentication provider that installer partners use to log in to the company's partner Experience Cloud site. The developer asks the identity architect what the handler must take care of. Which two responsibilities should the architect describe? Choose 2 answers.

- A. Find or create the installer's account and contact records and associate the new user with the contact, because the handler owns any associated account and contact records.
- B. Update the existing user's information in updateUser, which runs when a user who has logged in with the provider before logs in again.
- C. Insert the new user with DML in createUser, because Salesforce doesn't insert the User object that createUser returns.
- D. Trust every claim in the ID token without validation, because Salesforce validates the ID token before it calls the handler.
- E. Request the provider's access token in the handler, because Auth.AuthToken can't return tokens for users who log in through a registration handler.

**Correct answers:** A. Find or create the installer's account and contact records and associate the new user with the contact, because the handler owns any associated account and contact records.; B. Update the existing user's information in updateUser, which runs when a user who has logged in with the provider before logs in again.

**Explanation:** The Apex Reference says a class that implements Auth.RegistrationHandler must perform the logic of creating and updating user data, including any associated account and contact records, which is essential for partner users because they must be linked to a contact. updateUser is called when a user who has logged in before with the authentication provider logs in again. When createUser returns a new User object, Salesforce inserts the user record for you, so the handler doesn't need its own insert. Salesforce stores the ID token but doesn't validate it; to rely on its claims, the handler should validate it with Auth.JWTUtil. After authentication, the provider's access token for the user can be retrieved with the Auth.AuthToken class.

**Sources:** [RegistrationHandler Interface](https://developer.salesforce.com/docs/atlas.en-us.apexref.meta/apexref/apex_auth_plugin.htm), [Configure Your Experience Cloud Site as a Service Provider or Relying Party](https://help.salesforce.com/s/articleView?id=external_identity_sso_sp.htm&type=5&language=en_US)

### Question 17

A web developer at Get Cloudy Consulting adds the Embedded Login meta tags and script to a page on the firm's website. In every browser, the login form fails to load, and the console shows an error containing "an ancestor value violates the following Content Security Policy directive." What should the Salesforce administrator do?

- A. Add the website's URL to Remote Site Settings so that Salesforce can call the website.
- B. Add the website's origin to the CORS allowlist in Setup, as Embedded Login requires.
- C. Add the website's IP range to the Login IP Ranges on the site's customer profile.
- D. Set the salesforce-use-min-js meta tag to false so that the script loads correctly.

**Correct answer:** B. Add the website's origin to the CORS allowlist in Setup, as Embedded Login requires.

**Explanation:** Salesforce's Embedded Login considerations say that if you get an error containing "an ancestor value violates the following Content Security Policy directive," you configure CORS as described in Step 1 of the setup. Embedded Login makes web requests across domains, so the admin adds the website's origin to the CORS allowlist; without it, the Access-Control-Allow-Origin header is null, which blocks the requests. Remote Site Settings authorize outbound callouts from Salesforce, which isn't what fails here. Login IP ranges restrict where users can log in from and don't affect cross-origin requests. The salesforce-use-min-js tag only switches between minimized and readable JavaScript.

**Sources:** [Embedded Login Considerations](https://help.salesforce.com/s/articleView?id=sf.external_identity_login_considerations.htm&language=en_US&type=5), [Step 1: Enable Resource Sharing Across Domains](https://help.salesforce.com/s/articleView?language=en_US&id=xcloud.external_identity_login_step_1.htm&type=5)

### Question 18

Ursa Major Solar has one Aura-based Experience Cloud site that serves both homeowners and installer partners. Marketing wants partners to see different colors, images, and fonts than homeowners, without building separate pages or writing CSS for each group. What should the identity architect recommend?

- A. Create a second theme and use a login flow to activate it whenever a partner logs in.
- B. Create a branding set for partners in Experience Builder and assign it to a partner audience, leaving the default branding set for everyone else.
- C. Clone the site for partners, because Experience Builder branding always applies the same way to every visitor of a site.
- D. Point the Right Frame URL on the Login & Registration page to a partner-specific stylesheet.

**Correct answer:** B. Create a branding set for partners in Experience Builder and assign it to a partner audience, leaving the default branding set for everyone else.

**Explanation:** Branding sets are bundles of colors, images, and fonts managed in Experience Builder's Theme panel, and in Aura sites they can be assigned to audiences so that, for example, customers see one look and partners another. Visitors who don't match an assigned audience see the default branding set, and audiences with record-based criteria can't be used for branding sets. Activating a theme applies to the whole site for everyone, and a login flow isn't a mechanism for switching themes per user. Cloning the site doubles maintenance and isn't needed because audience-based branding exists. The Right Frame URL only displays content in an iframe next to the login form; it doesn't restyle the site.

**Sources:** [Assign an Audience to a Branding Set](https://help.salesforce.com/s/articleView?id=experience.networks_audiences_branding_sets.htm&language=en_US&type=5), [Prebuilt Experience Builder Themes](https://help.salesforce.com/s/articleView?id=sf.community_designer_brand.htm&language=en_US&type=5)

## Related pages

- [Salesforce Identity and Access Management Architect practice exam](https://www.certifyforce.com/salesforce-identity-access-management-architect-practice-exam)
- [Practice exam packs](https://www.certifyforce.com/practice-exams)
- [Official Identity and Access Management Architect exam guide](https://help.salesforce.com/s/articleView?id=005298975&language=en_US&type=1)