Explanation:
To enable social sign-on with providers like Facebook and Google (supporting OpenID Connect) in Salesforce, an Authentication Provider must be configured for each provider. Additionally, a Registration Handler (an Apex class) is required to map the external user's identity to an existing or new Salesforce user account, controlling how users are linked or created.

Correct Option:

C. configure an authentication provider and a registration handler for each social sign-on provider.
An Authentication Provider defines the connection details (client ID, secret, endpoints) for each social provider. A Registration Handler is an Apex class that implements the Auth.RegistrationHandler interface. It controls linking logic—whether to create a new user, link to an existing contact, or update user attributes. Both are mandatory for a complete social sign-on implementation.

Incorrect Option:

A. configure a single sign-on setting and a JTT handler for each social sign-on provider.
There is no "JTT handler" in Salesforce Identity terminology. SSO settings are for SAML, not for OIDC social providers. Social sign-on requires Authentication Providers, not SAML SSO configurations.

B. configure an authentication provider and an Auto-Time Unit handler for each social sign-on provider.
"Auto-Time Unit handler" is not a real Salesforce component. The correct component is a Registration Handler. This option uses fabricated terminology and would not work.

D. configure a single sign-on setting and a registration handler for each social sign-on provider.
SAML SSO settings are not used for social providers like Google or Facebook. Social sign-on uses OAuth 2.0/OIDC with Authentication Providers. A Registration Handler alone without the Authentication Provider is useless because there is no connection to the external IdP.

Reference:

Salesforce Help Article: "Set Up Social Sign-On for External Users"

Trailhead: "Social Sign-On" – Unit on "Configure Authentication Providers and Registration Handlers"

Salesforce Developer Guide: "Auth.RegistrationHandler Interface"

Explanation:

This scenario is about reducing password fatigue by letting employees authenticate once through the company’s existing identity provider, which already checks LDAP credentials. Salesforce should trust that external IdP and act as the service provider in the SSO flow.

Option D
✔️ Setup Salesforce as a Service Provider to the existing IdP.
This is correct because the existing IdP validates users against LDAP and then sends a trusted SSO response to Salesforce. Users log in once, which helps minimize the number of passwords they need to remember.

Option A
❌ Use Salesforce connect to synchronize LDAP passwords to Salesforce.
Salesforce Connect does not manage authentication or password synchronization. It is used for data access, so it cannot help employees remember fewer passwords.

Option B
❌ Setup Salesforce as an Authentication Provider to the existing IdP.
An authentication provider is not the best fit for this LDAP-backed enterprise SSO scenario. The company already has a third-party IdP, so Salesforce should not replace it as the login source.

Option C
❌ Setup Salesforce as an IdP to authenticate against the LDAP directory.
This reverses the required architecture. The third-party IdP is already authenticating against LDAP, so Salesforce does not need to be the identity provider.

🔧 Reference:
→ Salesforce as a Service Provider
— Confirms Salesforce can act as a service provider and rely on a third-party IdP for authentication.

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 controlling user access to external applications via OpenID Connect Connected Apps in Salesforce. The requirement is to ensure users can launch external Service Provider apps directly from Salesforce, but only if they are authorized.

This requires:

Centralized control over app access
Pre-approved trust configuration
User-level access assignment

🟢 Correct Options:

C. Set each of the Connected App access settings to Admin Pre-Approved
This is correct because setting a Connected App to Admin Pre-Approved ensures that only explicitly authorized users can access the app. It prevents open access and enforces centralized control, which is critical when launching external OIDC applications directly from Salesforce.

D. Use Profiles and Permission Sets to assign user access to Admin Pre-Approved Connected Apps
This is correct because once a Connected App is set to Admin Pre-Approved, access must be explicitly granted using Profiles or Permission Sets. This ensures that only specific users can initiate SSO from Salesforce to the external service provider application.

🔴 Incorrect options:

A. Manage which connected apps a user has access to by assigning authentication providers to the users profile
This is incorrect because Authentication Providers are not assigned via profiles to control app access. They are used for configuring external identity providers, not for managing Connected App access.

B. Assign the connected app to the customer community, and enable the users profile in the Community settings
This is incorrect because Community settings are for Experience Cloud access, not for controlling OAuth/OpenID Connected App access from Salesforce core platform.

🔧 Reference:
→ Connected Apps – Admin Pre-Approved Access and User Assignment
This documentation explains how Admin Pre-Approved Connected Apps combined with Profile/Permission Set assignments control which users can access external applications via OAuth/OpenID Connect from Salesforce.

Explanation:

The scenario involves using the JWT OAuth Bearer Token Flow (also called JWT Bearer Flow), which is a server-to-server OAuth 2.0 flow commonly used for secure integrations without user interaction.

To support JWT Bearer Flow, the following two settings are required on the Connected App:

A. Use Digital Signature
This option enables the Connected App to accept JWT assertions signed with a digital certificate.

You must upload a certificate (public key) in the Connected App.

This is mandatory for the JWT Bearer Flow because the JWT is signed using a private key, and Salesforce validates it using the uploaded certificate.

C. The "api" OAuth Scope
This scope grants the connected app permission to access Salesforce REST APIs.

Without the api scope, the app will not be able to call any Salesforce APIs even after getting the access token.

Why the other options are incorrect

B. The "web" OAuth Scope
This scope is used for web server flows where the user is redirected to a browser for authorization. It is not required (and usually not relevant) for the JWT Bearer Flow, which is a non-interactive, server-to-server flow.

D. The "eclair_api" OAuth Scope
This is an old/internal scope used for Analytics Cloud (Tableau CRM / Einstein Analytics). It has no relation to standard REST API access via JWT flow.