Salesforce-Platform-Identity-and-Access-Management-Architect Practice Test Questions (2026)

Explanation:

This question is about choosing the right tool within the Salesforce Identity product suite to solve a specific problem: automating user lifecycle management (provisioning/deprovisioning) and authentication between an on-premises Microsoft Active Directory and Salesforce.

Let's evaluate each option:

D. A Salesforce Identity can be included but NTO will require Identity Connect.
This is the correct and most precise answer. Salesforce Identity Connect is the specific product designed to synchronize an on-premises Active Directory with Salesforce. It automatically creates, updates, and deactivates users in Salesforce based on their status in AD. It can also be configured to use that same AD as an Identity Provider (IdP) for SAML-based authentication. This directly fulfills the requirements for provisioning, deprovisioning, and authenticating users from the existing Microsoft AD.

A. Salesforce Identity is not needed since NTO uses Microsoft AD. This is incorrect.
While NTO uses Microsoft AD, it needs a secure and automated way to connect that AD to Salesforce. "Salesforce Identity" is the overarching product family that provides these connection capabilities (including Identity Connect). Simply having AD does not automatically integrate it with Salesforce.
B. Salesforce Identity can be included but NTO will be required to build a custom integration with Microsoft AD.
This is not the recommended path. While building a custom integration using Salesforce APIs is technically possible, it is complex, requires ongoing maintenance, and is error-prone. Salesforce provides Identity Connect as a pre-built, supported, and robust solution specifically to avoid the need for custom code for this common integration.
C. Salesforce Identity is included in the Salesforce licenses so it does not need to be considered separately.
This is misleading and incorrect. While core platform licenses include the ability to be an Identity Provider (e.g., for SSO to external apps), the Identity Connect component, which is crucial for synchronizing with on-premises AD, is a separately licensed product. It is not included in standard Salesforce user licenses and must be procured and implemented separately.

Architectural Summary:
The requirement calls for a bidirectional sync between the system of record (on-premises AD) and Salesforce.
Provisioning/Deprovisioning: Identity Connect syncs user accounts, profiles, and group memberships from AD to Salesforce.
Authentication: Once synced, Identity Connect can facilitate using the on-premises AD as a trusted IdP for logging into Salesforce via SAML, providing a seamless SSO experience.

Reference:
Salesforce Help: "About Salesforce Identity Connect"
The documentation states: "Salesforce Identity Connect synchronizes your organization’s user information between your on-premises Active Directory and your Salesforce org... automatically deactivates users in Salesforce... and automatically assigns and updates user profiles and permission sets." This is the definitive tool for the described use case.

Explanation:

To restrict the API connection to only the employee portal server, we need a mechanism that ties the OAuth authentication to the specific server making the API calls. Let’s break down why option A is correct and why the others don’t fully meet the requirement:

Option A: Add the Employee portal’s IP address to the Trusted IP range for the connected App
In Salesforce, a Connected App is used to define and manage external applications (like the employee portal) that integrate with Salesforce via APIs. When using OAuth flows (like Username-Password flow), you can configure the Connected App to include a Trusted IP Range. This restricts API access to only requests coming from the specified IP addresses, in this case, the employee portal server’s IP.
By adding the employee portal’s IP address to the Trusted IP range in the Connected App settings, Salesforce ensures that only API requests from that server are allowed. This directly addresses the requirement to restrict the connection to the specific server.
Why it works: The Trusted IP range in a Connected App is specifically designed for API-based integrations, making it the most precise way to limit access to a particular server’s IP address for OAuth-based connections.

Option B: Use a digital certificate signed by the employee portal Server
Digital certificates are used in Salesforce for mutual TLS authentication or to secure specific types of integrations, but they are not typically used with the OAuth Username-Password flow. This flow relies on username, password, client ID, and client secret, not certificates.
While certificates could be used in other authentication scenarios (e.g., JWT Bearer flow), they’re not relevant here, as the question specifies OAuth Username-Password flow. This option doesn’t directly address restricting access to the employee portal server’s IP.

Option C: Add the employee portal’s IP address to the login IP range on the user profile
The Login IP Range on a user profile restricts where a user can log in to Salesforce’s UI or API. However, this applies to the user’s login session, not specifically to the Connected App’s API requests.
For an API user using OAuth Username-Password flow, the Connected App’s Trusted IP range (Option A) is the more appropriate control, as it governs the application-level access rather than the user’s login. Using a profile’s Login IP range could work but is less precise, as it affects all logins for that user, not just the API connection from the employee portal.

Option D: Use a dedicated profile for the user the Employee portal uses
Creating a dedicated profile for the API user is a good practice to control permissions and access to Salesforce data (e.g., limiting what the API user can do). However, it doesn’t address the requirement to restrict the connection to the employee portal server’s IP address. Profiles manage permissions, not IP-based restrictions for API calls.

Why Option A is Best?
The Trusted IP Range for the Connected App is the most direct and secure way to ensure that only the employee portal server can make API calls to Salesforce. It ties the restriction to the Connected App used for the OAuth Username-Password flow, which aligns perfectly with the question’s scenario. This setting is configured in the Connected App’s settings in Salesforce, under “Trusted IP Range,” where you can specify the IP address of the employee portal server.

Reference:
Salesforce Documentation: Connected Apps in Salesforce allow you to define Trusted IP Ranges to restrict API access. See the Salesforce Help article on Connected Apps for details on configuring IP restrictions.
OAuth Username-Password Flow: This flow is described in Salesforce’s OAuth 2.0 Username-Password Flow documentation, which explains how it’s used for server-to-server integrations.

Explanation:

This question focuses on securing sensitive data within a SAML assertion both in transit and from tampering. The requirements are to ensure integrity (cannot be tampered with) and confidentiality (not accessible to anyone in transit). The solution must work for users on both the corporate network and external mobile devices.

Why A is Correct: This is a standard and robust security practice for SAML.
Digitally Signing with the IdP's Certificate: This ensures integrity. Salesforce, the Service Provider (SP), uses the public key from the Identity Provider's (IdP) certificate to validate the signature. If the assertion is tampered with after being signed, the signature validation will fail, and login will be denied.
Encrypting with Salesforce's Certificate: This ensures confidentiality. The IdP uses Salesforce's public certificate (uploaded to the SAML configuration) to encrypt the sensitive portions of the assertion. Only Salesforce, possessing the corresponding private key, can decrypt it. This protects the sensitive data from being read by anyone while it is in transit over the network.

Why D is Correct: This approach avoids putting the sensitive data in the SAML assertion altogether, which is the most secure way to handle it. Instead of being passed through the user's browser via a form post, the sensitive data is fetched server-to-server after the initial SAML authentication is complete.
A custom login flow (often an Apex plugin for the authentication flow) can be triggered after the SAML assertion is validated.
This Apex code can then make a secure, outbound callout (e.g., to the custom Identity Provider application) to retrieve the necessary sensitive user data. This callout happens over a protected HTTPS channel directly between Salesforce and the IdP, completely bypassing the user's browser and the SAML response. This method is highly secure and is recommended for sensitive data transfer.

Why B is Incorrect: This option mixes incompatible concepts.
Digitally signing the assertion with Salesforce's certificate is incorrect. The assertion must be signed by the Identity Provider to prove its origin. Salesforce would not have the private key to sign an assertion it didn't create.
A Mobile Device Management (MDM) client can secure the device itself but does nothing to protect the SAML assertion while in transit over the internet between the browser and Salesforce. The data is still vulnerable to interception on the network.

Why C is Incorrect: This option is flawed because it uses the same certificate for both signing and encryption.
While signing with the IdP's certificate is correct for integrity, encrypting with the IdP's certificate is wrong. Encrypting with the IdP's certificate would mean the data is encrypted with the IdP's public key. This would require the IdP's private key to decrypt it. Since Salesforce does not have the IdP's private key, it would be unable to decrypt the assertion, causing the login to fail. Encryption must always be done with the recipient's (Salesforce's) public key.

Reference:
Salesforce Help - "Encrypt SAML Assertions"
Salesforce Help - "Create a Custom Login Flow" (Specifically for using Apex plugins)
General SAML specification best practices for signing and encryption.

Explanation:

The CMO wants to brand the login and registration experience on Salesforce Experience Cloud with:

Company logo
Background and button colors
A dynamic right-frame from an external URL

Salesforce provides out-of-the-box tools to achieve this without heavy customization:

✅ A. Use Experience Builder to build branded Reset and Forgot Password pages
Experience Builder allows you to visually customize pages like:
Forgot Password
Reset Password
You can apply branding elements such as logos, colors, and layout.
This ensures a consistent brand experience across all user flows.
✅ D. Login & Registration pages can be branded in the Community Administration settings
The Community Administration panel lets you:
Customize the login and registration pages
Add logos, background colors, and button styles
Embed a dynamic right-frame using external URLs or custom HTML
These settings are native to Salesforce and require no custom development.

❌ Why the other options are less ideal:
B. Build custom pages for branding requirements: Unnecessary unless you need extreme customization. Salesforce already supports branding through Experience Builder and Admin settings.
C. Build custom site pages for reset and forgot password features: Again, this adds complexity. Experience Builder already supports these pages natively.

🔗 Reference:
Customize Login Pages in Experience Cloud
Experience Builder Overview

Explanation:

✅ Correct Answer: A. OAuth 2.0 Asset Token Flow
This flow is specifically designed for IoT devices and hardware (like sensors, smart devices, gateways) that need to send data securely to Salesforce.
An asset token is issued for a connected device, which then allows the device to authenticate and push data into Salesforce without needing a human user session.
Perfect fit here since sensors (non-human clients) must send continuous data into Salesforce and be linked to installed assets for maintenance.

❌ Why not the others?

B. OAuth 2.0 Device Authentication Flow
Used for devices with limited input/display capability (like a TV, console, or set-top box) where a human must enter a code on another device to authenticate.
Not meant for autonomous sensors.

C. OAuth 2.0 JWT Bearer Token Flow
Used for server-to-server integrations where there is no user interaction but the integration still acts on behalf of a Salesforce user.
Good for backend services, but not for physical IoT devices/assets tied to Salesforce assets.

D. OAuth 2.0 SAML Bearer Assertion Flow
Used when an external Identity Provider (IdP) issues a SAML assertion to get an access token in Salesforce.
Not relevant for IoT sensors since they don’t use SAML.

📖 Reference:
Salesforce: Asset Token Flow for Securing IoT Device-to-Cloud Communication
Salesforce Identity Implementation Guide – OAuth Flows

👉 Final Answer: A. OAuth 2.0 Asset Token Flow

Explanation:

This solution uses Salesforce's built-in Session Security Levels to enforce a stricter login requirement for the high-risk action (Export Reports) without blocking access to the report viewing action itself.

Establish Dual Login Options:
Users need to be able to log in using either Salesforce credentials or AD credentials (via SAML/SSO).
Assign Assurance Levels:
By default, a standard password login grants a Standard Assurance session.
The architect configures the SAML Single Sign-On setting to grant a High Assurance session when a user successfully logs in using their AD credentials.
Restrict the High-Risk Action:
The administrator navigates to the Session Settings in Salesforce and specifies that the "Export Reports" permission (or the corresponding Profile/Permission Set) requires a High Assurance session level.
Result:
A user logged in with Salesforce credentials (Standard Assurance) can view reports but will be prompted to re-authenticate with a "High Assurance" method (i.e., their AD/SAML credentials) if they attempt to click the Export button.
A user logged in with AD credentials (High Assurance) can view and export reports without any further re-authentication.

Analysis of Incorrect Options

A. Use SAML Federated Authentication and block access to reports when accessed through a Standard Assurance session:
This is too broad. The requirement is only to prevent exporting reports, not viewing them. Blocking access to reports entirely when logged in with Salesforce credentials fails the requirement to allow viewing.
B. Use SAML Federated Authentication and Custom SAML JIT Provisioning to dynamically and or remove a permission set...:
JIT provisioning runs during the initial login and only creates/updates the user record. It is not designed to dynamically grant or revoke permissions based on the action the user is attempting after login.
D. Use SAML federated Authentication with a Login Flow to dynamically add or remove a Permission Set...:
A Login Flow executes only once when the user first logs in. Once the user is in the org, the Permission Set is fixed for that session. This does not allow the system to force a re-authentication (session elevation) just for the Export action.

Explanation:

The core requirement is to use a single Identity Provider (IdP) for multiple Salesforce orgs. This is a classic Single Sign-On (SSO) federation scenario. The key to making this work is ensuring that the IdP can uniquely identify a user and that each Salesforce org (Service Provider) can correctly map that unique identity from the SAML assertion to a specific user record in its database.

Why C is Correct: The Federation ID field on the User object is the standard, designed solution for this exact purpose.
When a user authenticates via SAML, the Identity Provider sends a unique identifier for that user (e.g., UserPrincipalName or Email) in the SAML assertion.
Salesforce receives this assertion and looks for a User record where the Federation ID field matches the unique identifier sent by the IdP.
By setting the same unique identifier from the IdP as the Federation ID for a user across all orgs, you ensure that the same user is correctly matched and logged in, regardless of which org they are accessing. This allows a single identity from the IdP to be mapped to multiple user records (one in each org).

Why A is Incorrect: While email is a common unique identifier and is often used, it is not the primary matching field for SAML. Salesforce's default and recommended behavior is to use Federation ID for matching. Relying on email can cause issues if a user's email address changes or if the identifier from the IdP is not an email address (e.g., a username or employee ID).

Why B is Incorrect: The ability to have the same username in multiple orgs is not controlled by Salesforce Support; it is a standard feature. Usernames must be unique within a single org but can be duplicated across different orgs. However, the Username field is not the primary field used for matching a SAML assertion. The architect should not rely on this nor is contacting support the necessary solution.

Why D is Incorrect: The Alias field is a short, friendly name used primarily for display purposes (e.g., in Chatter feeds). It has no functional role in the SAML authentication and user matching process and cannot be used to enable this behavior.

Reference:
Salesforce Help - "How Single Sign-On Authentication Matching Works": This document explicitly states: "When a user attempts to log in using single sign-on (SSO), Salesforce matches the identity provider’s (IdP’s) unique user identifier to the Federation ID of a user in the organization. If a match is found, the user is logged in to that user’s account."

Explanation:

The scenario describes a web service accessing customer order status on the Salesforce Platform via a connected app using the OAuth 2.0 Web Server Flow (also known as the Authorization Code Flow). This flow is used for server-to-server authentication, where a web application authenticates a user and obtains an access token to make API calls to Salesforce. The correct sequence of actions for the OAuth 2.0 Web Server Flow is critical to understand. Let’s analyze the flow and the provided options.

OAuth 2.0 Web Server Flow Steps:
User Authenticates and Authorizes Access: The user is redirected to Salesforce’s authorization endpoint (e.g., /authorize) via the connected app, where they log in and approve access for the application. This step confirms the user’s identity and authorizes the connected app.
Request an Authorization Code: The connected app sends a request to Salesforce’s authorization endpoint, including the client ID, redirect URI, and other parameters. This is part of the initial request that prompts user authentication.
Salesforce Grants Authorization Code: After the user authorizes access, Salesforce redirects the user back to the connected app’s redirect URI with an authorization code in the query string.
Request an Access Token: The connected app sends the authorization code to Salesforce’s token endpoint (e.g., /token), along with the client ID, client secret, and redirect URI, to request an access token.
Salesforce Grants an Access Token: Salesforce verifies the authorization code and, if valid, issues an access token (and optionally a refresh token) to the connected app, which can then be used to access protected resources (e.g., customer order status).

Correct Sequence:
Mapping the provided actions to the OAuth 2.0 Web Server Flow:
1. User Authenticates and Authorizes Access → First, the user must log in and approve the app.
4. Request an Authorization Code → The connected app initiates the request for an authorization code (this triggers the user authentication).
5. Salesforce Grants Authorization Code → Salesforce provides the authorization code after user approval.
2. Request an Access Token → The connected app uses the authorization code to request an access token.
3. Salesforce Grants an Access Token → Salesforce issues the access token to complete the flow.
Thus, the correct sequence is 1, 4, 5, 2, 3 (Option A).

Analysis of Options:
A. 1, 4, 5, 2, 3: Correct. Matches the OAuth 2.0 Web Server Flow: User authenticates (1), the app requests an authorization code (4), Salesforce grants the code (5), the app requests an access token (2), and Salesforce grants the token (3).
B. 4, 1, 5, 2, 3: Incorrect. Requesting an authorization code (4) cannot occur before user authentication (1), as the user must log in to authorize the code request.
C. 2, 1, 3, 4, 5: Incorrect. Requesting an access token (2) cannot happen before obtaining an authorization code (4, 5), as the code is required to request the token.
D. 4, 5, 2, 3, 1: Incorrect. Requesting and granting an authorization code (4, 5) cannot occur before user authentication (1), and user authentication should not be the last step.

Reference:
Salesforce Documentation - OAuth 2.0 Web Server Flow
OAuth 2.0 RFC 6749 - Authorization Code Grant

Explanation:

✅ Correct Answer: C. Configure Just-in-Time (JIT) provisioning using SAML attributes
Just-in-Time (JIT) provisioning allows Salesforce to create a user dynamically at the first login, based on the SAML assertion sent by the IdP.

This means:
No pre-creation of users is required.
Only employees who actually log in to Salesforce will consume a license.
New hires get immediate access because their user is created “just in time” during login.

This directly solves both requirements: immediate access and minimizing license usage.

❌ Why not the others?

A. Install Salesforce Identity Connect
Identity Connect synchronizes users from Active Directory to Salesforce automatically.
But it requires users to exist in Salesforce whether or not they log in. This could consume extra licenses unnecessarily.

B. Build an integration that queries LDAP periodically
This would create all users in Salesforce, whether they need Salesforce access or not.
Not efficient and doesn’t minimize license usage.

D. Build an integration that queries LDAP and creates inactive users
This still requires creating user records for everyone upfront.
Also adds complexity with login flows to activate users.
Less efficient than JIT provisioning.

📖 Reference:
Salesforce Help: Just-in-Time User Provisioning
Salesforce Identity Implementation Guide – SAML & JIT provisioning

👉 Final Answer: C. Configure Just-in-Time provisioning using SAML attributes to create new Salesforce users as necessary when a new user attempts to login.

Explanation:

The scenario involves a federated single sign-on (SSO) setup where a third-party Identity Provider (IdP) authenticates users, and Salesforce (as the Service Provider) grants access based on that authentication. When users receive error messages during login, the issue could lie with the IdP, the SSO configuration in Salesforce, or the user record itself (e.g., mismatched usernames).

Why Option D is Correct (Login History):
The Login History in Salesforce is the primary tool for debugging authentication issues, especially for SSO. It provides a detailed log of every login attempt, whether successful or failed. For a failed SSO attempt, it will show crucial information such as:

The Login Type (e.g., "SAML Single Sign-On").
The Login URL used.
The API Type (which can indicate the SSO flow).
A Status (e.g., "Failed").
An Error Message (e.g., "Single Sign-On failed. Please contact your administrator.").
An Additional Error field that often contains the specific, technical reason for the failure, such as "No assertion found in SAML response" or "User hasn't been provisioned in this organization."

This detailed error information is indispensable for an Identity Architect to pinpoint whether the problem is with the SAML response from the IdP, the Salesforce-connected app configuration, or the user provisioning.

Why Option A is Incorrect (Apex Exception Email):
This feature sends emails when unhandled Apex exceptions occur. Since the login process is a core platform function and not custom Apex code, a failed SSO login will not trigger an Apex exception. This tool is irrelevant for debugging standard authentication flows.

Why Option B is Incorrect (View Setup Audit Trail):
The Setup Audit Trail shows a history of configuration changes made in Salesforce Setup (e.g., "Changed SAML Single Sign-On Setting"). While it could be useful to see if the SSO configuration was recently modified, it does not provide any information about individual user login attempts or the specific errors they encountered. It audits administrative actions, not user authentication events.

Why Option C is Incorrect (Debug Logs):
Debug Logs are used to monitor the execution of custom Apex code and Visualforce pages. They generate detailed logs for specific users when that user triggers code. The standard SSO authentication process does not execute custom Apex code that would be captured in a debug log. Therefore, it will not contain information about why a SAML assertion failed to authenticate a user.

Reference
Salesforce Help: Monitor Login Activity
This document explains how to use Login History to investigate login issues.

Key Quote:
"Use Login History to monitor when and how users log in to your Salesforce org. Review login history to investigate login-related issues, such as... authentication failures for single sign-on (SSO)."