Free Salesforce Platform Identity and Access Management Architect Practice Test Questions

Explanation:

This question tests dynamic branding in an OAuth 2.0 flow where Heroku acts as the client and Experience Cloud as the IdP. The user selects a brand in Heroku before authorization. The IdP must render a login page with brand-specific images dynamically. Login Flows allow runtime decisions based on incoming parameters.

✔️ Correct Option:

✔️ A. Create multiple login screens using Experience Builders and use Login Flows at runtime to route to different login screens.
Login Flows evaluate the brand preference passed from Heroku (e.g., via display or custom parameter). Based on that value, the flow redirects the user to a brand-specific login screen built in Experience Builder. This enables dynamic image rendering before credentials are entered, meeting the requirement without multiple communities.

❌ Incorrect options:

❌ B. Authorize third-party service by sending authorization requests to the community. Authorizes/search? authorize?node=value.
This option contains malformed and non‑standard OAuth syntax. More critically, it does not address dynamic login screen rendering based on brand preference. Authorization parameters alone cannot change the login page UI at runtime.

❌ C. For each brand create different communities and redirect users to the appropriate community using a custom Login controller written in Apex.
Creating separate communities for each brand is over‑engineered and costly. While technically possible, Salesforce recommends Login Flows for dynamic branding within a single community. Custom Apex controllers add unnecessary maintenance complexity for this use case.

❌ D. Authorize third-party service by sending authorization requests to the community. Authorizes/search? authorize?coside_value.
This option contains a typo ("coside_value") and invalid OAuth syntax. Like option B, it only describes authorization request formatting and provides no mechanism to dynamically render brand‑specific login page images before authentication.

🔧 Reference:
→ Salesforce Help: Customize Login Experiences with Login Flows
Confirms that Login Flows can route users to different login pages, communities, or experience sites based on runtime criteria such as URL parameters, enabling dynamic branding.

Explanation:

This question tests knowledge of B2B partner provisioning in Salesforce Experience Cloud with SAML SSO and delegated administration. Partners need authentication (User record) and data association (Contact record). Delegated administration requires the Contact to be under the partner's Account hierarchy. Missing either record breaks SSO or partner management.

✔️ Correct Option:

✔️ A. Create a user and a related contact.
A User record stores login credentials, SAML federation ID, and profile/permissions. A related Contact links the user to a specific partner Account, enables partner hierarchy visibility, and is mandatory for delegated administration—allowing partner admins to manage only their own users. Both records together satisfy authentication, data ownership, and delegation requirements.

❌ Incorrect options:

❌ B. Create only a contact.
A Contact is a data object (name, email, phone) without login capabilities. It cannot store a SAML federation ID, assign a profile, or authenticate via an identity provider. Without a User record, the partner cannot access the Experience Cloud site at all.

❌ C. Create a contactless user.
A User without a Contact exists but has no relationship to any partner Account. Delegated administration fails because the system cannot determine which partner Account owns the user. Also, partner reports, account teams, and community sharing rules typically depend on the Contact-Account link.

❌ D. Create a person account.
Person Accounts combine Contact and Account fields into a single record, intended for B2C scenarios (e.g., retail customers). They do not support standard B2B partner delegation, cannot be used as parent accounts for multiple partner users, and often cause compatibility issues with Experience Cloud partner portal features.

🔧 Reference:
→ Salesforce Help: Set Up Partner Users in Experience Cloud
Confirms that each partner user requires both a User record (for login and permissions) and a Contact record (to link to a partner Account), and that delegated administration depends on this Contact-Account relationship.

Explanation:

This question is testing which Salesforce feature helps investigate authentication and login failures. For issues involving SSO, federation, or user sign-in problems, Login History is the built-in place to review failed login attempts, timestamps, source IP, and error details tied to the user’s login activity.

Option A
❌ News Legs
This is not a Salesforce feature for troubleshooting authentication issues. It does not provide login attempt details, error codes, or identity-provider-related failure information, so it cannot help debug SSO login problems.

Option B
❌ Web Apps Audit Trail
Audit trail tracks configuration changes made by administrators, not user login failures. It may help identify setup changes affecting SSO, but it does not show individual authentication errors when users try to sign in.

Option C
✔️ Login History
Login History is the correct feature because it records login attempts and failures, including the reason a login was blocked or rejected. This makes it the best place to debug SSO-related user access issues in Salesforce.

Option D
❌ About Exception Email
Exception emails are used for system or code errors, such as Apex exceptions, not for end-user authentication troubleshooting. They do not provide the login failure visibility needed for this scenario.

🔧 Reference:
→ Resolve User Login Problems
— Confirms Salesforce login issues can be investigated through login-related records and error details.

Explanation:

This question tests knowledge of the OAuth 2.0 User-Agent Flow (Implicit Grant Type) as implemented by Salesforce Identity for mobile applications. In this flow, the access token is returned directly to the client without an intermediate authorization code. Understanding which OAuth concepts participate in this flow is key.

✅ A. Refresh Token
In Salesforce's implementation, a refresh token can be returned in the user-agent flow if the refresh_token scope is explicitly included and the connected app is configured to allow it. This lets the app obtain new access tokens without re-prompting the user for credentials again.

✅ B. Client ID
The Client ID (Consumer Key) is a mandatory parameter in the user-agent flow. It identifies the connected app making the authorization request to Salesforce. Without it, Salesforce cannot recognize or validate the requesting application during the OAuth handshake.

✅ E. Scope
Scope defines the level of access the mobile application is requesting — such as api, openid, or refresh_token. It is a required parameter in the authorization request URL and controls what resources and data the issued token can access on behalf of the user.

❌ C. Verification Code
A Verification Code is not part of the standard OAuth 2.0 user-agent (implicit) flow. It belongs to device authentication flows or PKCE, not the implicit grant type. It plays no role in how tokens are requested or returned in this flow.

❌ D. Authorization Code
The Authorization Code belongs exclusively to the OAuth 2.0 Authorization Code Flow. In the implicit/user-agent flow, the access token is returned directly in the URL fragment — no intermediate authorization code is issued or exchanged at any stage.

🔧 Reference:
→ OAuth 2.0 User-Agent Flow – Salesforce Help
Confirms Client ID, Scope, and Refresh Token as key parameters used in the implicit grant flow and token response behavior.

Explanation:

The question tests knowledge of external authentication methods in Salesforce when regulatory rules require that all password storage and validation occur outside Salesforce. The key constraint is that authentication requests must be handled by a customer-owned system accessible only via SOAP webservice.

✔️ Correct Option:

B. Delegated Authentication
Delegated Authentication is designed for this exact use case. Salesforce sends the username and password entered on the login page to an external SOAP endpoint you host. Your service validates the credentials and returns true/false. Salesforce never stores or manages passwords, meeting the CIO’s requirement for external control via SOAP.

❌ Incorrect options:

A. Just-in-Time Provisioning
JIT handles automatic creation or updates of user records in Salesforce when a user logs in via SAML or an Auth Provider. It manages user provisioning attributes, not real-time password validation against an external SOAP service. So it doesn’t satisfy the requirement to externalize authentication requests.

C. Security Assertion Markup Language (SAML) Single Sign On
SAML SSO uses assertions from an identity provider to log users in without sending passwords to Salesforce. It bypasses the Salesforce login page and doesn’t invoke a customer SOAP webservice for password checks. Therefore it cannot meet the stated SOAP-based validation requirement.

D. OAuth Web-Server Flow
This OAuth flow is for authorizing external apps to access Salesforce APIs on behalf of a user and issues access tokens. It’s not used for direct user login to the Salesforce UI and does not delegate password verification to an external SOAP endpoint as required.

🔧 Reference:
→ Delegated Authentication – Confirms Salesforce calls an external SOAP web service to authenticate users and does not validate or store passwords internally.

Explanation:

This question tests knowledge of OpenID Connect standards within Salesforce Identity. Token introspection is a standard OAuth 2.0 / OpenID Connect endpoint that allows a client or resource server to check the active state, expiration, and metadata of an access token. This is exactly what is needed to retrieve the access token status.

✔️ Correct Option:

✔️ A. Leverage OpenID Connect Token Introspection.
Token Introspection (RFC 7662) provides a standard endpoint (/services/oauth2/introspect) that accepts an access token and returns its active status, scope, client ID, expiration, and other metadata. This allows the mobile app to programmatically validate whether an access token is still valid, without attempting to use it.

❌ Incorrect options:

❌ B. Query using OpenID Connect discovery endpoint.
The discovery endpoint (/.well-known/openid-configuration) returns metadata about the IdP's endpoints and capabilities. It does not retrieve the status of a specific access token. It is used for configuration, not token validation.

❌ C. Enable cross-origin resource sharing (CORS) for the /services/oauth2/token endpoint.
CORS allows web applications from different domains to call Salesforce APIs. It does not provide token status information. CORS is a browser security mechanism, not a method to inspect token validity or metadata.

❌ D. Create a custom OAuth scope.
Custom OAuth scopes control which resources or permissions a token grants access to. Scopes do not retrieve token status or introspection data. They define authorization boundaries, not token validation capabilities.

🔧 Reference:
→ Salesforce Help: Introspect an Access Token with OpenID Connect Token Introspection
Confirms that the /services/oauth2/introspect endpoint returns the active status and metadata of an access token for OpenID Connect connections.

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.

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.

Explanation:

This question tests the setup sequence for Salesforce SAML JIT provisioning. After SAML SSO is already configured, the next step is to turn on user provisioning in the SSO settings, choose either Standard or Custom provisioning, and specify the Apex handler if custom logic is needed.

Option A
✔️ Enable Just-in-Time User Provisioning in the SAML Single Sign-On Setting, configure the User Provisioning Type, and provide the SAML JIT Handler.
This is correct because Salesforce enables JIT from the Single Sign-On Settings page. Admins must select User Provisioning Enabled, choose a provisioning type, and, for custom handling, assign an Apex class that implements the JIT handler interface. This directly activates automatic create or update behavior during first SSO login.

Option B
❌ Create a new permission set with JIT provisioning enabled, configure the necessary permissions, and assign the permission set to relevant users.
Permission sets do not enable JIT provisioning. JIT is controlled in SAML Single Sign-On Settings, not through a permission set. Permissions may be needed for the executing user, but they are not the mechanism that turns JIT on.

Option C
❌ Create a new Apex class to handle JIT provisioning, implement the required methods, and assign the class to the appropriate user profiles.
Apex is only required when using Custom SAML JIT with an Apex handler. The class is not assigned to user profiles. Instead, it is selected in the SSO settings as the JIT handler, and the execution user is configured there.

Option D
❌ Modify the organization-wide sharing settings to allow JIT provisioning, update the sharing rules for the user object.
Sharing settings do not enable JIT provisioning. JIT is an authentication and user-creation feature, not a record-sharing feature. Adjusting OWD or sharing rules will not activate the SAML provisioning process.

🔧 Reference:
→ Enable Just-in-Time Provisioning
— Confirms the exact setup steps: enable user provisioning in SAML SSO settings, choose provisioning type, and specify the JIT handler.

Explanation:

This question tests knowledge of Salesforce SSO configuration with multiple ADFS systems across different regions in a single org. The key constraints are: one Salesforce org, multiple ADFS instances (Americas, Europe, APAC), and no additional application procurement. The solution must be native to Salesforce capabilities.

✅ B. Configure Each ADFS system under single sign-on settings and allow users to choose the system to authenticate during sign on to Salesforce.
Salesforce natively supports multiple SAML SSO configurations within a single org. Each regional ADFS system can be registered as a separate SSO provider. Users can select the appropriate ADFS system at login without requiring any additional licensed product or third-party application, fully satisfying the cost-limitation requirement.

❌ A. Implement Identity Connect to provide single sign-on to Salesforce and federated across multiple ADFS systems.
Salesforce Identity Connect is a separate licensed product that must be procured additionally. Since the company explicitly wants to avoid purchasing additional applications, this option directly contradicts the stated budget and procurement constraints of the requirement.

❌ C. Add a central identity system that facilitates between the ADFS systems and integrate with Salesforce for single sign-on.
Introducing a central identity broker requires procuring and deploying an additional application or middleware. This violates the company's preference to limit investments. It also adds unnecessary architectural complexity when Salesforce already natively supports multiple SAML SSO providers.

❌ D. Use connected apps for each ADFS implementation and implement Salesforce site to authenticate users across the ADFS system applicable to their geo.
Connected Apps are designed for OAuth-based integrations, not SAML-based SSO federation with ADFS. Using Salesforce Sites as an authentication layer adds significant complexity and is not the standard or recommended approach for enterprise-wide SSO with Active Directory Federation Services.

🔧 Reference:
→ Configure SSO with Salesforce as the Service Provider – Salesforce Help
Confirms that Salesforce supports multiple SAML SSO configurations within a single org, allowing different identity providers per region without additional products.