Total 108 Questions
Last Updated On : 25-May-2026
Salesforce User Authentication
Northern Trail Outfitters (NTO) has a number of employees who do NOT need access Salesforce objects. The employees should sign in to a custom Benefits web app using their Salesforce credentials. Which license should the identity architect recommend to fulfill this requirement?
A. Identify Only License
B. Identify Verification Credits Add-On License
C. External Identity License
D. Identify Connect License
Explanation:
NTO employees need to:
Authenticate using Salesforce credentials
Access an external (non-Salesforce) application
Not access Salesforce objects
The Identity Only License is specifically designed for this use case. It provides:
Authentication (SSO) capabilities
Identity services (login, user management)
No access to standard/custom Salesforce objects
This makes it the most cost-effective and appropriate choice for employees who only need Salesforce as an Identity Provider (IdP).
Why the other options are incorrect
Identity Verification Credits Add-On License
Not a user license. It’s a consumption-based add-on for verification (e.g., SMS OTP).
External Identity License
Intended for external users (customers/partners), not internal employees.
Identity Connect License
Related to on-premise Active Directory integration, not for this authentication-only use case.
Key Concept
This question tests understanding of Salesforce Identity licensing:
Identity Only License = authentication without CRM access
Exam Tip
If you see:
“No access to Salesforce objects”
“Only need login / SSO”
👉 Always think Identity Only License.
Northern Trail Outfitters (NTO) is launching a new sportswear brand on its existing consumer portal built on Salesforce Experience Cloud. As part of the launch, emails with promotional links will be sent to existing customers to log in and claim a discount. The marketing manager would like the portal dynamically branded so that users will be directed to the brand link they clicked on; otherwise, users will view a recognizable NTObranded page.
The campaign is launching quickly, so there is no time to procure any additional licenses.
However, the development team is available to apply any required changes to the portal.
Which approach should the identity architect recommend?
A. Create a full audience to replicate the portal and set up these the branding accordingly.
B. Use tutorials to build the new brand site and embedded login for some identities.
C. Configure an additional community site on the same way that is dedicated for the new brand.
D. Implement Experiences ID in the code and extend the URLs and endpoints, as required.
Explanation:
NTO needs dynamic branding (different look for promotional links, fallback to NTO brand) without new licenses, with development team available. Experience Cloud's dynamic branding feature uses an Experience ID (expid) parameter in the URL. Developers can implement logic to read this parameter and apply corresponding brand sets, extending URLs and endpoints as needed.
Correct Option:
D. Implement Experience ID in the code and extend the URLs and endpoints, as required.
Dynamic branding uses the expid (Experience ID) URL parameter to switch brand sets (logos, colors, themes) within a single Experience Cloud site. Developers can modify the site's code (themes, navigation, controllers) to read this parameter and apply branding accordingly. Promotional emails would include URLs with expid for the new brand; missing or invalid expid falls back to default NTO branding. This requires no additional licenses.
Incorrect Option:
A. Create a full audience to replicate the portal and set up the branding accordingly.
"Full audience" is not a valid Salesforce feature for portal replication. Audiences control content targeting, not branding. Replicating the portal would require a second site and additional licenses (page views, storage), violating the "no additional licenses" constraint.
B. Use tutorials to build the new brand site and embedded login for some identities.
Building a completely separate brand site requires additional Experience Cloud licenses (each site counts against limits) and development effort. Embedded login does not solve dynamic branding. This approach exceeds licensing constraints.
C. Configure an additional community site dedicated for the new brand.
An additional Experience Cloud site requires its own license, domain, and setup. This violates the "no additional licenses" requirement. Dynamic branding within a single site is the correct license-compliant approach.
Reference:
Salesforce Help Article: "Dynamic Branding in Experience Cloud Using expid"
Trailhead: "Build Branded Experiences with Experience Cloud" – Unit on "Dynamic Branding"
Salesforce Architect Documentation: "Experience Cloud License Limits and Sites"
Northern Trail Outfitters (NTO) has a requirement to ensure all user logins include a single multi-factor authentication (MFA) prompt. Currently, users are allowed the choice to login with a username and password or via single sign-on against NTO’s corporate Identity Provider, which includes built-in MFA. Which configuration will meet this requirement?
A. Create and assign a permission set to all employees that includes “MFA for User Interface Logins.”
B. Create a custom login flow that enforces MFA and assign it to a permission set. Then assign the permission set to all employees.
C. Enable “MFA for User Interface Logins” for your organization from Setup - > Identity Verification.
D. For all employee profiles, set the Session Level Required at Login to High Assurance and add the corporate identity provider to the High Assurance list for the org ' s Session Security Levels.
Explanation:
NTO wants to guarantee a single MFA prompt for all user logins, regardless of the method:
Direct login (username + password), or
SSO via the corporate Identity Provider (which already has built-in MFA).
Option D achieves this elegantly using Session Security Levels:
Salesforce allows you to define Session Security Levels (Low Assurance, Medium Assurance, High Assurance).
You can configure "Session Level Required at Login" on Profiles (or Permission Sets) to High Assurance.
For the corporate Identity Provider (SAML or OpenID Connect), you map it to the High Assurance level. This tells Salesforce that a successful login through this IdP (which includes the IdP’s MFA) should be treated as a High Assurance session.
Result:
Users logging in directly get prompted for Salesforce MFA to reach High Assurance.
Users logging in via SSO get their MFA from the corporate IdP, and Salesforce accepts it as High Assurance (no additional Salesforce MFA prompt).
This ensures exactly one MFA prompt while meeting the requirement uniformly.
Why the other options are less ideal
A. Permission Set with “MFA for User Interface Logins”
This enables Salesforce’s own MFA for direct logins, but it does not reliably enforce or recognize the corporate IdP’s MFA. Users logging in via SSO may still bypass or get a second prompt.
B. Custom Login Flow to enforce MFA
Login Flows are powerful but complex to maintain. They are usually not the recommended approach when native session security features can solve the problem cleanly.
C. Enable “MFA for User Interface Logins” org-wide
This forces Salesforce MFA for direct logins only. It does not automatically handle or honor MFA performed at the external corporate Identity Provider during SSO.
Exam Takeaway
This question tests your understanding of Session Security Levels and how Salesforce can trust MFA performed by a trusted external Identity Provider. Using High Assurance + mapping the IdP is the architecturally cleanest way to enforce consistent MFA without double-prompting when SSO is involved.
A farming enterprise offers smart farming technology to its farmer customers, which includes a variety of
sensors for livestock tracking, pest monitoring, climate monitoring etc.
They plan to store all the data in Salesforce. They would also like to ensure timely maintenance of the
installed sensors. They have engaged a Salesforce Architect to propose an appropriate way to send an alert
when something goes wrong.
Which OAuth flow should the architect recommend?
A. OAuth 2.0 SAML Bearer Assertion Flow
B. OAuth 2.0 Device Authentication Flow
C. OAuth 2.0 Asset Token Flow
D. OAuth 2.0 JWT Bearer Token Flow
Explanation:
This question addresses the architectural requirements for securing Internet of Things (IoT) devices within the Salesforce ecosystem. It tests the ability to select an OAuth flow that can handle massive scales of device-to-cloud communication while linking telemetry data to specific physical assets and customer accounts.
✅ Option C: OAuth 2.0 Asset Token Flow
The Asset Token Flow is specifically designed for the IoT landscape. It allows devices (like livestock or climate sensors) to authenticate and provide a token that includes context about the "Asset" it represents. This flow is ideal for this scenario because it creates a verifiable link between the sensor hardware and the Salesforce Asset record, enabling the system to trigger automated alerts and maintenance schedules based on the device's specific telemetry data.
❌ Option A: OAuth 2.0 SAML Bearer Assertion Flow
The SAML Bearer Assertion flow is typically used when a client wants to use a previous SAML authentication act to swap for an OAuth access token, often in a server-to-server integration where a trust relationship already exists via SAML. It is not optimized for individual IoT sensors and lacks the native "Asset" context required to efficiently manage and monitor thousands of farming sensors.
❌ Option B: OAuth 2.0 Device Authentication Flow
The Device Authentication flow is intended for devices with limited input capabilities or no web browser, such as Smart TVs or command-line tools, where a user must authorize the device on a separate screen. In a smart farming environment with thousands of automated sensors, it is impossible for a user to manually authorize each sensor through a browser-based interaction, making this flow impractical.
❌ Option D: OAuth 2.0 JWT Bearer Token Flow
The JWT Bearer flow is a server-to-server flow used for integrations where no explicit user interaction is required. While it is highly secure and common for backend integrations, it does not inherently carry the device-specific "Asset" metadata that the Asset Token Flow provides. For a farming enterprise managing diverse sensor types, the lack of native asset-linking makes it less efficient than the Asset Token Flow.
🔧 Reference:
→ Salesforce Help: OAuth 2.0 Asset Token Flow for IoT
This documentation confirms that the asset token flow is the standard for integrating IoT devices with Salesforce to provide asset-rich information for automated processing.
The CMO of an advertising company has invited an Identity and Access Management (IAM) specialist to discuss Salesforce out-of-box capabilities for configuring the company ' s login and registration experience on Salesforce Experience Cloud.
The CMO is looking to brand the login page with the company ' s logo, background color, login button color, and dynamic right-frame from an external URL.
Which two solutions should the IAM specialist recommend? Choose 2 answers:
A. Login & Registration pages can be branded in the Community Administration settings.
B. Build custom site pages for reset and forget password features.
C. Build custom pages for handling requirements as Experienced Cloud.
D. Use Experience Builder to build branded Reset and Forget Password pages.
Explanation:
The CMO needs branding (logo, colors, dynamic right‑frame from an external URL) for the login and registration experience. Out‑of‑the‑box, Experience Cloud allows branding of Login & Registration pages directly in administration settings. For more advanced needs like a dynamic right‑frame, Experience Builder can create fully customized branded pages for login, registration, reset password, and forgot password flows.
Correct Options:
A. Login & Registration pages can be branded in the Community Administration settings.
Within Experience Cloud administration, under Login & Registration → Branding, administrators can upload a logo, set background and button colors, and customize CSS. This is an out‑of‑the‑box, point‑and‑click solution without custom development, covering basic branding requirements.
D. Use Experience Builder to build branded Reset and Forget Password pages.
For dynamic content (e.g., right‑frame from an external URL), the standard Login & Registration branding may be insufficient. Using Experience Builder, developers can create fully custom pages for Login, Registration, Reset Password, and Forgot Password. These pages can include Lightning components, iframes to external URLs, and complete visual control.
Incorrect Options:
B. Build custom site pages for reset and forget password features.
This is partially correct but incomplete. Building custom pages is one approach; however, Experience Builder (option D) is the recommended, supported, and lower‑effort way to create branded reset/forgot pages. Option B does not specify that these pages must replace the standard flows, nor does it reference Experience Builder, which provides built‑in templates for these pages.
C. Build custom pages for handling requirements as Experienced Cloud.
This option is vague and grammatically unclear ("as Experienced Cloud"). It does not specify which pages or features. While custom pages are possible, the question asks for out‑of‑the‑box solutions. Experience Builder (option D) is the standard tool; building pages from scratch without it is more custom and less maintainable.
Reference:
Salesforce Help Article: "Brand Your Experience Cloud Login and Registration Pages"
Trailhead: "Build Login and Registration Pages with Experience Builder"
Salesforce Architect Documentation: "Customizing Login Flows in Experience Cloud"
Universal Containers is creating a mobile application that will be secured by Salesforce Identity using the OAuth 2.0 user-agent flow. Application users will authenticate using username and password. They should not be forced to approve API access in the mobile app or reauthenticate for 3 months. Which two connected app options need to be configured to fulfill this use case? Choose 2 answers
A. Set the Sealston Timeout value to 3 months.
B. Set Permitted Users to " All users may self-authorize " .
C. Set Permitted Users to " Admin approved users are pre-authorized " .
D. Set the Refresh Token Policy to expire refresh token after 3 months.
Explanation:
To meet the requirements of a mobile app that avoids user consent prompts ("approve API access") and minimizes re-authentication, you must configure specific OAuth policies within the Salesforce Connected App.
Why "Admin approved users are pre-authorized" is correct
By default, when a user logs in via OAuth, Salesforce prompts the user to "Approve" the application's access to their data.
By changing the Permitted Users setting to "Admin approved users are pre-authorized" and then assigning the app to specific users via Profiles or Permission Sets, you bypass the consent screen. This ensures that the user is not forced to manually approve API access, fulfilling the requirement for a seamless user experience.
Why "Refresh Token Policy" is correct
The Refresh Token Policy determines how long a refresh token remains valid.
If you set the policy to "Expire refresh token if not used for..." and define the duration (e.g., 90 days/3 months), the application can use the refresh token to obtain a new access token without the user having to re-enter their credentials. This effectively keeps the user logged in for the desired period, provided the token is used periodically within that timeframe.
Why the other options are incorrect
Set the Session Timeout value to 3 months
Session Timeout is a general security setting for the org's web interface sessions. It is not an OAuth Connected App configuration setting, and usually, organization-wide session timeouts are not set to 3 months for security compliance reasons.
Set Permitted Users to "All users may self-authorize"
This option forces the standard OAuth flow where users must explicitly approve API access, which contradicts the requirement to not force the user to approve access.
References
Salesforce Help: Manage OAuth Access Policies for a Connected App
Salesforce Help: OAuth 2.0 User-Agent Authentication Flow
Universal Containers (UC) has an Experience Cloud site (Customer Community) where customers can authenticate and place orders, view the status of orders, etc. UC allows guest checkout.
How can a guest register using data previously collected during order placement?
A. Enable self-registration and customize a self-registration page to collect only order details to retrieve customer data.
B. Enable Security Assertion Markup Language (SAML) Sign-On and use a login flow to collect only order details to retrieve customer data.
C. Enable Facebook as an authentication provider and use a registration handler to collect only order details to retrieve customer data.
D. Use a Connected App Handler. Apex Plugin class to collect only order details to retrieve customer data.
Explanation:
UC allows guest checkout, meaning order data exists before account creation. When a guest later registers, the system should retrieve that existing order data using previously collected information (like email or order number). Self-registration with a customized page allows collecting minimal identifying information (e.g., order number + email) to look up and link the guest's order history.
Correct Option:
A. Enable self-registration and customize a self-registration page to collect only order details to retrieve customer data.
The standard self-registration page can be customized using a custom Visualforce page or Lightning component. The customized page collects order-specific details (e.g., order number, email). A registration handler Apex class then looks up the order object, retrieves the customer's identity, and creates a new user linked to the existing contact/account. This preserves order history after registration.
Incorrect Option:
B. Enable Security Assertion Markup Language (SAML) Sign-On and use a login flow to collect only order details to retrieve customer data.
SAML SSO is for authenticating users against an external identity provider, not for guest checkout registration. Login flows occur after authentication, not before user creation. SAML also assumes an existing identity in the IdP, which a guest does not have. This does not solve guest-to-registered user transition.
C. Enable Facebook as an authentication provider and use a registration handler to collect only order details to retrieve customer data.
Facebook social login does not natively collect order details. While a registration handler could be written, the user would first authenticate via Facebook, then the handler would need to ask for order details anyway — but the requirement is to use previously collected data, not to collect new data after social login. This adds unnecessary complexity.
D. Use a Connected App Handler. Apex Plugin class to collect only order details to retrieve customer data.
"Connected App Handler Apex Plugin class" is not a standard Salesforce component for self-registration. Connected Apps manage OAuth clients, not guest registration flows. Custom registration handlers are used with self-registration pages, not with Connected App plugins.
Reference:
Salesforce Help Article: "Customize Self-Registration for Guest Users with Existing Orders"
Trailhead: "Identity for Customers" – Unit on "Guest Checkout to Registered User"
Salesforce Developer Guide: "Auth.RegistrationHandler – Linking Pre-existing Data"
Universal Containers wants to secure its Salesforce APIs by using an existing Security Assertion Markup Language (SAML) configuration that supports the company ' s single signon process to Salesforce. Which Salesforce OAuth authorization flow should be used?
A. OAuth 2.0 JWT Bearer Flow
B. OAuth 2.0 SAML Bearer Assertion Flow
C. OAuth 2.0 User-Agent Flow
D. SAML Assertion Flow
Explanation:
Let’s analyze the requirement and each option:
Requirement: UC wants to secure Salesforce APIs while leveraging an existing SAML configuration that already supports their single sign-on (SSO) process to Salesforce.
Option B - OAuth 2.0 SAML Bearer Assertion Flow (Correct)
This flow allows a client application to obtain an OAuth access token by presenting a valid, signed SAML assertion that was issued by the company's existing SAML Identity Provider (IdP). Since UC already has a SAML configuration for SSO, this flow reuses that same IdP and trust relationship. The app gets a SAML assertion from the existing IdP, sends it to Salesforce's OAuth token endpoint, and receives an OAuth access token to call APIs. This perfectly fulfills the requirement of securing APIs using the existing SAML infrastructure.
Option A - OAuth 2.0 JWT Bearer Flow (Incorrect)
This flow uses a JSON Web Token (JWT) signed with a certificate, not a SAML assertion. While it is a valid OAuth flow for server-to-server integration, it does not leverage an existing SAML configuration. It requires separate certificate management and does not reuse the SAML SSO IdP.
Option C - OAuth 2.0 User-Agent Flow (Incorrect)
This flow is designed for client-side applications (like JavaScript SPAs or mobile apps) where the OAuth process runs entirely in the user agent (browser). It does not involve SAML at all and does not leverage an existing SAML configuration. It's typically used for browser-based apps that can't securely store a client secret.
Option D - SAML Assertion Flow (Incorrect)
"SAML Assertion Flow" is not a standard OAuth 2.0 authorization grant type defined in the Salesforce OAuth specification. The official name is OAuth 2.0 SAML Bearer Assertion Flow (sometimes called SAML 2.0 Bearer Assertion Flow for OAuth 2.0). This option appears to be a distractor that sounds similar but is not the precise technical term.
Summary
The OAuth 2.0 SAML Bearer Assertion Flow is purpose-built exactly for this scenario: it bridges SAML and OAuth, allowing an organization to reuse its existing SAML IdP investment to secure API access via OAuth tokens.
Reference
Salesforce Help: OAuth 2.0 SAML Bearer Assertion Flow — "Use this flow to get an access token using a SAML assertion when you already have a SAML single sign-on configuration."
Salesforce Developer Documentation: OAuth 2.0 SAML Bearer Assertion Flow — "This flow allows use of a SAML 2.0 identity provider to authorize API access to Salesforce."
Northern Trail Outfitters (NTO) wants to give customers the ability to submit and manage issues with their purchases. It is important for NTO to give its customers the ability to login with their Amazon credentials.
What should an identity architect recommend to meet these requirements?
A. Create a custom external authentication provider for Amazon.
B. Configure Amazon as & connected app.
C. Configure an OpenlD Connect Authentication Provider for Amazon.
D. Configure a predefined authentication provider for Amazon.
Explanation:
NTO requires customers to log in to Experience Cloud using Amazon credentials. Amazon supports OpenID Connect (OIDC) as an identity provider. Salesforce provides native OIDC authentication provider functionality that can be configured to connect to Amazon's OIDC-compliant endpoints, enabling seamless social login without custom code.
Correct Option:
C. Configure an OpenID Connect Authentication Provider for Amazon.
Salesforce supports OpenID Connect authentication providers natively. Amazon's login service (Amazon Cognito or Login with Amazon) provides OIDC discovery endpoints. By configuring an OIDC authentication provider in Salesforce with Amazon's client ID, client secret, and metadata URL, users can authenticate using their Amazon credentials. A registration handler maps the Amazon identity to a Salesforce user.
Incorrect Option:
A. Create a custom external authentication provider for Amazon.
This suggests writing custom Apex code to implement a full authentication provider, which is unnecessary. Salesforce already supports OIDC and SAML. For Amazon, OIDC is the standard and simplest path. Custom providers are needed only for non-standard IdPs that do not support OIDC or SAML.
B. Configure Amazon as a connected app.
A connected app defines how external applications connect to Salesforce (outbound OAuth), not how Salesforce accepts authentication from an external IdP (inbound). Connected apps are used for API access from external apps to Salesforce, not for allowing users to log into Salesforce using external credentials.
D. Configure a predefined authentication provider for Amazon.
Salesforce does not offer a "predefined" authentication provider specifically for Amazon. Predefined providers exist for common IdPs like Facebook, Google, LinkedIn, and Twitter. Amazon is not among those. For Amazon, you must configure a generic OpenID Connect provider manually. This option is misleading.
Reference:
Salesforce Help Article: "Set Up an OpenID Connect Authentication Provider"
Trailhead: "Social Sign-On with OpenID Connect" – Unit on "Custom OIDC Providers"
Amazon Developer Documentation: "Login with Amazon – OpenID Connect"
Northern Trail Outfitters (NTO) uses Salesforce for Sales Opportunity Management. Okta was recently
brought in to Just-in-Time (JIT) provision and authenticate NTO users to applications. Salesforce users also
use Okta to authorize a Forecasting web application to access Salesforce records on their behalf.
Which two roles are being performed by Salesforce?
Choose 2 answers
A. OAuth Resource Server
B. SAML Service Provider
C. OAuth Client
D. SAML Identity Provider
Explanation:
This question is testing OAuth roles vs SAML roles in a hybrid identity architecture.
Two systems are involved: Okta (Identity Provider + OAuth client initiator) and Salesforce (resource owner of data APIs + service provider for SSO context). You must separate authentication (SAML) from authorization (OAuth) roles.
🟢 Correct Options:
A. OAuth Resource Server
Salesforce acts as the resource server because it stores and protects data (Salesforce records like Opportunities). When the Forecasting web app accesses Salesforce data on behalf of users, Salesforce validates OAuth tokens and serves protected resources. This makes Salesforce the API/resource endpoint in the OAuth flow.
C. OAuth Client
Salesforce also behaves as an OAuth client in this scenario because users inside Salesforce authorize an external Forecasting web application to access Salesforce data. In OAuth terms, Salesforce initiates or participates in granting access to third-party apps via authorization flows, making it a client in that interaction context.
🔴 Incorrect options:
B. SAML Service Provider
Salesforce can act as a SAML Service Provider in SSO scenarios, but in this question, Okta is explicitly handling authentication via JIT provisioning and SSO. The focus is OAuth-based authorization for API access, not SAML-based login, so this role is not relevant here.
D. SAML Identity Provider
Salesforce is not acting as the Identity Provider in this architecture. Okta is clearly defined as the IdP performing authentication and JIT provisioning. Therefore, Salesforce does not issue identity assertions in this scenario.
| Page 3 out of 11 Pages |
| 1234 |
| Salesforce-Platform-Identity-and-Access-Management-Architect Practice Test Home |
Our new timed 2026 Salesforce-Platform-Identity-and-Access-Management-Architect practice test mirrors the exact format, number of questions, and time limit of the official exam.
The #1 challenge isn't just knowing the material; it's managing the clock. Our new simulation builds your speed and stamina.
You've studied the concepts. You've learned the material. But are you truly prepared for the pressure of the real Salesforce Certified Platform Identity and Access Management Architect (SP25) exam?
We've launched a brand-new, timed Salesforce-Platform-Identity-and-Access-Management-Architect practice exam that perfectly mirrors the official exam:
✅ Same Number of Questions
✅ Same Time Limit
✅ Same Exam Feel
✅ Unique Exam Every Time
This isn't just another Salesforce-Platform-Identity-and-Access-Management-Architect practice questions bank. It's your ultimate preparation engine.
Enroll now and gain the unbeatable advantage of:
Copyright © - All Rights Reserved