Explanation:

When designing a Delegated Authentication implementation in Salesforce, one of the most critical design considerations is how the external authentication web service will identify the user attempting to log in. Salesforce typically uses the Federation ID as the key identifier in Delegated Authentication setups.
The Federation ID is a unique value on the Salesforce User record that correlates with the user’s identity in the external identity system. During the Delegated Authentication process, Salesforce sends the username or Federation ID to the external web service, which then verifies the credentials and returns a success or failure response.
Therefore, the correct and secure approach is to design the web service to recognize and authenticate users based on the Federation ID, making Option C the correct choice.

Other options are incorrect or misleading:

A is incorrect because while the connection should be secured via TLS, there’s no requirement to use Salesforce trusted certificates specifically — standard SSL/TLS with a trusted CA is sufficient.

B is incorrect because the delegated authentication web service doesn’t need to accept a flexible number of parameters — it receives a standardized request from Salesforce with a specific structure.

D is incorrect because Salesforce does not send encrypted passwords to the web service — instead, it sends the plaintext password, and it’s the responsibility of the external service to securely verify it. There is no decryption involved.

Explanation:

Login Forensics is a feature in Salesforce designed specifically to help security teams detect suspicious login behavior. It provides advanced insights such as:

📊 Average number of logins per user
🚨 Users who logged in more than the average
🌙 Logins during non-business hours
🌍 Geographic anomalies (e.g., logins from unexpected countries)

This makes it the ideal tool for identifying potential fraudulent activity or compromised accounts in a large organization like one with 15,000 employees.

❌ Why the other options fall short:
B. Login Report:
Offers basic login data but lacks advanced analytics like averages or time-based anomalies.
C. Login Inspector:
Used for debugging login issues during development—not for security analysis.
D. Login History:
Provides raw login data (IP, time, status), but requires manual analysis and doesn’t highlight patterns or anomalies.

🔗 Reference:
Salesforce Login Forensics Overview

Explanation:

Using Person Accounts for a B2C Experience Cloud site is a specific configuration. Person Accounts combine the Account and Contact into a single record, which is ideal for representing individual consumers.

Here is a breakdown of the three correct, necessary steps:

D. Contact Salesforce Support to enable person accounts. (Correct):
This is the foundational first step. The Person Account feature is not enabled by default and must be activated by Salesforce Support. It is a permanent, irreversible org setting. You cannot proceed without this step.

A. Enable access to person and business account record types under Public Access Settings. (Correct):
Once Person Accounts are enabled, your Experience Cloud site has a "Public Access Settings" profile (also known as the "Guest User Profile" or "Site Profile"). For self-registration to create Person Account records, this profile must have Read and Create access to the necessary Account and Contact record types. This includes the specific Person Account record type and, often, the associated Business Account record type for the system to function correctly.

C. Under Login and Registration settings, ensure that the default account field is empty. (Correct):
This is a critical and non-intuitive step. In the Experience Cloud site's "Login & Registration" settings, there is a field called "Default Account." This field is used to associate new Community users with a specific Account when they self-register. However, Person Accounts should not use this. When this field is left empty, the self-registration process will correctly create a new, individual Person Account record for each new user. If a Default Account is specified, all new users would be associated with that single, shared Account, which is not the desired B2C model.

Why the other options are incorrect:

B. Contact Salesforce Support to enable business accounts. (Incorrect):
Business Accounts are a standard feature in Salesforce and are enabled by default. There is no need to contact support to enable them. The requirement is specifically for Person Accounts.
E. Set organization-wide default sharing for Contact to Public Read Only. (Incorrect):
While the Guest User profile needs specific object permissions, this is managed through the "Public Access Settings" (the profile for the Guest User), not the Organization-Wide Defaults (OWD). OWD control visibility between internal users, not what an external, unauthenticated user (the Guest User) can see. Furthermore, the Guest User profile needs Create permission on Contact (and Account) to allow self-registration, not just "Read Only."

Reference:
Salesforce Help: "Enable Self-Registration for Experience Cloud":
This document covers the general setup, including the critical note about the "Default Account" field.
Salesforce Help: "Set Up Person Accounts":
This details the process of enabling Person Accounts, which requires a support case.
Salesforce Help: "Allow Access to Records in Experience Cloud":
Explains that you use the "Public Access Settings" (the guest user profile) to grant permissions for self-registration.

In summary, to enable self-registration with Person Accounts, you must: 1) Enable the feature via Support, 2) Configure the Guest Profile's record type access, and 3) Leave the Default Account field blank in the site's registration settings.

Explanation:

Requirement:
The insurance company uses a Connected App in Salesforce to integrate with Google Workspace. The IAM architect needs to automate user management (enable, freeze/suspend, disable, reactivate) in Google Workspace based on corresponding actions in Salesforce (e.g., user creation or updates).
Context:
Salesforce supports automated user provisioning for external systems via User Provisioning for Connected Apps, which syncs user lifecycle events (create, update, deactivate) with external systems like Google Workspace. The Connected App facilitates authentication (e.g., via OAuth) and API communication.

Option Analysis

A. Configure User Provisioning for Connected Apps.
Salesforce’s User Provisioning for Connected Apps feature automates user management in external systems by syncing Salesforce user data with the external system’s user directory (e.g., Google Workspace). For Google Workspace, a Connected App is configured with OAuth to authenticate API calls, and a User Provisioning Flow (or SCIM-based provisioning) is set up to map Salesforce user attributes to Google Workspace user attributes. This enables automated actions like creating, suspending, disabling, or reactivating users in Google Workspace when similar actions occur in Salesforce (e.g., user creation, deactivation).
Why It Fits:
This is a native, declarative Salesforce feature designed for user provisioning with external systems like Google Workspace, requiring minimal custom code. It supports automation for all required actions (enable, freeze/suspend, disable, reactivate) and integrates securely via the Connected App’s OAuth configuration.
Verdict: Correct.

B. Update the Security Assertion Markup Language Just-in-Time (SAML JIT) handler in Salesforce for user provisioning and de-provisioning.
SAML JIT Provisioning creates or updates users in Salesforce during SSO login based on SAML assertions from an external IdP. It is not designed for provisioning users from Salesforce to an external system like Google Workspace. Additionally, the question focuses on a Connected App (typically OAuth-based) rather than SAML SSO, making JIT provisioning irrelevant.
Verdict: Incorrect (wrong protocol and direction).

C. Build a custom REST endpoint in Salesforce that Google Workspace can poll against.
Creating a custom REST endpoint in Salesforce for Google Workspace to poll would require Google Workspace to initiate requests to check for user changes. This approach is inefficient, non-standard, and complex, as it involves custom development, polling logic, and maintenance. Salesforce’s User Provisioning for Connected Apps is a better, native solution for pushing user changes to Google Workspace.
Verdict: Incorrect (unnecessarily complex).

D. Build an Apex trigger on the UserLogin object to make asynchronous callouts to Google APIs.
The UserLogin object tracks login history and status (e.g., frozen/unfrozen), but it’s not the best place for user provisioning logic, as user management actions (e.g., create, update, deactivate) occur on the User object. Building an Apex trigger to make asynchronous callouts to Google Workspace APIs is possible but requires significant custom development, error handling, and maintenance. It’s less efficient than the native User Provisioning feature, which handles these tasks declaratively.
Verdict: Incorrect (overly complex compared to A).

Why A is Correct
User Provisioning for Connected Apps: This feature allows Salesforce to automate user lifecycle management in external systems like Google Workspace. It supports:
Enabling Users: Creating new users in Google Workspace when added in Salesforce.
Freezing/Suspending Users: Suspending Google Workspace accounts when users are frozen in Salesforce.
Disabling Users: Deactivating Google Workspace accounts when users are deactivated in Salesforce.
Reactivating Users: Re-enabling Google Workspace accounts when users are reactivated in Salesforce.

Implementation:
Configure a Connected App in Salesforce for Google Workspace with OAuth settings (client ID, secret, scopes).
Set up User Provisioning in Salesforce (Setup > User Provisioning) for the Connected App.
Map Salesforce user attributes (e.g., email, status) to Google Workspace user attributes using a provisioning flow or SCIM (System for Cross-domain Identity Management).
Enable automated provisioning to sync user changes to Google Workspace APIs.

Advantages:
Native, declarative, secure (via OAuth), and supports all required user management actions without custom code.

References
Salesforce Help: User Provisioning for Connected Apps
Salesforce Help: Connected Apps
Google Workspace Admin: User Provisioning

Explanation:

Why:
For social login with OpenID Connect in Experience Cloud, you set up an Authentication Provider (one per IdP: Facebook, Google, etc.). To create/update users at login, you attach an Apex Registration Handler to that Auth Provider. The handler performs just-in-time provisioning for social sign-on in Salesforce terms, but the configuration element is explicitly called Registration Handler, not a “JIT handler.”

Why not the others
B & D. “Single sign-on setting …” — Those SSO settings are for SAML/OIDC at the org level (Salesforce as SP/IdP). For social logins you must use Auth Providers.
C. “… and a JIT handler …” — Conceptually close (the handler does JIT), but Salesforce config uses the Registration Handler construct; that’s the correct, named component paired with an Auth Provider.