Explanation:

Gathering signals of a potential account compromise should start with the data most likely to show unusual access patterns. The Login History provides a granular log of every login attempt, which is the most direct source of forensic evidence for unauthorized access.

Here's why reviewing the Login History is the essential first step:

Direct Authentication Data:
Login History records critical details about every login attempt for a user, including the date, time, IP address, geographical location, and success or failure status. This immediately reveals any unusual login activity, such as a successful login from a foreign country or a strange IP address, which are classic signs of a compromised account.
Targeted Information:
The investigation is focused on a specific user account, so starting with their login history is the most efficient and targeted approach. It answers the most critical question: has anyone successfully logged into this account from an unexpected location or at an unusual time?
No Configuration Needed:
Login History is a standard, built-in Salesforce feature available to all administrators, and it does not require any prior configuration or special permissions.

Why other options are incorrect

A. Review the User record and evaluate the login and transaction history.
While the user record shows "Last Login," this only indicates the most recent activity and doesn't provide a comprehensive view of all login attempts. A comprehensive "transaction history" is not a standard feature; this would require more advanced tools like Event Monitoring. This option is not as thorough as downloading the Login History.
B. Download the Setup Audit Trail and review all recent activities performed by the user.
The Setup Audit Trail tracks changes to the organization's setup, such as profile modifications, changes to permission sets, or security settings. While it would show if a malicious actor modified the account, it would not provide the initial signals of the breach, such as the unauthorized login event itself. A compromised account might be used simply to export data without touching Setup at all.
C. Download the Identity Provider Event Log and evaluate the details of activities performed by the user.
The Identity Provider Event Log is relevant only if Salesforce is configured as the Identity Provider (IdP) for other applications. In this scenario, the compromise is suspected on the Salesforce account itself. The standard Login History is the correct place to look for authentication details regarding direct access to the Salesforce org.

Explanation:

Requirement:
Universal Containers (UC) is setting up an authentication provider for a Salesforce Experience Cloud site for its container wholesale business. We need to identify two options that can be utilized when creating an authentication provider in Salesforce.
Context:
An Authentication Provider in Salesforce enables external authentication (e.g., via Google, Facebook, or another IdP) for Experience Cloud users, typically using OAuth, OpenID Connect, or SAML. When configuring an Authentication Provider, certain settings can be customized to manage user authentication and integration.

Option Analysis

A. A custom registration handler can be set.
A Registration Handler is an Apex class (implementing the Auth.RegistrationHandler interface) that processes user data from the external IdP during login. It can create or update Salesforce user records based on data (e.g., email, name) received from the authentication provider (e.g., via OAuth or OpenID Connect). This is a key feature for Experience Cloud sites to map external identities to Salesforce Community users, making it a valid option for configuration.
Why It Fits:
Allows UC to customize how user profiles are created or updated in the Experience Cloud site based on the IdP’s data.
Verdict: Correct.

B. A custom error URL can be set.
When configuring an Authentication Provider in Salesforce, you can specify a Custom Error URL to redirect users if an authentication error occurs (e.g., invalid credentials or IdP failure). This is useful for providing a branded or user-friendly error page in the Experience Cloud site, improving the user experience during login issues.
Why It Fits:
Enhances the authentication process by allowing UC to handle errors gracefully in the Experience Cloud context.
Verdict: Correct.

C. The default login user can be set.
There is no concept of a "default login user" in the configuration of an Authentication Provider in Salesforce. Authentication Providers handle external authentication and map to Salesforce users dynamically (e.g., via Registration Handlers or JIT provisioning for SAML). Setting a default user is not a supported feature for Authentication Providers.
Verdict: Incorrect.

D. The default authentication provider certificate can be set.
Authentication Providers using OAuth or OpenID Connect typically rely on client IDs, client secrets, or JSON Web Key Sets (JWKS) for authentication, not Salesforce certificates. Certificates are more relevant for SAML-based SSO (e.g., when Salesforce is the IdP or SP). While SAML configurations might involve certificates, the question focuses on an Authentication Provider (typically OAuth/OpenID Connect for Experience Cloud), and no "default authentication provider certificate" setting exists in this context.
Verdict: Incorrect.

Why A and B are Correct
A. Custom Registration Handler:
Allows UC to define custom logic for creating or updating Experience Cloud user records based on data from the external IdP, ensuring seamless integration and profile synchronization.
B. Custom Error URL:
Enables UC to redirect users to a custom page in the Experience Cloud site if authentication fails, improving user experience and branding.

References
Salesforce Help: Set Up an Authentication Provider
Salesforce Help: Registration Handler
Trailhead: External Identity Basics

Explanation:

The scenario describes a need for IdP-initiated Single Sign-On (SSO) or deep linking from an email. When a user clicks a link to a record in "Instance A," they must be automatically and seamlessly authenticated by their central Identity Provider (IdP) and logged into "Instance A" without seeing a login page.

My Domain is the absolute prerequisite for this to work. Here's why:

Unique Org Identification:
Without My Domain, all Salesforce orgs use generic URLs (e.g., login.salesforce.com). When the IdP needs to send a user to a specific Salesforce org, it has no unique URL to target. My Domain provides a unique, custom subdomain for each org (e.g., universalcontainers--dev.my.salesforce.com), which acts as that org's unique identifier in the federation ecosystem.
Prerequisite for SAML:
Enabling My Domain is a mandatory step before you can configure and use most SAML SSO features, including the IdP-initiated flow required for this email link scenario. The IdP must be configured to send the SAML assertion to the user's specific org URL, which is only possible after My Domain is deployed.

How it Works:

The link in the email points to the record in a specific My Domain (e.g., https://uc-production.my.salesforce.com/a00...). The user clicks the link. Because they don't have an active session for that domain, they are redirected to their IdP. The IdP authenticates the user and, because it is configured to trust that specific My Domain URL, generates a SAML assertion for that org. The user is seamlessly redirected back to the original My Domain URL and is logged in, viewing the record.

Why the other options are incorrect:

B. External Identity:
This is a licensing feature for Experience Cloud (Communities) that allows you to manage external users. It is not relevant for internal users accessing different internal Salesforce instances via SSO.
C. Identity Provider:
While configuring Salesforce as an Identity Provider is a possible part of the overall solution (if the central IdP is one of the Salesforce orgs), it is not the fundamental prerequisite. The core, underlying requirement that enables any org to participate in this federated login—whether as an IdP or a Service Provider—is My Domain.
D. Multi-Factor Authentication (MFA):
MFA is a security feature for strengthening authentication. It is not a prerequisite for the SSO or deep-linking functionality described in the question.

Reference:
Salesforce Help: "Enable My Domain":
Key Quote: "My Domain is required for... Single sign-on (SSO) authentication from the Salesforce mobile app, Identity Provider (IdP)-initiated single sign-on (SSO)."
URL: https://help.salesforce.com/s/articleView?id=sf.domain_name_define.htm&type=5
Salesforce Help: "Plan Single Sign-On":
This documentation reiterates that My Domain is a prerequisite for SAML.
URL: https://help.salesforce.com/s/articleView?id=sf.identity_plan_authentication_options.htm&type=5

In summary:
My Domain is the non-negotiable foundation that provides a unique address for each Salesforce org, enabling the Identity Provider to correctly route users and initiate login sessions to the specific instance referenced in an email link.

Explanation:

Rationale for High-Assurance Session
This solution leverages Salesforce's built-in Session Security Levels to manage access to sensitive actions like exporting reports, which is the most secure and scalable approach for this requirement.
SAML Federated Authentication: Users logging in with their Active Directory (AD) credentials will use SAML (or another SSO protocol) to authenticate against the external Identity Provider (AD).
Treat SAML Sessions as High Assurance: In Salesforce's Single Sign-On Settings, the Identity Architect can configure the SAML login handler to result in a High Assurance session. This marks all users who successfully logged in via AD as having met the highest security standard.
Raise Session Level for Exporting Reports: In Salesforce's Session Settings, the administrator can move the "Export Reports" permission from the standard "Standard" session security level to the "High Assurance" session security level.

Why This Works

AD Login (SSO): Users log in via AD → Session is High Assurance → User can export reports.
Salesforce Login (Standard Credentials): Users log in directly with Salesforce credentials → Session is Standard assurance → User cannot export reports (they can view them, as viewing is typically a Standard level action).
This meets all parts of the requirement: users must use AD to export, but they can still view reports when logged in with Salesforce credentials.

Why Other Options Are Incorrect

A and D. Use a Permission Set or Login Flow: While login flows and permission sets can dynamically manage permissions, they are not the best practice for session security requirements. A login flow runs once at login, but a user's session assurance level is checked continuously before executing high-risk actions. If you use a permission set, the user would lose the ability to export reports immediately upon logging out and back in via the non-AD path, but relying on session security levels is the correct feature for continuous, policy-based risk mitigation.
C. Block access to reports when accessed through a standard assurance session: This is too broad. The requirement is only to block exporting reports, not viewing them. Raising the session level for the specific "Export Reports" permission is the granular control needed.

Explanation:

Why this is correct
With social sign-on (e.g., Facebook as an Auth Provider) for Experience Cloud, Salesforce invokes your Apex Registration Handler on login. The handler has two methods: createUser() (first-time provisioning) and updateUser() (subsequent logins). Implementing updateUser() lets you refresh the Salesforce User record with the latest attributes from Facebook each time the user logs in, ensuring profile changes are reflected automatically.

Why the others are not correct

A. SAML JIT — Facebook social login uses OAuth/OpenID Connect, not SAML.
B. Signed Request — That’s a Facebook Canvas concept and not the supported mechanism for Experience Cloud social SSO updates.
C. Nightly job — Possible but unnecessary and heavier; you’d need tokens/consent management. The built-in login-time updateUser() pattern is the standard, simpler approach.

Exam tip:
For social SSO into Experience Cloud, think Auth Provider + Registration Handler; use createUser() for first login provisioning and updateUser() to keep user data in sync on later logins.