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

Explanation:

When User Provisioning is enabled for a Connected App, Salesforce can synchronize user data (such as profiles, roles, and permissions) with a third-party system. However, role synchronization is not automatic—it must be explicitly configured in the User Provisioning Settings.

Here’s why Option B is correct:

👉 Provisioning Requires Explicit Field & Operation Mapping
👉 Under User Provisioning Settings, administrators must define which user attributes (e.g., Role, Profile, Email) should be synced.
👉 If the "Role" field was not mapped or the "Update" operation was not enabled, role changes in Salesforce will not propagate to the third-party system.

Why the Other Options Are Incorrect:

👉 A. User Provisioning does support role sync → But it must be configured manually.
👉 C. An unmonitored Approval queue → Would delay provisioning but not block role sync specifically.
👉 D. Role hierarchy depth → Does not affect provisioning sync capabilities.

Conclusion:

The issue stems from missing field/operation mappings in User Provisioning Settings. To fix this, UC’s admin must:
✔ Map the RoleId field.
✔ Ensure "Update" operations are enabled for role changes.

Explanation:

Why this works
Register the native iOS app as a Connected App and use OAuth 2.0 for sign-in to Salesforce. You can privately distribute the app and restrict access via the Connected App (e.g., “Admin approved users are pre-authorized”).
Configure Salesforce as the IdP (SAML or OpenID Connect) for your other internal applications. After users authenticate to Salesforce in the mobile app, they can SSO into those apps using Salesforce-issued assertions/tokens—meeting the “self-authorize once logged in to Salesforce” requirement.

Why not the others
A mixes concepts imprecisely; the mobile app authenticates to Salesforce via OAuth, and SSO to other apps is handled by Salesforce as IdP (SAML/OIDC). That IdP setup is what B states clearly.
C adds an external IdP unnecessarily; the requirement is to use Salesforce for authentication.
D changing to a hybrid app is irrelevant; identity is solved with a Connected App + Salesforce as IdP, regardless of app framework.

Explanation:

For IoT devices or other hardware with limited input/output capabilities (e.g., no keyboard, small screen), the OAuth 2.0 Device Flow is specifically designed to handle authentication in such constrained environments.

Here’s how it works:
The device presents a user code and verification URL to the user.
The user completes authentication on a separate device (e.g., smartphone or computer).
Once authenticated, the device receives an access token to interact with Salesforce.
This flow is ideal for:
Smart appliances
Wearables
Industrial IoT sensors
Any device that cannot support full browser-based login

❌ Why the other options are incorrect:
🅰️ OAuth 2.0 JWT Bearer Flow
Used for server-to-server integrations where the client can sign a JWT.
Not suitable for devices with limited UI or user interaction.

🅲️ OAuth 2.0 User-Agent Flow
Requires a browser and user interaction, which IoT devices typically lack.

🅳️ OAuth 2.0 Asset Token Flow
Used for asset-based authentication in mobile SDKs.
Not applicable to general IoT device registration.

📘 Reference:
Salesforce Developer Guide: OAuth 2.0 Device Flow

Explanation:

B. Use an AppExchange product to sync users from Active Directory to Salesforce.
AppExchange tools like Okta, OneLogin, or Azure AD Enterprise Apps support automated user provisioning (via SCIM or custom APIs) directly from Active Directory. They can handle creating, updating, and deactivating users in Salesforce, including assigning profiles, roles, and permissions, often with minimal coding required.

D. Use Identity Connect to sync users from Active Directory to Salesforce.
Salesforce's Identity Connect is a managed solution explicitly designed to sync users and their metadata from AD to Salesforce. It supports provisioning, deprovisioning, SSO, and mapping of AD groups to Salesforce roles and profiles—meeting UC’s requirement to avoid manual user setup in Salesforce

❌ Why A and C Are Not Optimal

A. Using custom REST API integration from AD to Salesforce would require building and maintaining a custom middleware layer. This approach is more complex and error-prone than leveraging established provisioning tools.

C. ADFS handles authentication (SSO), not user provisioning. It won’t automatically create or manage Salesforce user records, roles or profiles—only authenticate users.

💡 Summary Table

Explanation:

Universal Containers (UC) wants to ensure SAML-based SSO works seamlessly for users accessing Salesforce via the Salesforce1 mobile app. Here’s why Options B and C are the best recommendations:

1. Option B: Configure the Salesforce1 App to Use My Domain URL
👉 For SAML SSO to work on the Salesforce1 mobile app, users must log in via My Domain (e.g., yourcompany.my.salesforce.com).
👉 If users try to log in directly through the app without My Domain, Salesforce defaults to username/password authentication instead of SAML redirection.
2. Option C: Use the Existing SAML-SSO Flow Along with User Agent Flow
👉 The User Agent Flow (also called the "WebView" flow) is the recommended OAuth flow for SAML SSO on mobile apps.
👉 It allows the Salesforce1 app to:
✔ Open a browser session (or embedded WebView) for SAML authentication.
✔ Redirect users to the IdP for login, then return them to the app with an OAuth token.

Why Not the Other Options?

A. Embedded Web Browser → While configuring My Domain is necessary, this option alone does not address the OAuth flow requirement for SAML SSO on mobile.
D. Web Server Flow → Designed for server-to-server authentication (not mobile SSO).

Explanation:

The goal is to use Salesforce as the central IdP and have the external applications appear in the Salesforce App Launcher for SSO. The correct sequence of required steps is:

A. Add each connected App to the App Launcher with a Start URL:
This is the specific step that makes the external application appear as a tile in the App Launcher. After the Connected App is created, you must configure its App Launcher settings by providing a Start URL (the login URL of the external application) and assigning it to the appropriate profiles or permission sets. This controls which users see which application tiles.
C. Set up Salesforce as a SAML Idp with My Domain:
This is the foundational step. You must first enable Salesforce to act as a SAML IdP. My Domain is a prerequisite for this functionality. Without a My Domain, you cannot configure Salesforce as an IdP. This setting is activated in Setup > Identity > Identity Provider.
E. Create a Connected App for each external application:
A Connected App in Salesforce represents the external application that will be relying on Salesforce for authentication. When you create the Connected App, you enable the SAML settings and configure the necessary parameters like the Entity ID (Audience) and ACS (Assertion Consumer Service) URL provided by the external application. This creates the trust relationship.

Why the other options are incorrect:
B. Set up an Auth Provider for each External Application:
This is the opposite of what is required. An Authentication Provider is used when you want Salesforce to act as a Service Provider (SP) and accept identities from an external IdP (like Google, Facebook, or an corporate AD). In this scenario, Salesforce is the IdP, not the SP.
D. Set up Identity Connect to Synchronize user data:
Identity Connect is a specific product for synchronizing passwords between Salesforce and an on-premise Active Directory. It is not required for configuring Salesforce as a SAML IdP or for managing access to external applications via the App Launcher. This is unrelated to the core SAML SSO setup.

Architectural Consideration:
This configuration creates a seamless user experience by centralizing application access through the Salesforce App Launcher. It leverages the existing user management and profile/permission set structures in Salesforce to control not only access to Salesforce data but also access to entirely external applications.

Reference:
Salesforce Help: "Use Salesforce as a SAML Identity Provider" - This outlines the prerequisites, including My Domain, and the steps to enable the Identity Provider.
Salesforce Help: "Create a Connected App for Use with a SAML Identity Provider" - This details how to configure the Connected App that represents the external service provider.

Explanation:

Universal Containers (UC) wants to simplify authentication across five Salesforce orgs (UC1, UC2, UC3, UC4, UC5), where every user in UC2–UC5 is also in UC1, but not all users have access to every org. The goal is to use one set of credentials with minimal cost and maintenance. The solution must leverage Salesforce’s identity capabilities and account for user provisioning across orgs.

A. Purchase a third-party Identity Provider for all five Salesforce orgs to use and set up JIT user provisioning on all other orgs:
Incorrect. Using a third-party Identity Provider (IdP) like Okta or Ping Identity introduces additional costs (e.g., licensing, integration, maintenance) and complexity, which contradicts UC’s goal of minimizing cost and maintenance. While Just-In-Time (JIT) provisioning could automate user creation in UC2–UC5, the third-party IdP is unnecessary when Salesforce can act as an IdP, leveraging existing infrastructure.

B. Purchase a third-party Identity Provider for all five Salesforce orgs to use, but don't set up JIT user provisioning for other orgs:
Incorrect. This option also incurs the cost and maintenance of a third-party IdP, which is not needed since Salesforce can serve as an IdP. Without JIT provisioning, user management across UC2–UC5 would require manual or custom synchronization, increasing maintenance effort and failing to simplify the process effectively.

C. Configure UC1 as the Identity Provider to the other four Salesforce orgs and set up JIT user provisioning on all other orgs:
Correct. Configuring UC1 as the SAML Identity Provider (IdP) allows users to authenticate once in UC1 and access UC2–UC5 via single sign-on (SSO) using the same credentials. Since all users in UC2–UC5 exist in UC1, UC1 can act as the central IdP, issuing SAML assertions to the other orgs (configured as Service Providers). JIT provisioning enables automatic user creation or updates in UC2–UC5 based on SAML attributes sent from UC1, reducing manual user management. This approach leverages Salesforce’s native identity features, minimizing cost (no external IdP) and maintenance (automated provisioning), while meeting the single-credential requirement.

D. Configure UC1 as the Identity Provider to the other four Salesforce orgs, but don't set up JIT user provisioning for other orgs:
Incorrect. While configuring UC1 as the IdP enables SSO with one set of credentials, not using JIT provisioning means users in UC2–UC5 must be manually created or synchronized, increasing maintenance effort. This contradicts UC’s goal of minimizing maintenance, as it requires ongoing administrative overhead to manage user access across orgs.

Why C:
Using UC1 as the SAML IdP leverages Salesforce’s built-in identity capabilities, avoiding the cost of a third-party IdP. JIT provisioning automates user management in UC2–UC5, ensuring users are created or updated with the correct profiles/permissions based on SAML attributes, minimizing maintenance. This solution supports SSO for a single set of credentials and aligns with UC’s goals of simplicity, cost-efficiency, and low maintenance.

References:
Salesforce Help: Set Up Salesforce as an Identity Provider
Trailhead: Identity Basics
Salesforce Help: Single Sign-On Overview

Explanation:

B. Leverage OpenID Connect Token Introspection.
OpenID Connect (OIDC) is built on top of the OAuth 2.0 protocol. A key part of the OAuth 2.0 and OIDC specifications is the concept of token introspection.
The Token Introspection endpoint (/services/oauth2/introspect) allows a client application to send a token to an authorization server (Salesforce, in this case) to determine its status. The server will respond with a JSON object that indicates whether the token is active, and provides additional metadata like the token's scope, the user it was issued for, and its expiration time.
This is the standard, designated method for a client to check the validity and status of an OAuth/OIDC token.

Incorrect Answer Rationale:

A. Query using OpenID Connect discovery endpoint.
The OpenID Connect discovery endpoint (/.well-known/openid-configuration) is used by a client to retrieve the metadata about the OpenID Provider (OP). This metadata includes the URIs for various endpoints, such as the authorization, token, and introspection endpoints. It does not provide the status of a specific access token.
C. Create a custom OAuth scope.
A custom OAuth scope defines a specific set of permissions that a client can request from a user during the authorization process. While scopes are essential for defining what a mobile app can do with the access token, they are not used to check the status or validity of an already issued token.
D. Enable cross-origin resource sharing (CORS) for the /services/oauth2/token endpoint.
CORS is a mechanism that allows a web page from one origin (e.g., www.example.com) to make requests to another origin (e.g., login.salesforce.com). It is relevant for browser-based applications (like single-page apps) to make API calls, but it is not the mechanism for a native mobile app to introspect a token. The mobile app would make a direct API call to the introspection endpoint, so CORS is not the relevant concern here.

Reference:
OpenID Connect Token Introspection: This is the most relevant Salesforce documentation for this question, detailing the introspection endpoint and its function.
OpenID Connect Dynamic Client Registration: This page explains how OAuth clients can check the state of their tokens using the introspection endpoint.
OpenID Connect (OIDC) Overview: This is a good overview of the OpenID Connect protocol, which is fundamental to the question.

Explanation:

Why:
In SP-initiated SAML, the SP sends a SAML AuthnRequest to the IdP and includes RelayState to carry opaque state (often the deep link or target resource). After authentication, the IdP returns the user to the SP along with the same RelayState, allowing the SP to redirect the user to the intended resource.

Why not the others:

A. RedirectURL — not a standard SAML parameter.
C. DisplayState — not part of the SAML spec.
D. StartURL — Salesforce-specific in some contexts, but the SAML-standard parameter for round-tripping target info is RelayState.

Explanation:

To ensure secure communication between Salesforce and the on-premise application, the Identity Architect must enforce certificate-based authentication, where Salesforce presents a trusted certificate to the on-premise system. Here’s why Option C is the best approach:

1. Certificate Authority (CA)-Signed Certificate Ensures Trust
👉 A CA-signed certificate (unlike a self-signed one) is inherently trusted because it is issued by a recognized Certificate Authority (e.g., DigiCert, GlobalSign).
👉 The on-premise application can validate this certificate via its Truststore, which contains trusted CA root certificates.

2. Steps to Implement This Solution:
👉 Generate a CA-signed certificate in Salesforce (or obtain one from a trusted CA).
👉 Upload the certificate (public key) to the on-premise Truststore, ensuring the app only accepts requests with this certificate.
👉 Configure Salesforce to present this certificate when calling the on-premise endpoint (e.g., in Named Credentials or Apex callouts).

Why Not the Other Options?

👉 A (Self-signed certificate) → Not inherently trusted; requires manual Truststore updates and is less secure.
👉 B (Firewall IP whitelisting) → Does not enforce certificate-based authentication (only network-level security).
👉 D (Third-party certificate from Salesforce) → Misleading; Salesforce does not issue third-party certificates—they must be obtained from a CA.