Free Salesforce Platform Identity and Access Management Architect Practice Test Questions

Explanation:

This question tests your understanding of Salesforce Identity Connect capabilities when integrating Microsoft Active Directory. It focuses on user lifecycle management and security controls that Identity Connect provides beyond basic provisioning and SSO between AD and Salesforce.

✔️ Correct Option:

D. When Identity Connect is in place, if a user is deprovisioned in an on-premise AD, the user’s Salesforce session is revoked immediately.
Identity Connect supports real-time deprovisioning. When a user is disabled or deleted in AD, Identity Connect immediately deactivates the Salesforce user and revokes active sessions via the Identity Connect Event Monitoring integration. This ensures terminated users lose Salesforce access instantly, which is critical for compliance.

❌ Incorrect options:

A. Identify Connect can be deployed as a managed package on Salesforce org, leveraging High Availability of Salesforce Platform out-of-the-box.
Identity Connect is not a managed package installed in the Salesforce org. It’s a separate on-premise Java application that you install and manage on your own servers. It does not automatically inherit Salesforce platform HA and must be clustered manually for high availability.

B. When configured, Identity Connect acts as an identity provider to both Active Directory and Salesforce, thus providing SSO as a default feature.
Identity Connect is not an identity provider. It acts as a provisioning bridge between AD and Salesforce. For SSO, you still need a separate SAML IdP like AD FS or Azure AD. Identity Connect itself doesn’t issue SAML assertions, so SSO is not a default feature of Identity Connect.

C. If the number of provisioned users exceeds Salesforce licence allowances, Identity Connect will start disabling the existing Salesforce users in First-in, First-out (FIFO) fashion.
Identity Connect does not automatically disable users based on license counts or use FIFO logic. Provisioning stops or fails if you hit license limits, and admins must resolve it. Salesforce will not auto-deactivate existing users, as that would cause data and access issues.

🔧 Reference:
→ Salesforce Help – Identity Connect – Confirms Identity Connect synchronizes user changes from AD to Salesforce and immediately deactivates users plus revokes sessions when they are removed from Active Directory.

Explanation:

This question tests knowledge of establishing trust between Salesforce (as Service Provider) and an external identity provider for SAML-based SSO. SAML trust is established through metadata exchange, where both parties share XML files containing entity IDs, certificate public keys, endpoints, and binding configurations. This allows each system to cryptographically verify assertions and redirect URIs without custom code or network tunnels.

✔️ Correct Option:

✔️ C. Configuring a trust relationship by exchanging metadata XML files between Salesforce and the IdP.
SAML 2.0 defines metadata XML containing issuer URIs, X.509 certificates, endpoints (ACS for SP, SSO for IdP), and supported bindings. Admins upload IdP metadata into Salesforce's SAML SSO settings and provide Salesforce metadata to the IdP. This establishes cryptographic trust and correct message routing. This is the standard, code-free method recommended by Salesforce.

❌ Incorrect options:

❌ A. Setting up a VPN (Virtual Private Network) tunnel between Salesforce and the identity provider for secure communication.
SAML communications happen over standard HTTPS (port 443) with TLS, not VPN tunnels. VPN is unnecessary, often impossible (Salesforce cannot join customer VPNs), and adds operational overhead. SAML security relies on XML signatures and HTTPS, not network-layer tunnels.

❌ B. Embedding the identity provider's authentication code directly into Salesforce source code.
Salesforce is a multi-tenant cloud platform; customers cannot embed external authentication code into core Salesforce source code. This violates platform architecture, security boundaries, and upgradeability. SAML integration requires configuration, not code injection.

❌ D. Creating a custom login page within the Salesforce platform for user authentication.
A custom login page changes the UI but does not establish trust with an external IdP. In SAML SSO, authentication occurs at the IdP, not on a Salesforce login page. This option defeats SSO by keeping authentication within Salesforce instead of delegating to the IdP.

🔧 Reference:
→ Salesforce Help: Configure SAML SSO with Metadata Files
Confirms that admins can upload IdP metadata XML to Salesforce or download Salesforce SP metadata for the IdP to establish a trust relationship.

Explanation:

This question explores the fundamental components of the OAuth 2.0 User-Agent Flow, which is typically utilized by mobile and desktop applications. It tests the architect's ability to identify which parameters are required to define permissions and establish long-term access in a browser-based redirection model.

✅ Option A: Scopes:
Scopes are essential in the User-Agent flow as they define the specific permissions the mobile application is requesting, such as api, web, or refresh_token. During the flow, these scopes are presented to the user on the authorization screen, allowing them to explicitly grant or deny the application access to specific parts of their Salesforce data.

✅ Option B: Client ID:
The Client ID (known as the Consumer Key in Salesforce) is a unique identifier for the Connected App. In the User-Agent flow, the mobile app must provide this ID in the initial authorization request so Salesforce can identify which application is requesting access and apply the correct security policies and redirect URIs configured for that specific app.

✅ Option E: Refresh Token:
While the standard OAuth 2.0 Implicit Grant does not typically support refresh tokens, the Salesforce User-Agent flow does allow an application to request a refresh_token scope. If granted, Salesforce returns a refresh token alongside the access token, enabling the mobile app to maintain long-term access without requiring the user to re-authenticate every time the short-lived access token expires.

❌ Option C: Authorization Code:
The Authorization Code is a concept exclusive to the OAuth 2.0 Web Server Flow, where a temporary code is exchanged for an access token on a secure backend server. In the User-Agent flow (Implicit Grant), no intermediate code is used; the access token is returned directly in the URL fragment after the user authenticates.

❌ Option D: Verification Code:
A "Verification Code" is generally used in the Device Flow (for devices with no browser) or during Multi-Factor Authentication (MFA) challenges. It is not a core architectural component of the standard OAuth 2.0 User-Agent flow used to establish the identity and permission handshake between a mobile client and Salesforce.

🔧 Reference:
→ Salesforce Help: OAuth 2.0 User-Agent Flow
This documentation confirms that Client ID, Scopes, and Refresh Tokens are integral parts of the User-Agent flow used to secure mobile and desktop apps.

Explanation:

This scenario is about enabling social sign-in for a B2C website that does not support SAML or OAuth natively. Salesforce Identity must provide external authentication, user registration, and seamless login integration.

You need features that support:

Social identity federation
External app trust
Embedded customer login experience

🟢 Correct Options:

A. Connected Apps
Connected Apps establish the trust framework between Salesforce and external applications. They are required to configure authentication flows, define access policies, and enable secure integration for external websites using Salesforce Identity services.

B. Authentication Providers
Authentication Providers enable social login and external identity federation (Google, Facebook, etc.). They allow users to authenticate using third-party identity systems and map external identities into Salesforce customer records. This is the core feature for social sign-in.

D. Embedded Login
Embedded Login allows Salesforce authentication and registration UI to be embedded directly into a B2C website. It is essential when the external system does not support SAML or OAuth, providing seamless login without requiring protocol implementation on the website.

🔴 Incorrect Options:

C. Delegated Authentication
Delegated Authentication forwards password validation to an external system. It is not designed for social login or identity federation and does not support modern customer authentication experiences.

E. Identity Connect
Identity Connect is used for syncing enterprise users between Active Directory and Salesforce. It is intended for internal workforce identity management, not B2C social sign-in or customer authentication.

🔧 Reference:
→ Salesforce Identity – Authentication Providers and Social Sign-On
This document explains how Salesforce uses Authentication Providers, Connected Apps, and Embedded Login to enable social sign-in and external customer authentication for B2C websites.