Explanation:

How Customer 360 Identity Contributes to Truth
The goal of Customer 360 Truth is to create a single source of the truth for every customer. Customer 360 Identity is a fundamental component that powers this goal.

Unified Authentication (Single Login - B):
By creating a single login (e.g., through Single Sign-On or a unified registration process), Customer 360 Identity ensures that when a customer accesses any of UC's applications (website, mobile app, service portal), they are authenticated using the same, trusted identity record.
This identity record is assigned a unique identifier (like a Global Party ID - GPID), which then serves as the key to link and unify all the customer's behavioral and transactional data across disparate systems in the Customer 360 Data Manager. This is the bedrock of the "single source of truth."

Cross-Brand Identity Management (C):
In a multi-brand or multi-site organization like UC, customers might interact with several different digital properties (e.g., "NTO Outdoors" vs. "NTO Camping").

Customer 360 Identity centralizes the user authentication for all these brands. This means the system can confidently correlate activity across all experiences to the same unique customer profile, even if the branding is different. This ensures that the unified customer profile is complete, reflecting all interactions across the entire corporate family, which is critical for accurate "Truth."

Why the other options are incorrect:
A is incorrect: While Customer 360 Identity works with Data Manager and Audiences, it does not automatically integrate to "seamlessly populate all user data." Customer 360 Data Manager (or Data Cloud) is the component responsible for the heavy lifting of connecting, matching, reconciling, and ultimately unifying the data from all sources (including the Identity data).
D is incorrect: The core feature of tracking anonymous user activity prior to sign-up is primarily the function of Customer 360 Audiences (Salesforce's Customer Data Platform - CDP) and related data services, which unify known (authenticated) and unknown (anonymous) data. Customer 360 Identity focuses on the authenticated user experience (login, registration, security).

Explanation:

Why these are correct?

B. UC will be required to develop and support a custom SOAP web service.
Delegated Authentication (DA) works by having Salesforce call your authentication endpoint. Salesforce’s guidance is to “wrap your authentication method in a web service that Salesforce can consume” (implemented via SOAP for DA), which you must build, host, and maintain.
C. Salesforce users will be locked out of Salesforce if the web service goes down.
If DA is the sole login path and your DA endpoint is unavailable, Salesforce can’t validate credentials—users with DA enforced can’t log in. This is why it’s common to exclude at least a break-glass admin from DA so they can still log in if SSO/DA is down.

Why the others are not correct
A. Delegated Authentication is enabled or disabled for the entire Salesforce org.
You enable the DA feature at the org level, but whether a user is actually forced to use DA is controlled per user (profile/permission set) via the “Is Single Sign-On Enabled” permission. So it isn’t an all-or-nothing user impact.
D. The web service must reside on a public cloud service, such as Heroku.
There’s no such hosting requirement. Salesforce only requires that it can reach your DA web service; it can be hosted on-prem or in any cloud. The setup docs simply say to provide a web service endpoint—no mandate for Heroku or any specific provider.

References:
Salesforce Help: Delegated Authentication overview & setup (“wrap your authentication method in a web service…”, user-level control via permissions).
Ping Identity support example of DA outage error (“Your company’s authentication service is currently down”).
Salesforce StackExchange best practice to keep an admin able to log in if SSO/DA is down.

Explanation:

Delegated Authentication is a mechanism in Salesforce that allows you to delegate login authentication to an external system (such as an on-premise Active Directory or another identity service). It works by having Salesforce make a web service call (either SOAP or REST) to the external authentication service during the login process.

Here are the correct capabilities:

B. It can connect to SOAP services. ✅
Delegated Authentication traditionally supports SOAP-based services. Salesforce sends a username and password to the delegated authentication endpoint, and expects a Boolean (true/false) response indicating authentication success.

C. It can be assigned by Profiles. ✅
Delegated Authentication is enabled at the Profile level. This allows Salesforce administrators to specify which users must use delegated authentication for login instead of standard Salesforce credentials.

D. It can connect to REST services. ✅
As of recent updates, REST support is also available via custom implementations, although SOAP is the most officially supported and common. Developers can configure a RESTful endpoint for Salesforce to use in delegating the login authentication.

❌ A. It can be assigned by Custom Permissions.
This is incorrect. Delegated Authentication cannot be assigned by Custom Permissions. It is controlled via Profiles, not permission sets or custom permissions.

Explanation:

Social Sign-On Setup: Universal Containers will configure Facebook as an Authentication Provider in Salesforce.
Registration Handler: When a user logs in for the first time using a social provider (like Facebook), Salesforce executes a custom Apex class called the Registration Handler (which implements the Auth.RegistrationHandler interface).
Core Logic: The primary purpose of the createUser method in the Registration Handler is to automatically create the corresponding Salesforce User and Contact/Account record in the community.
External System Integration: To meet the requirement of automatically creating the account in the external accounting system, the Registration Handler's createUser method is the ideal place to add an Apex callout. This callout will invoke the accounting system's web service to create the customer record before the Salesforce community user is fully provisioned and logged in.

Why the Other Options are Incorrect

A. Create a custom application on Heroku that manages the sign-on process from Facebook.
This is overly complex. Salesforce provides native Authentication Provider functionality to handle social sign-on directly, making an external Heroku application unnecessary for this specific requirement.

B. Use JIT Provisioning to automatically create the account in the accounting system.
JIT Provisioning (Just-in-Time) in Salesforce is primarily for SAML and for creating the Salesforce User record, not for directly triggering external systems. While the Registration Handler (used for both social login and custom JIT) does the provisioning, the action of calling the external accounting system is a code-based step (Apex callout), not a standard JIT feature.

D. Use OAuth JWT flow to pass the data from Salesforce to the Accounting System.
The OAuth JWT Bearer Flow is a method for Salesforce (or any client) to authorize itself to an external service without an interactive login. While the accounting system callout would likely use a secure authorization method like JWT or Named Credentials, this option describes the authorization method (a technical detail of the callout) rather than the mechanism that triggers the required business logic upon first login. The Registration Handler (Option C) is the correct triggering mechanism.

Explanation:

Why:
A. Public Group assignment — YES. Identity Connect can map AD group membership to Salesforce Public Groups, adding/removing users accordingly.
C. Role assignment — YES. You can map AD attributes/groups to set a user’s Role in Salesforce.
E. Permission Set assignment — YES. AD groups can be mapped to Permission Sets so users inherit app-level capabilities.

Eliminate the others:

B. Granting report folder access — NO (not directly). Folder access is controlled by Salesforce sharing (e.g., to roles/public groups). Identity Connect doesn’t grant folder access itself—though adding users to Public Groups (A) can indirectly affect folder access if those groups are used in sharing.
D. Custom permission assignment — NO (not directly). Custom permissions are granted via Permission Sets/Profiles. Identity Connect doesn’t assign custom permissions on their own; use Permission Set mapping instead (covered by E).