Explanation:

This question tests knowledge of Active Directory integration with Salesforce for mobile authentication without VPN access. Since employees cannot use mobile VPN, any solution requiring a direct network tunnel to the corporate AD is not viable. The recommended approach must allow AD credentials to work with Salesforce authentication without requiring VPN connectivity on mobile devices.

✅ A. Active Directory Password Sync Plugin
The AD Password Sync Plugin synchronizes Active Directory passwords directly to Salesforce user accounts. When users update their AD password, it is synced to Salesforce automatically. Since the credentials are stored in Salesforce, mobile users can authenticate using their AD password without needing VPN access, making this ideal for mobile scenarios.

✅ B. Salesforce Identity Connect
Salesforce Identity Connect bridges Active Directory and Salesforce, enabling SSO and real-time user attribute synchronization. It authenticates users against AD credentials through Salesforce without requiring a mobile VPN connection. It also handles user provisioning and deprovisioning, providing a comprehensive identity management solution for AD-integrated Salesforce environments.

❌ C. Salesforce Trigger & Field on Contact Object
Triggers and Contact object fields have no relevance to Active Directory authentication or password management. Contact objects are for customer records, not employee authentication. This option does not address the requirement of enabling AD-based login on the Salesforce mobile app in any way.

❌ D. Configure Cloud Provider Load Balancer
A Cloud Provider Load Balancer manages traffic distribution and availability — it is an infrastructure component, not an identity or authentication solution. It has no capability to facilitate Active Directory password-based authentication for Salesforce mobile users or replace VPN-dependent authentication flows.

🔧 Reference:
→ Salesforce Identity Connect – Salesforce Help
Confirms that Identity Connect integrates Active Directory with Salesforce for SSO and user sync, enabling AD credential-based login without requiring mobile VPN access.

Explanation:

This question is testing how Salesforce uses Authentication Method Reference in Login History for MFA visibility. AMR is driven by the identity provider and is used to show which authentication methods were used. It is especially relevant to OIDC, while SAML support depends on the IdP supplying the required authentication context.

Option A
✔️ Both OIDC and Security Assertion Markup Language (SAML) are supported but AMR must be implemented at IdP.
This is correct because Salesforce does not invent the AMR values itself. The identity provider must send the authentication method information, and Salesforce can then record it. Support varies by protocol and IdP implementation, so the IdP must provide the data correctly.

Option B
❌ High-assurance sessions must be configured under Session Security Level Policies.
High-assurance session settings are related to enforcing stronger access, but they are not the main consideration for reading AMR in Login History. The AMR field is about what the IdP reported, not just the Salesforce session policy.

Option C
✔️ AMR field shows the authentication methods used at IdP.
This is correct because the Login History AMR column reflects the methods the identity provider used to authenticate the user. It helps architects verify whether secure methods such as MFA were actually used during login.

Option D
❌ Dependency on what is supported by OpenID Connect (OIDC) implementation at IdP.
This is too narrow as a standalone answer. While OIDC support is important, the broader point is that AMR must be supplied by the IdP and Salesforce can display it in Login History. The question is not limited only to OIDC.

🔧 Reference:
→ Monitor How Your Identity Providers Authenticate Your Users with Authentication Method Reference
— Confirms the AMR field in Login History shows authentication methods returned by the IdP.

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:

This question tests your understanding of the specific functionality of Salesforce Identity Connect within a complex enterprise architecture that already has an existing SSO solution.

The Scenario: NTO already has a Third-Party SSO solution (which acts as the Identity Provider or IdP) and Microsoft Active Directory (the Source of Truth for credentials).
The Need: NTO specifically wants "automatic provisioning and deprovisioning" for Salesforce.

Why User Management?
Identity Connect is a synchronization tool that sits between Microsoft Active Directory and Salesforce. Its primary purpose is to monitor AD for changes (like a new hire, a name change, or an employee termination) and instantly push those changes to Salesforce User records. While Identity Connect can handle SSO, in this specific architecture, the requirement is focused on the User Lifecycle (provisioning/deprovisioning), which falls under the category of User Management.

Why other options are incorrect:

Single Sign-On / Identity Provider:
The prompt explicitly states that NTO already owns a third-party SSO solution for all corporate applications. Therefore, Identity Connect is not being brought in to fulfill the SSO or IdP role; it is being added specifically to solve the data synchronization gap that many SSO solutions don't handle natively.

Service Provider:
In this integration, Salesforce is the Service Provider (the application being accessed). Identity Connect is a piece of middleware or an "add-on" that manages the users within that Service Provider.

🔧 Reference:
→ Salesforce Help: Identity Connect Product Overview
This documentation confirms that Identity Connect's core strength is integrating Active Directory with Salesforce to manage user accounts, attributes, and permissions automatically.

Explanation:

This question asks about establishing trust between Salesforce and an external directory service for authentication and authorization. The goal is to integrate Salesforce (as a service provider) with an external directory that authenticates users. The industry-standard approach for this is federation using SAML, which allows the external directory to act as the Identity Provider (IdP) and Salesforce to act as the Service Provider (SP). This creates a trust relationship where the IdP provides authentication assertions that the SP trusts, enabling Single Sign-On (SSO) without synchronizing or sharing raw passwords across systems.

✔️ Correct Option:

✔️ D. Implementing a federated identity solution based on SAML (Security Assertion Markup Language).
SAML is an open standard designed specifically for exchanging authentication and authorization data between an identity provider (the external directory) and a service provider (Salesforce) . The trust is established by exchanging SAML metadata, including entity IDs and signing certificates, so Salesforce can verify that incoming assertions are genuinely from the trusted directory . This creates a federated, SSO-based relationship that does not require storing or synchronizing user passwords, aligning with security best practices for enterprise identity architecture.

❌ Incorrect options:

❌ A. Utilizing email-based verification for user authentication across the systems.
Email-based verification is a secondary factor or account confirmation method, not a robust protocol for establishing trust between enterprise systems. It is inherently insecure for primary authentication because emails can be intercepted or spoofed, and it does not provide a standardized way for Salesforce to trust the external directory's authentication assertions.

❌ B. Using a shared database table to synchronize user credentials between the two systems.
This is a security anti-pattern. Storing or synchronizing passwords between systems dramatically expands the attack surface and violates credential management best practices. It also requires complex, custom-built synchronization logic and does not provide real-time trust or standardized identity federation. SAML federation keeps credentials securely within the directory without exposing them to Salesforce.

❌ C. Enforcing IP-based access restrictions for Salesforce and the external directory service.
IP restrictions control where a user can connect from but do nothing to prove who the user is or establish trust between two systems. An attacker could bypass IP restrictions from a permitted network, and this approach does not solve the requirement of having the external directory authenticate the user for access to Salesforce.

🔧 Reference:
→ Salesforce Help: SAML Single Sign-On
Confirms that SAML enables Salesforce to act as a service provider trusting an external identity provider for authentication.