B.   Set trusted IP ranges for the organization.

Explanation:

The identity architect needs to reduce the frequency of identity verification prompts for users logging into Salesforce. Salesforce’s identity verification prompts are typically tied to Multi-Factor Authentication (MFA) or other security policies that trigger based on factors like IP address, device, or session context. Let’s evaluate each option:

A. Implement 2FA authentication for the Salesforce org: Incorrect.
Two-Factor Authentication (2FA) is an outdated term for Salesforce, now replaced by Multi-Factor Authentication (MFA), which requires users to provide a second factor (e.g., authenticator app, security key) at login. Implementing 2FA/MFA would increase verification prompts, not reduce them, as it mandates additional verification steps for all users.

B. Set trusted IP ranges for the organization: Correct.
Salesforce triggers identity verification (e.g., MFA prompts or email verification) when users log in from unrecognized or untrusted IP addresses. By setting trusted IP ranges (e.g., corporate network IPs) in Salesforce’s Network Access settings, the architect can exempt users logging in from these IPs from frequent verification prompts. This reduces the frequency of MFA or identity verification challenges for users within the trusted network, meeting the requirement while maintaining security.

C. Implement a single sign-on for Salesforce using an external identity provider: Incorrect.
Single Sign-On (SSO) with an external Identity Provider (IdP) allows users to authenticate via the IdP and access Salesforce without re-entering credentials. However, SSO does not inherently reduce identity verification prompts, as MFA or verification policies can still apply at the IdP or Salesforce level. Additionally, implementing SSO introduces complexity and may not address verification frequency unless the IdP’s policies are specifically configured to reduce prompts, which is not implied here.

D. Implement multi-factor authentication for the Salesforce org: Incorrect.
Salesforce has required MFA for all users since February 1, 2022, so it’s likely already in place. Enabling MFA would increase verification prompts (e.g., requiring authenticator codes), not reduce them, as it enforces additional authentication steps for security.

Why B:
Setting trusted IP ranges allows Salesforce to recognize logins from specified IP addresses (e.g., corporate offices) as trusted, bypassing MFA or identity verification prompts for those sessions. This directly reduces the frequency of prompts for users within the trusted network, aligning with the requirement while maintaining security for external access.

References:
Salesforce Help: Set Trusted IP Ranges
Salesforce Help: Multi-Factor Authentication Overview
Trailhead: Secure Your Users’ Identity

A.   OpenID Connect

Explanation:

The key requirement is that "user attributes need to be returned to the wellness application in an ID token." This is the exact purpose of the OpenID Connect (OIDC) protocol.

A. OpenID Connect:
OpenID Connect is a simple identity layer built on top of the OAuth 2.0 protocol. Its primary function is to authenticate users and provide client applications with verifiable information about the user in the form of an ID Token. The ID Token is a JSON Web Token (JWT) that contains claims (attributes) about the user, such as name, email, and subject identifier. This is precisely what is needed for the wellness application to receive user attributes.

Why the other options are incorrect:
B. User Agent Flow:
This is an OAuth 2.0 flow (the Implicit Flow), not an authentication protocol itself. OAuth 2.0 is designed for authorization (granting access to resources) and does not define a standard way to return user information. While you could later call an API to get user info, OAuth itself does not provide an ID token. OpenID Connect extends OAuth 2.0 to provide authentication and the ID token.
C. JWT Bearer Token Flow:
This is an OAuth 2.0 flow used for server-to-server authentication where there is no user context. It is used to obtain an access token, but it does not return an ID token containing user attributes. It is not designed for a user-facing application like a wellness portal.
D. Web Server Flow:
This is another OAuth 2.0 flow (the Authorization Code Flow). Like the User Agent Flow, it is used for authorization and results in an access token. The access token can then be used to call the Salesforce UserInfo endpoint to retrieve attributes, but this is a two-step process. The key distinction is that OAuth 2.0 flows do not natively provide an ID Token; that is the specific innovation of OpenID Connect. While OIDC often uses the Web Server Flow, the protocol enabling the ID token is OIDC itself.

Architectural Consideration:
OpenID Connect is the modern standard for federated identity in web and mobile applications. It provides a standardized way to obtain basic user profile information in a secure and verifiable manner, which is ideal for a scenario like a wellness app that needs to know who the user is.

Reference:
OpenID Connect Specification: The core specification defines the ID Token as a JSON Web Token that contains Claims about the Authentication event.

B.   Require High Assurance sessions in order to use the Connected App.

D.   Use Google Authenticator as an additional part of the login process

Explanation:

The goal is to increase security for a custom mobile app accessed by users who are outside the corporate network.

B. Require High Assurance sessions in order to use the Connected App:
In Salesforce, you can configure Session Policies for a Connected App.
By requiring a "High Assurance" session, you force users to have already authenticated with a higher level of security (like Multi-Factor Authentication) before being granted access to the connected app. This is a best practice for securing access to a specific, high-risk application.
D. Use Google Authenticator as an additional part of the login process:
Google Authenticator is a common Time-based One-Time Password (TOTP) application used to implement Multi-Factor Authentication (MFA).
MFA is a fundamental security requirement and best practice, as it requires the user to provide two or more verification factors, which is critical for users accessing the system from mobile devices outside the secure corporate perimeter. This recommendation directly addresses the need for a properly secured login process.

Why the Other Options are Less Appropriate
A. Disallow the use of Single Sign-on for any users of the mobile app:
SSO can be a secure authentication method, especially when paired with strong controls like MFA. Disallowing it unnecessarily adds complexity for users and doesn't inherently make the application more secure than a properly configured SSO with MFA.
C. Set Login IP Ranges to the internal network for all of the app users Profiles:
This is not a viable solution for a mobile app used by employees who are "commonly out of the office." Since their IP addresses will constantly change (using mobile data, Wi-Fi hotspots, etc.), restricting login IP ranges to the internal network would effectively block most of their access. IP restriction in the connected app settings is more flexible, but locking it down to a single internal network is counterproductive for a mobile workforce.

B.   The Federation ID must is case sensitive

D.   The Federation ID must be populated on the user record.

Explanation:

In a multi-org SAML-based SSO setup, Salesforce uses the Federation ID to match the incoming SAML assertion to the correct user record. If a user can log in to the Identity Provider org but gets a generic SAML error when accessing other orgs, it likely means the assertion isn’t matching a user in the target org.

Here’s what the architect should review:

✅ B. The Federation ID is case sensitive
Salesforce treats the Federation ID as case sensitive, so mismatches in capitalization can cause login failures.
Ensure the value in the SAML assertion exactly matches the Federation ID on the user record.

✅ D. The Federation ID must be populated on the user record
If the Federation ID is missing, Salesforce cannot map the SAML assertion to a user.
This is a common cause of SAML errors in multi-org setups.

❌ A. The Federation ID must be a valid Salesforce Username
Incorrect — Federation ID is a separate field used for SAML mapping.
It does not need to match the Salesforce username.

❌ C. The Federation ID must be in the form of an email address
Incorrect — While it can be an email address, it’s not required.
It can be any unique string that matches the SAML assertion.

📘 Reference:
Salesforce Help: SAML SSO Configuration
Salesforce Developer Guide: Federation ID

D.   Use a Common Connected App Handler using Apex to dynamically allow access to the system based on whether the staff owns any open "Classified" Cases.

Explanation:

The requirement is for access to be granted or denied at the time of the SSO attempt, based on the current state of the user's case ownership. This necessitates a dynamic check during the authentication process.

D. Use a Common Connected App Handler using Apex: This is the correct and most powerful approach.
When you configure a Connected App in Salesforce (acting as the IdP) for SAML SSO, you can define an Apex class that implements the Auth.SamlJitHandler interface.
This class is known as a Just-in-Time (JIT) Provisioning Handler or a Connected App Handler.
This Apex class contains a method (createUser) that is executed every time a user attempts to log in via SAML to the external system (the classified information system).
Within this Apex method, you can write a SOQL query to check if the authenticating user currently owns any open cases with the "Classified" record type.
Based on the result of this query, the handler can dynamically allow or deny the login by either proceeding with the login or throwing an exception to block it.

Why the other options are incorrect:
A. Use Salesforce reports to identify users...
Reports are a static, batch-oriented tool. They cannot perform a real-time check at the moment a user tries to access the external system. There is no way to integrate a report into the SAML SSO flow to make an instantaneous access decision. This is a manual process, not an automated, real-time solution.
B. Use Apex trigger on case to dynamically assign permission Sets...
While this seems logical, it is not the right mechanism for this SSO scenario. Permission Sets control access within Salesforce, not to an external system that uses Salesforce as an IdP. The external system has no knowledge of Salesforce Permission Sets. Furthermore, there would be a delay between the case being assigned/closed and the trigger firing, creating a window where access is incorrect. The requirement is for access to be contingent on the exact moment of login.
C. Use Custom SAML JIT Provisioning to dynamically query...
This option is very close and is a good distractor. Standard JIT provisioning is used to create or update user records in Salesforce when they log in from an external IdP. In this scenario, Salesforce is the IdP, not the Service Provider. Therefore, the standard JIT provisioning mechanism does not apply. The correct hook is the Connected App Handler (option D), which serves a similar purpose but from the IdP side for controlling access to external apps.

Architectural Consideration:
The Connected App Handler pattern provides the necessary real-time, attribute-based access control. It allows the authorization decision (is the user actively working on a classified case?) to be embedded directly into the authentication flow. This is a secure and precise way to implement dynamic access policies for external applications.

Reference:
Salesforce Help: "Create a Connected App Handler for JIT Provisioning" - This documentation explains how to use an Apex class to control user creation and access during SAML SSO from Salesforce as the IdP. The logic can be extended to include custom authorization checks.

B.   Identity Verification Credits are consumed with each SMS (text message) sent and should be estimated based on the number of login verification challenges for SMS verification users.

Explanation:

Northern Trail Outfitters (NTO) is implementing passwordless login for their customer service portal, using one-time passcodes sent via email or SMS. Identity Verification Credits are a Salesforce add-on license specifically for SMS-based identity verification in features like passwordless login and MFA for external users. Let's evaluate each option:

A. Incorrect: There is no standard allocation of 10,000 Identity Verification Credits per community per month. Credits are purchased as an add-on and consumed per SMS sent, not bundled by community. Estimation is based on actual usage, not a fixed threshold for additional SMS.

B. Correct: Identity Verification Credits are consumed only with each SMS (text message) sent for verification challenges, such as one-time passcodes in passwordless login. Email verifications do not consume credits. To estimate, the architect should project the number of login attempts by users opting for SMS verification (e.g., based on historical data or expected user behavior), as each failed or prompted login could trigger an SMS. This aligns with Salesforce's usage-based model for SMS in Experience Cloud.

C. Incorrect: While verifications are tied to login challenges, credits are not consumed for each verification sent—only SMS ones. Email-based passcodes (a common passwordless option) do not use credits, so estimation cannot be based solely on total logins without distinguishing SMS usage.

D. Incorrect: Identity Verification Credits are not a direct add-on license tied to the quantity of member-based or login-based Community licenses. They are purchased separately based on expected SMS volume, not scaled to existing licenses.

Why B: For passwordless login, SMS is an optional verification method requiring credits per message sent during challenges. Estimating based on SMS-specific login verifications ensures accurate forecasting of consumption and costs, avoiding over- or under-provisioning.

Reference:
Salesforce Help: Identity Verification Credits Add-On License
Trailhead: Mobile-First Identity Experience
Salesforce Help: SMS Identity Verification

B.   Customer 360 Identity enables an organization to build a single login for each of its customers, giving the organization an understanding of the user's login activity across all its digital properties and applications.

C.   Customer 360 Identity supports multiple brands so you can deliver centralized identity services and correlation of user activity, even if it spans multiple corporate brands and user experiences.

Explanation:

How Customer 360 Identity Contributes to Truth
The goal of Customer 360 Truth is to create a single source of the truth for every customer. Customer 360 Identity is a fundamental component that powers this goal.

Unified Authentication (Single Login - B):
By creating a single login (e.g., through Single Sign-On or a unified registration process), Customer 360 Identity ensures that when a customer accesses any of UC's applications (website, mobile app, service portal), they are authenticated using the same, trusted identity record.
This identity record is assigned a unique identifier (like a Global Party ID - GPID), which then serves as the key to link and unify all the customer's behavioral and transactional data across disparate systems in the Customer 360 Data Manager. This is the bedrock of the "single source of truth."

Cross-Brand Identity Management (C):
In a multi-brand or multi-site organization like UC, customers might interact with several different digital properties (e.g., "NTO Outdoors" vs. "NTO Camping").

Customer 360 Identity centralizes the user authentication for all these brands. This means the system can confidently correlate activity across all experiences to the same unique customer profile, even if the branding is different. This ensures that the unified customer profile is complete, reflecting all interactions across the entire corporate family, which is critical for accurate "Truth."

Why the other options are incorrect:
A is incorrect: While Customer 360 Identity works with Data Manager and Audiences, it does not automatically integrate to "seamlessly populate all user data." Customer 360 Data Manager (or Data Cloud) is the component responsible for the heavy lifting of connecting, matching, reconciling, and ultimately unifying the data from all sources (including the Identity data).
D is incorrect: The core feature of tracking anonymous user activity prior to sign-up is primarily the function of Customer 360 Audiences (Salesforce's Customer Data Platform - CDP) and related data services, which unify known (authenticated) and unknown (anonymous) data. Customer 360 Identity focuses on the authenticated user experience (login, registration, security).

A.   Build an integration that performs a remote call-in to the Salesforce SOAP or REST API.

Explanation:

Northern Trail Outfitters wants to provision Salesforce users immediately upon approval in their custom on-premise helpdesk application, including assigning profiles and permission sets. The most direct and reliable way to achieve this is by building an integration that uses the Salesforce SOAP or REST API to:

Create new users in Salesforce
Assign the appropriate profile
Attach permission sets
Trigger notifications or workflows if needed

This approach allows real-time provisioning and full control over user attributes, and it can be securely initiated from the helpdesk system as soon as access is approved.

✅ Why A is Correct:
Salesforce APIs (SOAP or REST) support user creation and updates
Enables automated provisioning from external systems
Supports profile and permission set assignment
Ideal for custom workflows and enterprise-grade integrations

❌ Why the other options are incorrect:
🅱️ Use a login flow to query the helpdesk
Login flows run after the user logs in, not for initial provisioning
Doesn’t help with creating users or assigning access

🅲️ IdP-initiated JIT provisioning via SAML
JIT provisioning is triggered during SSO login, not from an external approval system
Limited control over complex access logic like permission sets

🅳️ Use Salesforce Connect
Salesforce Connect is for data integration, not user provisioning
It allows viewing external data in Salesforce, but not creating or managing users

📘 Reference:
Salesforce Developer Guide: REST API – Create User
Salesforce Help: SOAP API Overview

B.   Use a browser that has an add-on/extension that can inspect SAML.

C.   Paste the SAML Assertion Validator in Salesforce.

Explanation:

B. Use a browser that has an add-on/extension that can inspect SAML.
A SAML inspection tool (e.g., "SAML Tracer" for Firefox or "SAML Chrome Panel" for Chrome) is an invaluable resource for troubleshooting SAML-based SSO.
It allows the architect to view the SAML requests and responses as they are sent between the browser, the Identity Provider, and the Service Provider (Salesforce).
By inspecting the SAML assertion, the architect can identify common issues such as incorrect digital signatures, mismatched certificates, incorrect NameID formats, or invalid timestamps.
C. Paste the SAML Assertion Validator in Salesforce.
The Salesforce SAML Assertion Validator is a built-in tool that is essential for diagnosing SAML errors.
After an SSO login attempt fails, an administrator can navigate to the Single Sign-On Settings in Salesforce and click the "SAML Assertion Validator" button.
This tool shows the details of the last failed SAML operation, providing specific error messages and highlighting potential problems with the SAML assertion, such as certificate mismatches, audience restriction errors, or subject (Federation ID) mismatches.

Incorrect Answer Rationale:
A. Ensure the Callback URL is correctly set in the Connected Apps settings.
The term "Callback URL" is primarily associated with OAuth flows, where an authorization server redirects the user back to the client application after successful authentication. While the SAML configuration involves an "Assertion Consumer Service (ACS) URL," it is not called a "Callback URL" in this context. The connected app is involved in SAML configuration, but referring to the URL as a "Callback URL" is incorrect terminology.
D. Use the browser's Development tools to view the Salesforce page's markup.
While a browser's developer tools can be useful for debugging client-side issues, simply viewing the page's markup will not reveal the details of the SAML assertion or the underlying SSO communication. The SAML assertion is transmitted in a base64-encoded format, which is not easily readable in the standard page markup. A dedicated SAML inspection tool (as in option B) is required to decode and analyze the assertion.

Salesforce documentation:
Troubleshoot SAML Assertion Errors: An essential guide from Salesforce explaining how to use the SAML Assertion Validator and other troubleshooting techniques.
How to Troubleshoot a Single Sign-On Error: A comprehensive blog post detailing the step-by-step process of using the SAML Assertion Validator.
How to view SSO/SAML response using a Web browser in debug mode: Provides instructions for capturing SAML responses using browser tools.

C.   Configure an OpenID Connect Authentication Provider for Amazon.

Explanation:

Why:
“Login with Amazon” supports OpenID Connect (OIDC). In Salesforce, to let customers sign in with an external identity like Amazon on an Experience Cloud site, you configure an OIDC Auth Provider, add it to My Domain login options, and (optionally) use a registration handler to map/create users.

Why not the others:
A. There isn’t a predefined Amazon provider in Salesforce.
B. A “custom external auth provider” using generic OAuth 2.0 won’t return standardized identity claims as cleanly as OIDC; OIDC is the right protocol for social identity login.
D. A Connected App is for apps accessing Salesforce data (Salesforce as IdP/SP), not for letting users log into Salesforce with Amazon.

B.   Username and password + secunty key

C.   Third-party single sign-on with Mobile Authenticator app

E.   Lightning Login

Explanation:

Salesforce defines Multi-Factor Authentication (MFA) as requiring two or more distinct factors: something the user knows (like a password), and something the user has (like a mobile device or security key). To comply with Salesforce's MFA requirements, the second factor must be strong and phishing-resistant.

Here are the correct answers:

✅ B. Username and password + Security Key
This meets MFA criteria. Security keys (like YubiKey or FIDO2-compliant devices) are considered phishing-resistant hardware-based authenticators and are fully compliant with Salesforce's MFA requirements.

✅ C. Third-party Single Sign-On with Mobile Authenticator App
If your SSO provider supports MFA and enforces a second factor like TOTP-based mobile authenticator apps (e.g., Okta Verify, Microsoft Authenticator), it qualifies. Salesforce accepts SSO-based MFA when configured according to their guidelines.

✅ E. Lightning Login
Lightning Login allows users to log in with their username and approve the login from the Salesforce Authenticator app without a password. It combines "something the user has" (their trusted mobile device) and "something the user is" (device biometric), which meets Salesforce's MFA standard.

❌ A. Username and password + SMS passcode
SMS is not considered secure or compliant for MFA by Salesforce (and other standards bodies like NIST) due to its vulnerability to SIM swapping and interception.

❌ D. Certificate-based Authentication
While secure, certificate-based login alone does not meet Salesforce’s MFA criteria unless combined with another factor. It’s typically used for machine-to-machine authentication rather than user login.

B.   Build a custom visualforce page for both the change password and Forgot password experiences.

D.   Build a community builder page for both the change password and Forgot password experiences.

Explanation:

Universal Containers (UC) aims to implement a partner community using Salesforce Experience Cloud and customize the "Forgot Password" and "Change Password" experiences with custom branding for partner community users. The solution must leverage Salesforce’s capabilities to provide a branded, seamless user experience. Let’s evaluate each option:

A. Build a Community Builder page for the Change Password experience and Custom Visualforce page for the Forgot Password experience: Incorrect.
Salesforce’s Experience Builder (formerly Community Builder) does not natively support creating a custom "Change Password" page for Experience Cloud users. While Visualforce can be used for the "Forgot Password" experience, combining these approaches (Community Builder for one, Visualforce for the other) is inconsistent and not fully supported, as both experiences typically require the same customization method for consistency.

B. Build a custom Visualforce page for both the Change Password and Forgot Password experiences: Correct.
Salesforce allows customization of both the "Change Password" and "Forgot Password" pages using Visualforce pages in Experience Cloud. These pages can be fully branded (e.g., with UC’s logos, colors, and layouts) and configured in the Experience Cloud site settings (under Login & Registration) to replace the default Salesforce pages. This approach provides complete control over the user experience and is a standard, supported method for customizing password-related flows.

C. Build a custom Visualforce page for the Change Password experience and a Community Builder page for the Forgot Password experience: Incorrect.
Similar to option A, this approach is inconsistent. While Visualforce is supported for the "Change Password" page, Experience Builder does not natively support creating a custom "Forgot Password" page. Both experiences typically require the same customization method (e.g., Visualforce or Experience Builder) to ensure a cohesive user experience, making this option impractical.

D. Build a Community Builder page for both the Change Password and Forgot Password experiences: Correct.
In Salesforce Experience Cloud (as of Spring ‘25), Experience Builder allows administrators to create branded pages for login, registration, and password management, including "Change Password" and "Forgot Password" experiences. These pages can be customized with UC’s branding (e.g., themes, logos, layouts) using Experience Builder’s no-code/low-code tools. This approach is modern, user-friendly, and reduces development effort compared to Visualforce, making it a recommended option.

Why B and D:
B (Custom Visualforce pages) offers maximum flexibility for branding and custom logic via Visualforce and Apex, ideal for complex requirements or specific UC branding needs.
D (Community Builder pages) leverages Experience Builder’s native, no-code capabilities to create branded password management pages, simplifying implementation and maintenance. Both approaches meet UC’s branding requirements, with B suited for advanced customization and D for a streamlined, platform-native solution.

References:
Salesforce Help: Customize Login and Registration Pages for Experience Cloud Sites
Salesforce Help: Create Custom Login Pages with Visualforce
Trailhead: Experience Cloud Basics
Salesforce Help: Customize Password Management Pages