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

Explanation:

To enforce two-factor authentication (2FA) only when users log in from outside the internal company network, you need dynamic control based on the user's IP address. Salesforce's Custom Login Flow feature provides exactly that flexibility.
By writing an Apex login flow, you can inspect the incoming IP address—comparing it against internal IP range criteria—and decide whether to require an extra 2FA step. This method is supported by Salesforce and is the recommended pattern for conditional authentication based on login context.

Option B, configuring login IP ranges under 2FA setup, doesn’t trigger selective 2FA; instead, it broadly restricts or allows login access.
Option C is invalid because triggers on UserLogin run after authentication, making them ineffective for gating 2FA during login.
Option D applies 2FA for all UI logins and uses IP ranges per profile to restrict access—rather than enforcing 2FA only for external network access. Therefore, the only viable, supported way is via a Custom Login Flow.

Explanation:

Universal Containers needs to enable self-registration for Partner Community users, capture custom data, and assign Profiles and Accounts based on that data. The solution must integrate with Salesforce’s self-registration process.

A. Incorrect:
Visualforce pages customize UI, not logic for assigning Profiles/Accounts. They’re outdated for Experience Cloud, which favors Lightning components.

B. Incorrect:
There’s no "Self Registration trigger." Triggers on User/Contact are not ideal for self-registration logic, as they run post-creation and can’t handle form data directly.

C. Correct:
Modifying CommunitiesSelfRegController allows capturing custom data and assigning Profiles/Accounts during registration. It’s a straightforward, native approach.

D. Correct:
A custom Apex controller offers full flexibility to handle complex logic for data capture and Profile/Account assignment, configured in Experience Cloud settings.

Why C and D:
Both leverage Apex to customize the self-registration process, with C using the standard controller for simpler needs and D offering a custom controller for complex logic.

References:
Salesforce Help: Customize Self-Registration
Apex Docs: CommunitiesSelfRegController
Trailhead: Experience Cloud Basics

Explanation:

Use Case: The requirement is to provide Single Sign-On (SSO) for a business-to-consumer (B2C) application using Salesforce Identity. This involves managing a large volume of external users (consumers/customers) who need to authenticate but typically do not require full access to core Salesforce CRM features like Sales or Service Cloud objects.

External Identity License:
The External Identity license (a component of Salesforce Customer Identity) is specifically designed for managing the identity and access of external users (customers, partners, consumers).
It enables key identity features such as Single Sign-On (SSO), self-registration, and multi-factor authentication (MFA) for these external users.
It provides a user record in Salesforce purely for identity management purposes, allowing the user to log in via Salesforce and then access the target B2C application (the Service Provider in the SSO flow).
This license is far more cost-effective and scalable for high-volume B2C scenarios compared to full CRM or even full Community licenses.

Why the other options are incorrect:
A. Identity Only: The "Identity Only" license is primarily designed for internal users (employees) who need access to identity services (SSO, App Launcher, MFA) but do not need a full Salesforce license (like Sales or Service Cloud). It is not the correct license for external (B2C) users.

B. Salesforce Platform: The "Salesforce Platform" license is for internal employees who need custom app functionality, but not the standard CRM apps. It is not intended for external B2C customers.

D. Partner Community: The "Partner Community" license is specifically for business-to-business (B2B) external users who need to collaborate with internal teams, access partner-specific data (Leads, Opportunities), and usually require a higher level of data access than a general B2C customer. It is overkill and inappropriate for a basic B2C identity-only use case.

Reference:
Salesforce Help Article: External Identity License Details
Snippet: "Salesforce Customer Identity is available when you purchase the External Identity license. You can purchase the External Identity license in blocks of active users. These users are typically consumers of your business, such as customers, purchasers, patients, partners, and dealers."
Snippet: "With Customer Identity, customers and partners can self-register, log in, update their profile, and securely access web and mobile apps with a single identity."
Trailhead Module: Experience Cloud User Licenses (The identity functions are typically deployed via Experience Cloud)
This module explains the different external licenses, clearly differentiating the scope of External Identity (focus on Authentication/SSO) from Customer Community and Partner Community licenses (focus on full data access and collaboration).

Explanation:

The key factor here is that Universal Containers has already invested in and built a custom 2FA system that is serving their on-premise applications. The requirement is to extend this existing investment to Salesforce, not to replace it. The most architecturally sound approach is to integrate the two systems.

D. Use custom login flows to connect to the existing custom 2fa system:
Salesforce provides a powerful and supported extensibility point called Authentication Providers and Apex Authentication Classes. This allows you to create a custom login flow that can call out to your external, on-premise 2FA system during the Salesforce login process. The user would enter their credentials in Salesforce, and then the custom authentication flow would hand off the verification to the existing 2FA system. This provides a unified 2FA experience for the user across both on-premise apps and Salesforce, leveraging the existing infrastructure.

Why the other options are incorrect:
A. Replace the custom 2fa system with salesforce 2fa for on-premise application and salesforce:
This is not a recommended solution. It would require UC to abandon their existing investment and re-architect their on-premise applications to use Salesforce's 2FA system, which may not be feasible or desirable. It creates unnecessary work and cost.

B. Use the custom 2fa system for on-premise applications and native 2fa for salesforce:
This creates a disjointed user experience. Users would have to use one method for on-premise apps and a completely different method for Salesforce. From an administrative standpoint, it also doubles the management overhead, as two separate 2FA systems need to be maintained.

C. Replace the custom 2fa system with an app exchange app that supports on-premise applications and salesforce:
While an AppExchange solution might be viable in some greenfield scenarios, it suffers from the same core drawback as option A: it requires UC to replace a system they have already built and that is currently working. This is typically more costly and complex than integrating the existing system.

Architectural Consideration:
The principle of "reuse over replacement" is important here. Leveraging existing, functioning systems reduces cost, complexity, and risk. Salesforce's extensible authentication framework is specifically designed for this kind of integration, allowing a custom identity provider to be plugged in seamlessly. This approach future-proofs the investment in the custom 2FA system.

Reference:
Salesforce Help: "Create an Authentication Provider" - This documentation explains how to create a custom authentication provider using an Apex class, which is the technical foundation for implementing this solution. The Auth.AuthProviderPluginClass interface allows you to integrate a custom external authentication system like the one described.

Explanation:

Universal Containers wants to dynamically assign roles and permission sets to agents who log in via SAML-based Single Sign-On (SSO). Since the default profile lacks Manage Users permission, any provisioning logic must run with elevated privileges — either via System Context or an admin-level JIT handler.

🅰️ A. Login Flow in User Context
❌ Incorrect
Running in User Context means the flow executes with the permissions of the logged-in user.
Since agents don’t have Manage Users permission, they cannot update roles or permission sets for themselves.

🅱️ B. Login Flow in System Context
✔️ Correct
Running in System Context allows the flow to bypass user-level restrictions.
This enables the flow to assign roles and permission sets even if the user lacks the necessary permissions.

🅲️ C. SAML JIT Handler run as current user
❌ Incorrect
Like Login Flow in User Context, this handler would run with limited permissions.
It cannot assign roles or permission sets unless the user has elevated privileges.

🅳️ D. SAML JIT Handler run as admin user
✔️ Correct
JIT provisioning can be configured to run as an admin user, allowing it to assign roles and permission sets during the SSO login process.
This is ideal for automated user provisioning based on attributes passed in the SAML assertion.

📘 References:
Salesforce Help: Login Flows
Salesforce Developer Guide: SAML JIT Provisioning

Explanation:

The contactless user feature allows organizations to create external users in Experience Cloud without requiring an associated Contact record. However, this has key licensing and functionality implications:

Option A (Incorrect) – While a custom registration handler can be used for advanced logic, it is not mandatory for assigning licenses. Salesforce allows contactless users to be created directly with an External Identity license, and admins can manually assign licenses without Apex.

Option B (Incorrect) – If a contactless user is upgraded to a Community license, Salesforce does not automatically create a Contact record. The admin must manually link the user to a Contact if needed.

Option C (Correct) – The contactless user feature only works with External Identity licenses, not standard Community licenses. This means:
👉 Users with External Identity licenses have limited access compared to full Community users (e.g., no access to standard Community features like Chatter or record sharing).
👉 If NTO wants full Experience Cloud functionality, they must convert these users to Community licenses and link them to Contacts.

Option D (Incorrect) – Passwordless authentication (e.g., OTP) can still work via email, even without a Contact record. While phone-based OTP requires a phone number, email-based methods do not.

Why C is the Best Answer?
The primary architectural impact is that contactless users require External Identity licenses, which restrict functionality compared to full Community licenses. If NTO relies on standard Experience Cloud features, they may need additional steps (like license upgrades and Contact linking) to ensure full access.

References:
Enable Contactless Users — Salesforce Help

Explanation:

Why: Configure the mobile app as a Connected App and set Permitted Users = “Admin approved users are pre-authorized.” Then assign access to only the Sales users via specific profiles and/or permission sets in the Connected App’s policy. This is the standard way to gate app access to a subset of users.

Why not the others:
A. A custom user attribute isn’t enforced by the OAuth gate; you’d still need a control point like the Connected App policy.
C. Permission Set Licenses grant product features, not app-level access. You still need the Connected App restriction.
D. Adding a new IdP is unnecessary; Salesforce can be the IdP and enforce access via the Connected App.

Explanation:

Universal Containers (UC) wants OAuth-enabled integration clients to use SAML-based single sign-on (SSO) for authentication in Salesforce. The solution must integrate SAML-based SSO with an OAuth flow for secure, programmatic access. Let’s evaluate each option:

A. User-Agent OAuth Flow: Incorrect.
The User-Agent flow (also known as the implicit grant flow) is designed for client-side applications (e.g., single-page apps) running in a browser, where the access token is returned directly to the client. It doesn’t support SAML-based SSO, as it relies on user interaction via a browser and doesn’t integrate with SAML assertions for authentication.

B. SAML Assertion OAuth Flow: Correct.
The SAML Assertion OAuth flow (also called OAuth 2.0 SAML Bearer Assertion Flow) allows an external client to authenticate to Salesforce using a SAML assertion issued by an identity provider (IdP). The client presents the SAML assertion to Salesforce’s OAuth token endpoint, which validates it and issues an OAuth access token. This flow is specifically designed to integrate SAML-based SSO with OAuth, making it ideal for UC’s requirement to use SAML for inbound OAuth-enabled clients.

C. User-Token OAuth Flow: Incorrect.
There is no standard OAuth flow called “User-Token OAuth flow” in Salesforce or the OAuth 2.0 specification. This appears to be a distractor. It might be confused with the User-Agent flow or the JWT Bearer Token flow, but neither aligns with SAML-based SSO requirements.

D. Web Server OAuth Flow: Incorrect.
The Web Server OAuth flow (also known as the Authorization Code flow) is designed for server-side applications where the client redirects the user to Salesforce for authentication, then exchanges an authorization code for an access token. While it supports SSO (e.g., via a configured IdP), it requires user interaction through a browser and doesn’t directly use SAML assertions for OAuth token issuance, unlike the SAML Assertion flow.

Why B:
The SAML Assertion OAuth flow is purpose-built for scenarios where an external client authenticates to Salesforce using a SAML assertion from an IdP, aligning perfectly with UC’s requirement for SAML-based SSO in an OAuth-enabled integration. It enables secure, programmatic access without requiring user interaction, ideal for integration clients.

Reference:
Salesforce Help: OAuth 2.0 SAML Bearer Assertion Flow
Trailhead: Identity for Developers
Salesforce Developer Docs: Understanding OAuth Endpoints

Explanation:

Universal Containers (UC) will build a custom Innovation platform entirely in Apex and Visualforce, using custom objects. They plan to authenticate employees via a third-party Identity Provider (IdP) with SAML SSO; employees shouldn't use Salesforce credentials. For this scenario, the Salesforce Platform License is optimal. It supports Apex, Visualforce, custom objects, reports, dashboards, Flows, and SAML-based SSO, ensuring employees have the tools they need without full CRM access.

👉 Option A (Identity License) isn't sufficient. Identity licenses are focused on authentication and single sign-on and do not support Visualforce, Apex, or access to custom objects.

👉 Option B (Salesforce License) is overkill—this full-featured CRM license grants access to standard Sales Cloud objects like Leads, Opportunities, and Cases, which the Innovation platform doesn’t need.

👉 Option C (External Identity License) is for external users (e.g., partners or customers) and lacks access to custom Apex/Visualforce or internal apps.

Therefore, the Platform License neatly fits the requirement: SSO login via SAML, ability to use Apex/VF and custom objects, without unnecessary licensing features.

References:
Standard User & Platform Licence Overview — Salesforce Help

Explanation:

The key requirement is to connect a fitness device (an IoT or input-limited device) to a customer's profile within the community. The OAuth Device Flow (also known as the Device Authorization Flow) is specifically designed for this type of integration.

OAuth Device Flow Rationale
Limited Input Devices:
Fitness trackers and other IoT devices often have limited input or display capabilities (e.g., a small screen, no keyboard/browser). The standard web server or user-agent OAuth flows that require a full browser redirect and login are impractical.
The Flow:
The Device Flow enables the device to get an access token by having the user complete the authorization process out-of-band (on a separate, input-capable device like a phone or computer) while still logged into the Community.
The device displays a short code and a verification URL.
The customer (logged into the Community) navigates to the URL on their phone/PC, enters the code, and approves access for the device.
The device polls the authorization server and receives the access token, linking it to the customer's Community profile.
Outcome:
This securely links the fitness device to the customer's Salesforce profile, allowing the device to send exercise data and enabling the community to deliver personalized fitness recommendations.

Why the Other Options are Incorrect
A. Named Credentials:
Named Credentials are used for outbound integrations (Salesforce calling an external system) and simplify authentication for Apex/Flows. They do not handle the inbound authentication and authorization required to link an external device to a user's session.
B. Login Flows:
Login Flows are used to customize the user login experience (e.g., adding a multi-factor authentication screen or a custom welcome message) after a user has entered their credentials but before they access the Community. They do not handle the separate OAuth process for an external device.
D. Single Sign-On Settings:
SSO settings (like SAML) handle the user's primary login to the Community. They ensure the customer is logged in, but they do not provide the mechanism for an external IoT device to obtain an access token to send data on the user's behalf.