Salesforce-Platform-Identity-and-Access-Management-Architect Practice Test Questions

Explanation:

Why it’s correct (exam reasoning):
“Contactless users” let you create Experience Cloud users without a Contact (lightweight identity records). Salesforce documents that this capability is tied to the External Identity license. External Identity is focused on identity services (login/SSO, passwordless, self-registration, etc.), not full Experience Cloud object access; to get those features (Cases, Accounts, etc.), you must upgrade the user to a Community/Experience Cloud license.

Why the other options are wrong:
A. “Custom registration handler is needed … to assign license” — Not required. You can assign the External Identity license via standard Experience Cloud self-registration / admin flows; a custom handler is optional for bespoke provisioning logic. (Salesforce docs describe enabling/creating contactless users without mandating a custom handler.)
B. (the “automatic contact on upgrade” statement) — When you upgrade a contactless user to a Community license, there’s an administrative process (associate with an Account/Contact as appropriate); Salesforce does not state an automatic, account-less Contact is created for you. The official guidance frames this as a managed upgrade, not auto-creation. Salesforce
D. “Passwordless authentication cannot be supported … needs to match the number on the contact record.” — Passwordless login (email or phone OTP, WebAuthn, headless flows) is supported for Experience Cloud/External Identity users and relies on verification methods registered on the User, not on a Contact record.

References:
Metadata setting: UserManagementSettings — “If … your org has the External Identity license, you can create contactless users.”
Contactless users: create/manage/enable & upgrade notes.
External Identity license vs. Community features (upgrade to get Cases, etc.).

Explanation

To enable SP-initiated SSO with Salesforce as the Service Provider, two steps are required in Salesforce:

Option A is correct because configuring SAML SSO settings involves specifying the identity provider details, such as the entity ID, login URL, logout URL, and certificate2.

Option D is correct because setting up My Domain enables you to use a custom domain name for your Salesforce org and allows you to use SAML as an authentication method3.

Option B is incorrect because creating a connected app is not necessary for SP-initiated SSO using a SAML-compliant IdP. A connected app is used for OAuth-based authentication or OpenID Connect based authentication4.

Option C is incorrect because configuring delegated authentication is not related to SP-initiated SSO using a SAML-compliant IdP. Delegated authentication is a feature that allows Salesforce to delegate user authentication to an external service, such as LDAP or Active Directory5.

References:
SAML based single sign-on: Configuration and Limitations, Configure SAML single sign-on with an identity provider, My Domain, Create a Connected App, Configure Salesforce for Delegated Authentication.

Explanation:

Northern Trail Outfitters (NTO) needs a solution for employees who do not require access to Salesforce objects (e.g., standard or custom objects like Accounts or Cases) but must use their Salesforce credentials to sign in to a custom Benefits web app via Single Sign-On (SSO). The Identity Only License is the most appropriate choice for this scenario. Below is a detailed analysis of why A is correct and why the other options are not suitable.

A. Identity Only License (Correct)
Why Appropriate: The Identity Only License (previously known as Salesforce Identity License) is designed for users who need to use Salesforce as an Identity Provider (IdP) for SSO to external applications without accessing Salesforce objects or data. It allows:
Employees to authenticate using their Salesforce credentials (e.g., via SAML or OpenID Connect) to access the custom Benefits web app.
Configuration of Salesforce as the IdP, enabling secure SSO to external systems without granting access to Salesforce’s internal CRM functionality.
Support for identity features like MFA, user provisioning, and session management without requiring object-level permissions.
Fit for Scenario: Since the employees only need to sign in to the external Benefits web app and do not require Salesforce object access, this license provides the necessary identity services at a lower cost than full Salesforce licenses (e.g., Sales Cloud or Service Cloud licenses).
Architectural Impact: The identity architect should configure Salesforce as the IdP, set up a Connected App for the Benefits web app, and assign the Identity Only License to these employee User records. Ensure the Federation ID or username matches the external app’s expected identifier.
Reference: Salesforce Help: Salesforce Identity License.

B. External Identity License (Incorrect)
Why Not Suitable: The External Identity License is designed for high-volume, external users (e.g., customers or partners) accessing lightweight Experience Cloud sites or contactless user scenarios. It is not intended for internal employees and is limited to specific use cases like self-registration or guest access. While it supports SSO, it’s not cost-effective or appropriate for employees, as it restricts functionality and is tailored for external user communities.
Clarification: This license would be relevant if NTO were enabling SSO for customers on an Experience Cloud portal, not for internal employees accessing a custom app.
Reference: Salesforce Help: External Identity License.

C. Identity Verification Credits Add-on License (Incorrect)
Why Not Suitable: The Identity Verification Credits Add-on License is used for purchasing additional credits for identity verification methods, such as SMS-based MFA or push notifications, typically for External Identity users. It is not a standalone user license and does not provide SSO capabilities or user authentication on its own. It’s irrelevant for enabling employees to access an external app with Salesforce credentials.
Clarification: This add-on might be used in conjunction with another license for enhanced security (e.g., MFA for the Benefits app), but it doesn’t fulfill the core requirement.
Reference: Salesforce Help: Identity Verification.

D. Identity Connect License (Incorrect)
Why Not Suitable: The Identity Connect License is specific to Salesforce Identity Connect, a tool for synchronizing user data between Salesforce and Microsoft Active Directory (AD) for SSO and user management. It is not a general-purpose user license for SSO to external apps. It’s used for integrating AD with Salesforce, not for employees accessing a custom web app without Salesforce object access.
Clarification: If NTO were syncing employee identities from AD to Salesforce, Identity Connect might be considered, but the scenario specifies using Salesforce credentials directly for SSO, not AD integration.
Reference: Salesforce Help: Identity Connect Overview.

Additional Notes
Implementation Steps: To set up SSO for the Benefits web app:
Assign Identity Only Licenses to the employee User records in Salesforce.
Configure Salesforce as the IdP (Setup > Identity > Identity Provider).
Create a Connected App in Salesforce for the Benefits web app, specifying the SAML or OpenID Connect settings.
Ensure the external app is configured to trust Salesforce as the IdP and map user attributes (e.g., Federation ID).
Test the SSO flow in a sandbox to verify seamless authentication.
Security Considerations: Enable MFA for these users to enhance security, as the Identity Only License supports it. Ensure the Benefits app supports SAML or OpenID Connect for compatibility with Salesforce’s IdP.
Trailhead Reference: For further study, see Trailhead: Salesforce as an Identity Provider.

This solution ensures NTO’s employees can securely access the Benefits web app using Salesforce credentials without unnecessary access to Salesforce data, aligning with cost and security best practices.

Explanation:

Just-in-Time (JIT) provisioning is a built-in Salesforce feature designed specifically for this scenario. When an external identity provider (IdP) is used for authentication, JIT provisioning allows Salesforce to automatically create a user account the first time a user successfully authenticates with the IdP.

Here's how it works in this context:
A customer attempts to log in to the Experience Cloud site.
They are redirected to UC's third-party SSO solution (the IdP).
The user authenticates successfully with the IdP.
The IdP sends a SAML assertion (or similar token) back to Salesforce.
Salesforce receives the assertion. If a user with the unique identifier from the assertion does not already exist, Salesforce uses the information in the assertion (like username, email, first name, last name) to automatically create a new user record on the fly.
The user is then logged in. This entire process happens seamlessly without any manual intervention.
JIT provisioning is the recommended solution because it is:
Native: It's a standard, supported feature that requires no custom code.
Efficient: It eliminates the need for a separate user synchronization process.
Secure: The provisioning is tied directly to a successful authentication event.

Why the other options are incorrect:
B. Custom middleware and web services:
This is an overly complex and unnecessary solution. While it is technically possible to build a custom service that uses the Salesforce API to create users, it introduces additional points of failure, requires maintenance, and is not needed when a built-in, purpose-built feature like JIT exists.
C. Custom login flow and Apex handler:
Login Flows and Apex handlers are powerful for customizing the authentication experience (like collecting additional information post-login) or for complex logic that JIT cannot handle. However, for the basic requirement of automatic user creation upon first SSO login, JIT provisioning is the standard and simpler solution. Using a custom login flow for this would be "re-inventing the wheel."
D. Third-party AppExchange solution:
While an AppExchange solution might exist, it would be redundant. JIT provisioning is the native, out-of-the-box way to solve this exact problem. Recommending a third-party tool when a robust, free, native feature is available would not be architecturally sound.

Reference:
Salesforce Help: Just-in-Time User Provisioning - This documentation explains how JIT provisioning works with SAML and OpenID Connect, confirming it's the standard method for automatically creating user records during SSO.

Explanation:

This scenario requires a centralized authentication mechanism where Salesforce acts as the source of truth for user identities. A connected app is the cornerstone of this solution.
Connected App and OAuth: A Connected App is the key component for integrating external applications with Salesforce. By using OAuth, the mobile app can securely request access to Salesforce data on behalf of the user without needing to store their credentials. This establishes the initial trust relationship and provides the necessary tokens for API access.
Salesforce as Identity Provider (IdP): Once the user authenticates with Salesforce, the platform can then act as a SAML Identity Provider for other non-Salesforce applications. The mobile app, after receiving a successful login token from Salesforce via OAuth, can then use that established session to seamlessly access other applications. The app essentially gets a "ticket" from Salesforce which it can present to the other services. This is a classic Single Sign-On (SSO) pattern.
Mobile App Settings: The Connected App's settings can be configured specifically for mobile apps to enforce policies such as inactivity timeouts, session locking, and even remote wipe capabilities, which are crucial for corporate-distributed mobile apps. This provides the necessary security controls for a privately distributed application.

Why the other options are incorrect:
A. Use connected app with OAuth and Security Assertion Markup Language (SAML) to access other non-Salesforce internal apps. This is partially correct, but it's not the most precise or complete answer. While a connected app and OAuth are used, the flow for accessing the other non-Salesforce apps would be a separate SAML flow where Salesforce acts as the IdP. The option suggests a mixed use of both for the non-Salesforce apps, which is not the standard or most efficient architecture.
C. Use Salesforce as an identity provider (IdP) to access the mobile app and use the external IdP for other non-Salesforce internal apps. This option is incorrect because the user is authenticating with Salesforce first, meaning Salesforce is the initial IdP for the mobile app itself. The question states that the other non-Salesforce apps are accessed after the user authenticates with Salesforce, reinforcing the need for Salesforce to be the IdP for all of the connected services.
D. Create a new hybrid mobile app and use the connected app with OAuth to authenticate users for Salesforce and non-Salesforce internal apps. The prompt specifies a "native iOS mobile app," so a hybrid app is not the correct solution. More importantly, while a connected app and OAuth are used for Salesforce authentication, they don't directly handle authentication for other non-Salesforce apps; that's the role of Salesforce as the IdP via SAML.

Explanation:

In a SAML-based Single Sign-On (SSO) setup, the Identity Provider (IdP) is responsible for authenticating the user and then creating a SAML assertion (token) that contains the user's identity and attributes. This token is then sent to the Service Provider (SP), which consumes it to grant access.

Here’s how it works:
The user attempts to access a service (SP).
The SP redirects the user to the IdP for authentication.
The IdP authenticates the user and creates a SAML token (assertion).
The token is sent back to the SP.
The SP consumes the token and grants access.

❌ Why the other options are incorrect:
A. Validate token – This is the role of the Service Provider, which validates the token received from the IdP.
C. Consume token – Also the role of the Service Provider, not the IdP.
D. Revoke token – SAML tokens are not revocable; they are short-lived and used once per session.

📚 Reference:
Salesforce Help: SAML SSO Overview
Auth0 Docs: SAML Explained

Explanation:

B. Create authentication providers for both Facebook and LinkedIn:
To enable social sign-on, Salesforce must be configured to trust an external service. This is done by creating an authentication provider record in Salesforce for each external identity provider (Facebook and LinkedIn in this case). This record stores information such as the consumer key and consumer secret, allowing Salesforce to delegate authentication to the social media service.
C. Check "Facebook" and "LinkedIn" under Login Page Setup:
After creating the authentication providers, you must explicitly enable them for your Experience Cloud site. This is done in the site's "Login & Registration" administration settings by selecting the checkboxes for the newly created authentication providers.
E. Update the default registration handlers to create and update users:
When a customer logs in for the first time, Salesforce needs to know how to create their user record. An Apex registration handler defines this logic, mapping the information received from the social media provider (like name and email) to a new Salesforce user. The handler also handles subsequent logins, updating the user record as needed. While Salesforce can automatically generate a basic handler, you often need to update it for your specific requirements.

Explanation of the Incorrect Answers
A. Register both Facebook and LinkedIn as connected apps:
A connected app is used when Salesforce is the identity provider (IdP) for an external application. In this scenario, Facebook and LinkedIn are the IdPs, and Salesforce (specifically the Experience Cloud portal) is the service provider (SP).
D. Enable "Federated Single Sign-On Using SAML":
SAML is a standard for exchanging authentication data, but it is not the protocol used for integrating with social media providers like Facebook and LinkedIn. These integrations are typically based on the OpenID Connect and OAuth 2.0 protocols, which are configured via Authentication Providers. Federated SSO using SAML is a separate feature.

Explanation:

Why B fits the requirements
UC must authenticate to Salesforce with mainframe credentials and can’t use SAML. The Salesforce feature for this is Delegated Authentication (DA), which hands username/password verification to an external web service (your mainframe).
On-the-fly user creation via SAML JIT isn’t possible here because SAML isn’t available. The practical pattern is to provision users via API (SOAP/REST or SCIM) from the mainframe when they’re created/first enabled there, and then rely on DA at login time to validate their password against the mainframe.

Why the others are not
A. Login Flow callout — Login Flows run after Salesforce has identified a valid user and authenticated them; they can’t authenticate against the mainframe for a user who doesn’t exist yet, so they can’t create the user “on first login.”
C. JIT on the mainframe — Salesforce JIT user provisioning is a Salesforce-side feature that’s triggered by SAML/OIDC assertions into Salesforce. With no SAML/OIDC, you can’t use JIT.
D. OAuth User-Agent Flow + Registration Handler — Registration Handlers are used with Auth Providers (SAML/OpenID Connect) for inbound login to Salesforce. The OAuth User-Agent flow described here is for Salesforce acting as an authorization server for connected apps, not for logging into Salesforce from an external IdP.

Implementation tip (typical pattern)
Mainframe HR/identity system creates or enables a worker → provision a Salesforce User via API (SOAP/REST/SCIM) with the right Profile/Permission Sets.
Enable Delegated Authentication and point it to your mainframe validation service so Salesforce defers password checks to the mainframe at login time.

Explanation:

Universal Containers (UC) wants to use Salesforce Identity to control access to a custom time tracking app for its employees, implying that Salesforce will act as the Identity Provider (IdP) to authenticate users and enable Single Sign-On (SSO) to the external app. The employees need to use their Salesforce credentials to access the custom app without requiring access to Salesforce objects or data. The Identity Only License is the most appropriate choice to meet this requirement at a minimum. Below is a detailed analysis of why C is correct and why the other options are not suitable.

C. Identity Only License (Correct)
Why Appropriate: The Identity Only License (previously known as Salesforce Identity License) is designed for users who need to authenticate via Salesforce as an IdP to access external applications (like the custom time tracking app) without accessing Salesforce CRM objects or data. It provides:
SSO capabilities using protocols like SAML or OpenID Connect, allowing employees to log in to the custom app with their Salesforce credentials.
Identity management features such as user provisioning, MFA, and session management without granting access to Salesforce objects (e.g., Accounts, Opportunities).
Cost-effective licensing for employees who only need identity services, not full Salesforce functionality.
Fit for Scenario: Since UC’s employees are internal users who only need to access the custom time tracking app via Salesforce Identity, the Identity Only License meets the requirement with minimal overhead. The architect would configure Salesforce as the IdP, set up a Connected App for the time tracking app, and assign Identity Only Licenses to the employee User records. Implementation:
Enable Salesforce as an IdP (Setup > Identity > Identity Provider).
Create a Connected App in Salesforce for the time tracking app, specifying SAML or OpenID Connect settings.
Assign Identity Only Licenses to users and map their Federation ID or username to the external app’s authentication requirements.
Reference: Salesforce Help: Salesforce Identity License.

A. Identity Verification (Incorrect)
Why Not Suitable: Identity Verification is not a standalone license but an add-on feature (e.g., Identity Verification Credits) used to enable advanced verification methods like SMS-based MFA or push notifications, typically for External Identity users. It does not provide user authentication or SSO capabilities on its own and is not sufficient to control access to an external app. It might complement the Identity Only License for enhanced security (e.g., MFA), but it doesn’t meet the core requirement.
Clarification: This option is irrelevant for enabling SSO to a custom app.
Reference: Salesforce Help: Identity Verification.

B. Identity Connect (Incorrect)
Why Not Suitable: Identity Connect is a specific tool for synchronizing user data between Salesforce and Microsoft Active Directory (AD) to enable SSO and user management. It is not a user license and is not required for employees to access a custom app using Salesforce Identity.
Identity Connect would be relevant if UC were integrating mainframe or AD credentials with Salesforce, but the scenario specifies leveraging Salesforce Identity directly.
Clarification: Identity Connect is a middleware solution, not a license for user access or SSO.
Reference: Salesforce Help: Identity Connect Overview.

D. External Identity (Incorrect)
Why Not Suitable: The External Identity License is designed for high-volume, external users (e.g., customers or partners) accessing Experience Cloud sites or lightweight portals, often with contactless user capabilities. It is not intended for internal employees, as it restricts functionality to basic community features and is not optimized for employee SSO to custom apps. Using External Identity for employees would be inappropriate and likely more restrictive than needed.
Clarification: This license is suited for customer-facing portals, not internal employee apps.
Reference: Salesforce Help: External Identity License.

Additional Notes
Implementation Steps:
Assign Identity Only Licenses to employee User records in Salesforce.
Configure Salesforce as the IdP (Setup > Identity > Identity Provider) and enable the appropriate protocol (SAML or OpenID Connect).
Create a Connected App in Salesforce for the time tracking app, specifying the SSO protocol and settings (e.g., SAML Assertion Consumer Service URL or OAuth endpoints).
Ensure the time tracking app is configured to trust Salesforce as the IdP and map user attributes (e.g., Federation ID or email).
Test the SSO flow in a sandbox to verify authentication and session handling.

Security Considerations:
Enable MFA for employees using the Identity Only License to enhance security, as it’s supported and aligns with best practices.
Validate that the time tracking app supports SAML or OpenID Connect for compatibility with Salesforce’s IdP.
Use secure attribute mapping (e.g., Federation ID) to prevent account linking issues.

Architectural Impact:
The Identity Only License minimizes licensing costs by avoiding full Salesforce licenses (e.g., Sales Cloud) for employees who don’t need CRM access.
Ensure the custom app’s authentication endpoints are scalable and secure (e.g., using TLS).
Trailhead Reference: Trailhead: Salesforce as an Identity Provider.

Explanation:

The External Identity license is specifically designed for this type of use case. It allows for high-volume external users (like customers) to perform identity-centric functions without needing a full or even a partial CRM license.

Here's a breakdown of why it's the right choice:
External Users: The scenario involves customers, not internal employees, which immediately points to an external-facing license.
External Authentication: The prompt states customers are logging in using external providers like Facebook and Google. The External Identity license is built to handle social sign-on and other authentication protocols like SAML and OAuth 2.0.
App Launcher Access: A key requirement is that customers need to access an "off platform application" via the Salesforce App Launcher. The External Identity license provides access to the App Launcher, enabling users to launch connected apps and other integrated services.
No CRM Data Access: The prompt mentions that customers use Salesforce to track order status and access an external label generator. This suggests a limited scope of access, primarily for identity management and launching external apps, rather than needing full access to standard Salesforce objects like accounts, contacts, or opportunities. The External Identity license is a cost-effective solution because it provides these identity services without the additional overhead of a full Experience Cloud license.

Why the other options are incorrect:
A. Customer Community license: This license is intended for customers who need to access and collaborate on Salesforce objects like cases, knowledge articles, and accounts. While it supports social sign-on, it provides more data access than is required by the problem statement, making it a more expensive solution than necessary.
B. Identity license: The Identity Only license is for internal employees who don't need access to standard Salesforce CRM functionality but require a Salesforce identity for SSO to other internal apps. It is not for external customers.
C. Customer Community Plus license: This license is an upgrade from the standard Customer Community license, providing even more advanced features like roles, delegated administration, and reporting. It is significantly more than what is needed for this scenario.