Explanation:

Salesforce Identity Connect is a specialized application that synchronizes user accounts and attributes between an on-premise Microsoft Active Directory (AD) and Salesforce. Its core functions are synchronization and lifecycle management.

C. Support multiple orgs connecting to multiple Active Directory servers. This is a key feature of Identity Connect. It can be configured in a hub-and-spoke model, where a single Identity Connect instance can synchronize users from multiple Active Directory forests/domains to multiple Salesforce orgs. This is essential for large enterprises with complex directory structures.

D. Automated user synchronization and de-activation. This is the primary purpose of Identity Connect. It provides automated, real-time (or scheduled) synchronization of user profiles, roles, and other attributes from AD to Salesforce. Crucially, it also handles de-activation: when a user is disabled or deleted in AD, Identity Connect can automatically deactivate the corresponding user in Salesforce, which is a critical security function.

Why the other options are incorrect:

A. Synchronization of Salesforce Permission Set Licence Assignments. This is incorrect. Identity Connect synchronizes standard user attributes from AD (like username, email, profile, role). However, the assignment of Permission Set Licenses is a Salesforce-specific licensing function that is not controlled by or synchronized from Active Directory. This is managed within Salesforce.
B. Supports both Identity-Provider-Initiated and Service-Provider-Initiated SSO. This is incorrect. Identity Connect is not an SSO product. It is strictly a user provisioning and de-provisioning tool. SSO (whether IdP-initiated or SP-initiated) is handled by separate protocols and configurations, such as SAML or OpenID Connect, often involving a federation service like ADFS. Identity Connect works alongside SSO solutions to ensure user accounts are synchronized, but it does not perform the SSO authentication itself.

Architectural Consideration:
Identity Connect solves the problem of user lifecycle management between an on-premise directory and the cloud. It ensures that user access in Salesforce is directly tied to their status in the corporate directory, enforcing a "joiner, mover, leaver" process automatically. This reduces administrative overhead and improves security.

Reference:
Salesforce Help: "Salesforce Identity Connect" - This documentation outlines its purpose, stating it "synchronizes your Microsoft Active Directory with your Salesforce organization to automate user creation, updates, and deactivations." It also discusses the multi-org and multi-directory capabilities.

Explanation:

To implement Social Sign-On for Salesforce Experience Cloud using providers like Facebook and LinkedIn, an Identity Architect should follow these core steps:

B. Create authentication providers for both Facebook and LinkedIn ✅
Salesforce provides built-in support for popular social identity providers. You must configure Authentication Providers under Setup > Auth. Providers for each service (Facebook and LinkedIn), specifying their client ID, client secret, authorize endpoint, etc.

C. Check "Facebook" and "LinkedIn" under Login Page Setup ✅
After the Auth Providers are set up, you can customize the login page in the Login & Registration section of the Experience Builder to display social login buttons for Facebook and LinkedIn.

E. Update the default registration handlers to create and update users ✅
You need to provide an Apex Registration Handler class to control how new users are created or updated when logging in via social accounts. This is crucial to link the external identity to Salesforce users and define user profiles, roles, etc.

❌ Incorrect Options

A. Register both Facebook and LinkedIn as connected apps
Incorrect: Connected Apps are used for OAuth clients or integrations, not required for social sign-on using Auth Providers.

D. Enable "Federated Single Sign-On Using SAML"
Incorrect: SAML is not used for social login like Facebook or LinkedIn, which use OAuth 2.0.

Explanation:

To automate user provisioning and deprovisioning into Salesforce from an external system, one of the most scalable and Salesforce-native solutions is SAML Just-in-Time (JIT) provisioning.

With SAML JIT:
👉 When a user attempts to log in via SAML Single Sign-On, Salesforce receives a SAML assertion from the Identity Provider (IdP).
👉 If the user does not exist in Salesforce, it is automatically created with the attributes provided in the assertion (e.g., username, email, profile, role).
👉 If the user already exists, the user record is updated with new values as defined in the mapping rules.
👉 It requires no pre-setup of user records in Salesforce—perfect for real-time provisioning and maintenance

❌ Incorrect Options:

A. Call SOAP API upsert on User object
Technically possible, but not the best practice for real-time identity lifecycle integration. Also requires custom integration and higher maintenance.
C. Run registration handler on incoming OAuth responses
Registration handlers are used with Auth Providers, but not standard for automated enterprise provisioning. This is better suited for social login or Experience Cloud.
D. Call OpenID Connect (OIDC)-userinfo endpoint with a valid access token
This fetches user information from an IdP—it doesn’t provision users into Salesforce.

Explanation:

Delegated Authentication allows Salesforce to delegate user authentication to an external service (e.g., a custom web service) instead of using Salesforce’s native password-based authentication. The architect must consider key aspects of its implementation to ensure it meets security and functionality requirements. Let’s evaluate each option:

A. The authentication web service can include custom attributes: Correct.
In Delegated Authentication, the external authentication web service (hosted by the organization) can process custom attributes sent by Salesforce during the authentication request (e.g., user ID, organization ID, or custom fields). This allows the external service to use additional context for authentication decisions, such as verifying user-specific data or applying custom logic, making it a key consideration for implementation.

B. It can be used to authenticate API clients and mobile apps: Incorrect.
Delegated Authentication is designed for interactive user logins (e.g., via the Salesforce UI) and is not typically used for API clients or mobile apps. API clients and mobile apps generally use OAuth flows (e.g., Web Server, User-Agent) or other protocols like JWT Bearer for authentication, as Delegated Authentication relies on a SOAP-based web service that is not optimized for programmatic or non-browser-based access.

C. It requires trusted IP ranges at the User Profile level: Incorrect.
Delegated Authentication does not mandate trusted IP ranges at the user profile level. Trusted IP ranges are a separate Salesforce security feature used to bypass multi-factor authentication (MFA) or restrict login access, but they are not a requirement for implementing Delegated Authentication. The external authentication service handles credential validation, independent of IP-based restrictions.

D. Salesforce servers receive but do not validate a user’s credentials: Correct.
In Delegated Authentication, Salesforce receives the user’s credentials (e.g., username and password) but forwards them to the external authentication web service for validation instead of checking them against Salesforce’s own database. Salesforce trusts the external service’s response (true/false) to authenticate the user, making this a critical consideration for security and implementation.

E. Just-in-Time Provisioning can be configured for new users: Incorrect.
Just-in-Time (JIT) Provisioning is specific to SAML-based SSO or OpenID Connect, where user attributes in a SAML assertion or ID token are used to create or update users in Salesforce. Delegated Authentication does not support JIT provisioning, as it focuses solely on credential validation and does not pass user attributes for provisioning purposes.

Why A and D:
A is critical because the ability to include custom attributes in the authentication request allows flexibility in how the external service validates users.
D is fundamental to Delegated Authentication’s mechanism, as Salesforce delegates credential validation to the external service, impacting security and integration design.

References:
Salesforce Help: Delegated Authentication Overview
Salesforce Help: Configuring Delegated Authentication
Trailhead: Identity Basics

Explanation:

Why these:
B. Require high assurance sessions for the Connected App. In the Connected App’s policies, require a High Assurance session. Map MFA to High Assurance in Session Settings, so the app is usable only after strong auth (e.g., MFA).
C. Use Google Authenticator (TOTP) as an extra factor. Salesforce supports MFA via TOTP apps such as Google Authenticator; using MFA for this sensitive, internal-only billing app is an appropriate control.

Why not:
A. Disallow SSO — SSO is typically beneficial (central policies, MFA at IdP). Disallowing it reduces control and user experience.
D. Set login IP ranges to internal network — Users are “commonly out of the office,” so restricting to internal IPs would block legitimate mobile access.

Explanation:

The requirement is for users to use their AD password for the Salesforce mobile app, but a VPN is not available. This means the authentication cannot happen directly against the on-premise AD server. The solution must bridge the on-premise AD world with the cloud-based mobile app.

A. Active Directory Password Sync Plugin: This is a specific component that works with Identity Connect. The Password Sync Plugin is installed on the on-premise Active Directory servers. Its job is to capture password changes as they happen in AD and securely transmit a one-way hash of the new password to Salesforce. This allows Salesforce to store a version of the password that it can validate against, without ever knowing the actual plaintext password.

D. Salesforce Identity Connect: Identity Connect is the central orchestrator for this solution. It is the application that synchronizes user accounts and, when combined with the Password Sync Plugin, password hashes from on-premise AD to Salesforce. It ensures that when a user's password is changed in AD, that change is reflected in Salesforce. This allows the user to enter the same AD password directly into the Salesforce mobile app, as Salesforce can now validate it against the synchronized hash.

Why the other options are incorrect:
B. Configure Cloud Provider Load Balancer: This is completely unrelated to identity and access management. A load balancer distributes network traffic across servers and has no role in synchronizing passwords or enabling authentication.
C. Salesforce Trigger & Field on Contact Object: This is a technical distractor. While you could theoretically build a completely custom system using Apex triggers and a custom field to store a password, this would be a massive security anti-pattern. It would involve handling and storing passwords in plaintext or with weak encryption, which is highly insecure and violates best practices. Salesforce provides supported, secure tools (Identity Connect) for this exact purpose.

Architectural Consideration:
The combination of Identity Connect and the Password Sync Plugin is the supported and secure method to achieve AD password synchronization for cloud authentication. It avoids the need for a VPN or exposing the on-premise AD server to the internet. The password hash is synchronized securely, and the actual plaintext password never leaves the user's device or the on-premise network during the capture process.

Reference:
Salesforce Help: "How Password Synchronization Works" - This documentation explains the role of both the Password Sync Plugin and Identity Connect in enabling users to log in with their network password.

Explanation:

Why:
Experience Cloud supports passwordless login where users enter an email or phone number, then verify with a code sent via email or SMS. The recommended way is to enable a Login Discovery page and implement a LoginDiscoveryHandler that accepts the identifier (email/phone) and orchestrates sending and verifying the code—no custom login page required.

What this looks like:
Enable Login Discovery for the site and generate the handler.
Configure verification method = Email or SMS so Salesforce sends the one-time code and completes login after verification.

References:
Salesforce Help — Email or Phone Number Registration with Passwordless Login (use Login Discovery).
Salesforce Help — Create a Custom Login Discovery Page (handler accepts email/phone and sends code).
Trailhead — Mobile-First Identity Experience (verification via email/SMS).

Explanation:

The company uses Salesforce to protect an external application via OAuth, and the identity architect needs to limit access to the protected resource’s data in a flexible manner. This requires controlling the scope of access granted to the external application through OAuth. Let’s evaluate each option:
A. Select "Admin approved users are pre-authorized" and assign specific profiles: Incorrect.
The “Admin approved users are pre-authorized” setting in a Connected App restricts which users can access the app by requiring them to have specific profiles or permission sets. While this controls who can access the app, it does not provide fine-grained control over the level of access (e.g., specific data or API operations). It’s a user-access restriction, not a data-access control, and thus lacks the flexibility needed.

B. Create custom scopes and assign to the connected app: Correct.
OAuth scopes define the level of access (e.g., specific APIs, objects, or operations) that the external application can perform when it receives an access token. By creating custom scopes in Salesforce (e.g., limiting access to specific standard or custom objects, read-only access, or specific API endpoints), the architect can flexibly control the data and operations available to the external application. Assigning these scopes to the Connected App ensures that the OAuth token grants only the necessary permissions, improving security by adhering to the principle of least privilege.

C. Define a permission set that grants access to the app and assign to authorized users: Incorrect.
Permission sets control user access to objects, fields, and features within Salesforce, including whether users can access a Connected App. However, they do not define the scope of data access for the external application itself during OAuth flows. This option addresses user authorization, not the flexible control of data access for the external app, making it less relevant.

D. Leverage external objects and data classification policies: Incorrect.
External objects are used to map data from external systems into Salesforce via External Data Sources, not to control OAuth access to Salesforce data. Data classification policies (e.g., for Data Loss Prevention or compliance) are unrelated to OAuth scope management. This option does not address the requirement to limit data access for the external application.

Why B:
Custom OAuth scopes allow the architect to define granular access levels (e.g., specific APIs, objects, or actions) for the external application, ensuring it only accesses authorized data. This provides flexibility and enhances security by restricting the application’s permissions, aligning with best practices for OAuth-based integrations.

References:
Salesforce Help: Define Custom OAuth Scopes
Salesforce Help: Connected Apps Overview
Trailhead: Identity for Developers
Salesforce Developer Docs: OAuth Scopes

Explanation:

The requirement is to ensure that users complete specific actions before their annual event. Passive approaches like emails, banners, or tasks can be ignored. The most effective method is to make the action a mandatory step in the process of accessing the community.

C. Create a login flow that conditionally prompts users...:
This is the correct and most robust approach.
A Custom Login Flow can interrupt the standard login process. After the user authenticates successfully, the flow checks certain conditions (e.g., a custom checkbox field RulesAccepted__c is false, or a LastContactUpdate__c date field is older than one year).
If the conditions are met, the user is redirected to a custom page where they are required to accept the rules and update their contact information before they can proceed to the community.
This method is proactive and unavoidable for the targeted users, guaranteeing compliance.

Why the other options are incorrect:
A. Create tasks for users...:
Tasks are easy to ignore or miss within the community. There is no mechanism to force a user to act on a task before using the community. This is a passive reminder system, not an enforcement mechanism.
B. Create a custom landing page and email campaign...:
Similar to option A, this relies on users proactively responding to an email and remembering to take action. Many users will login and bypass the landing page, or simply forget after reading the email. It lacks enforcement.
D. Add a banner to the community Home page...:
Banners are also passive and can be easily dismissed or ignored. A user can simply close the banner and continue using the community without updating their information or accepting the rules.

Architectural Consideration:
The login flow approach is architecturally sound because it uses a supported Salesforce feature to enforce business rules at the point of entry. It provides a high level of assurance that the required actions will be completed. This pattern is commonly used for mandatory password resets, terms of service acceptance, and multi-factor authentication enrollment—situations where action is required for security or compliance.

Reference:
Salesforce Help: "Create a Custom Login Flow" - The documentation for login flows explains how they can be used to perform post-authentication steps, like prompting users for additional information, which is the core concept needed here.

Explanation:

The OAuth 2.0 SAML Bearer Assertion Flow is specifically designed for scenarios where:

An external Identity Provider (IdP) issues a SAML assertion
That assertion is used to obtain an OAuth access token from Salesforce
The goal is to secure API access using federated identity

This flow allows applications to authenticate without user interaction, making it ideal for server-to-server integrations where administrators pre-authorize apps via Connected App policies.

✅ Why A is Correct:
Uses a SAML assertion to authenticate and authorize API access
Supports admin-approved apps via Connected App settings
Ensures secure, token-based access to Salesforce APIs

❌ Why the other options are incorrect:
🅱️ OAuth 2.0 JWT Bearer Flow
Uses a JWT, not a SAML assertion
Suitable for internal integrations, but not when SAML is required

🅲️ SAML Assertion Flow
Refers to SAML-based SSO for UI login, not for API access
Not part of the OAuth framework

🅳️ OAuth 2.0 User-Agent Flow
Designed for browser-based apps
Requires user interaction and does not support SAML assertions

📘 Reference:
Salesforce Developer Guide: OAuth 2.0 SAML Bearer Assertion Flow
Salesforce Help: Connected Apps and OAuth Flows

Explanation:

B. Enforce mutual authentication between systems using SSL.
Mutual Authentication (mTLS) is the standard and most robust mechanism to establish a trusted connection between two systems, especially when one is exposed to the internet.
In a delegated authentication setup, Salesforce initiates a SOAP web service call to UC's login service endpoint.
By enforcing mutual authentication, both Salesforce and UC's login service verify the identity of the other party using digital certificates during the Transport Layer Security (TLS/SSL) handshake. This ensures that Salesforce is communicating with the legitimate corporate login service and not an imposter, and that the corporate login service is communicating with a genuine Salesforce server.

Incorrect Answer Rationale:

A. Require the use of Salesforce security tokens on passwords.
A Salesforce security token is an extra layer of security for users accessing Salesforce from an untrusted IP address. It is intended for end-user security, not for securing server-to-server communication, which is what happens in a delegated authentication flow.

C. Include Client Id and Client Secret in the login header callout.
Client ID and Client Secret are credentials used in OAuth 2.0 flows, not in the SOAP-based delegated authentication web service call. While they are used to secure communication in OAuth scenarios, they are not the mechanism for establishing the server-to-server trust required here.

D. Set up a proxy service for the login service in the DMZ.
A proxy service in a Demilitarized Zone (DMZ) can be a component of the network architecture for security, but it is not the trust mechanism itself. The proxy service, even if used, would still need a secure, mutually authenticated connection to the backend login service to prevent unauthorized access. The core trust is established via mTLS, not the presence of a proxy.

Salesforce documentation:
Configure Salesforce for Delegated Authentication: Provides an overview of the delegated authentication setup process.
Certificates in Mutual Authentication for Salesforce: Explains how mutual authentication works and its purpose in securing server-to-server communication.
Best Practices for Implementing Single Sign-On: Offers guidance on securing SSO configurations, including the importance of secure connections.

Explanation:

Why:
To keep users signed in after the first login, the app needs a refresh token so it can get new access tokens silently. In Salesforce, refresh tokens can be issued (with the refresh_token / offline_access scope) via:
Web Server (Authorization Code) flow — common when you can manage the code exchange securely (PKCE is recommended for native apps).
User-Agent (Implicit) flow — designed for mobile/desktop clients; can also request a refresh token in Salesforce when the proper scope is granted.

Why not the others:
B. Mobile Agent flow — not an OAuth flow.
D. SAML Assertion flow — exchanges a SAML assertion for an access token, but doesn’t provide a refresh token for silent reauth in the app.