Explanation:
The requirement is to automate user lifecycle management (create, freeze, disable, reactivate) between Salesforce and Google Workspace. Salesforce provides native "User Provisioning for Connected Apps" using the SCIM (System for Cross-domain Identity Management) standard, which automates provisioning and de-provisioning to external apps like Google Workspace.

Correct Option:

C. Configure User Provisioning for Connected Apps.
Salesforce User Provisioning for Connected Apps uses the SCIM 2.0 protocol to synchronize user attributes and lifecycle states (active, frozen, inactive) between Salesforce and external identity stores or applications. Google Workspace supports SCIM. By configuring a connected app with a provisioning profile, Salesforce automatically pushes user creation, updates, suspension, and reactivation to Google Workspace without custom code.

Incorrect Options:

A. Build a custom REST endpoint in Salesforce that Google Workspace can pull against.
Google Workspace expects to receive provisioning events via SCIM (pushed from Salesforce or pulled on a schedule). Building a custom REST endpoint for Google to pull from is non-standard, requires custom code, and does not leverage native provisioning features. This approach is more complex and less reliable.

B. Build an Apex Trigger on the UserLogin object to make asynchronous callouts to Google APIs.
There is no "UserLogin" object in Salesforce. User status is stored on the User object (IsActive, IsFrozen). Writing a trigger on User with asynchronous callouts is possible but requires significant custom code for error handling, retries, and state management. This is not recommended when native SCIM provisioning exists.

D. Update the Security Assertion Markup Language Just-In-Time (SAML JIT) handler in Salesforce for user provisioning and de-provisioning.
SAML JIT (Just-In-Time) provisioning creates users only at the time of SSO login. It does not handle freeze, suspend, disable, or reactivate actions triggered by Salesforce user status changes. SAML JIT is for authentication-time provisioning, not ongoing lifecycle management.

Reference:

Salesforce Help Article: "User Provisioning for Connected Apps – SCIM Integration"

Trailhead: "Identity and Access Management for Architects" – Unit on "Automated User Provisioning"

Salesforce Architect Documentation: "Provisioning Users to Google Workspace Using SCIM"

Explanation:
When creating an authentication provider in Salesforce (for Social Sign-On, OIDC, or SAML), administrators have multiple configuration options. Among them, setting a custom error URL allows redirecting users on authentication failures, and a custom registration handler (Apex class) controls how external identities map to Salesforce users.

Correct Options:

B. A custom error URL can be set.
When configuring an authentication provider, there is an optional field for "Custom Error URL." If authentication fails (e.g., user denies consent, token exchange fails), Salesforce redirects the user to this URL instead of showing a generic error page. This allows organizations to provide branded or helpful error messages, improving user experience.

D. A custom registration handler can be set.
Every authentication provider must reference a registration handler (Apex class implementing Auth.RegistrationHandler). While a default handler exists, a custom registration handler can be specified to override user creation, linking, and update logic. This is essential for complex mapping, deduplication, or linking multiple social identities to one user.

Incorrect Options:

A. The default login user can be set.
Authentication providers do not have a "default login user" setting. If a user cannot be linked or created, the authentication fails. There is no fallback user concept. This option may confuse with SAML JIT provisioning defaults or community guest user settings, which are unrelated.

C. The default authentication provider certificate can be set.
Certificates are used with SAML authentication providers (for signing or encryption) and OIDC providers (for private key JWT client authentication). However, there is no "default authentication provider certificate" setting at the provider level. Certificates are uploaded separately in Certificate and Key Management and referenced where needed. This phrasing is inaccurate.

Reference:

Salesforce Help Article: "Set Up Authentication Providers – Configuration Options"

Salesforce Developer Guide: "Auth.AuthProviderCustomSettings – Error URL and Registration Handler"

Trailhead: "Build Authentication Providers" – Unit on "Provider Configuration"

Explanation:

The VP wants only active Salesforce users to access the Order Tracking system, and it should be visible only within Salesforce. The order tracking system supports SAML SSO. To enforce Salesforce as the source of truth for user status and embed the app inside Salesforce, you use Salesforce as IdP + Canvas.

✔️ Correct Option:

C. Setup Salesforce as an identity provider (IdP) for Order Tracking.
With Salesforce as IdP, users authenticate to Salesforce first. Salesforce issues a SAML assertion to the Order Tracking system only for active users. If a user is deactivated in Salesforce, they can’t get an assertion and can’t access Order Tracking. This satisfies the “only active Salesforce users” requirement without custom code.

D. Setup Order Tracking as a Canvas app in Salesforce to POST IdP initiated SAML assertion.
Canvas apps let you embed external apps inside Salesforce and pass identity via Signed Request or SAML. Using IdP-initiated SAML from Salesforce into a Canvas app ensures the Order Tracking system is only accessible from within Salesforce and leverages the active Salesforce session. This meets the “only visible within Salesforce” requirement.

❌ Incorrect options:

A. Set up the Corporate Identity store as an identity provider (IdP) for Order Tracking.
If a corporate IdP is used, users could SSO directly to Order Tracking outside Salesforce. That bypasses Salesforce user status and visibility. The requirement is that access be controlled by Salesforce and only visible inside Salesforce, so using an external IdP fails both conditions.

B. Customize Order Tracking to initiate a REST call to validate users in Salesforce after login.
This is a custom integration that adds complexity and latency. It also doesn’t prevent initial access to Order Tracking outside Salesforce. SAML IdP already validates user status before issuing the assertion, so REST validation is unnecessary and doesn’t enforce the “only within Salesforce” rule.

🔧 Reference:
→ Salesforce Help – SAML Single Sign-On Flows – Explains using Salesforce IdP to control access to external apps via SAML.
→ Salesforce Developer Guide – Introducing Canvas – Shows how Canvas can embed external apps and pass SAML assertions for SSO inside Salesforce.

Explanation:

This scenario is about enabling social sign-in for a B2C website that does not support SAML or OAuth natively. Salesforce Identity must provide external authentication, user registration, and seamless login integration.

You need features that support:

Social identity federation
External app trust
Embedded customer login experience

🟢 Correct Options:

A. Connected Apps
Connected Apps establish the trust framework between Salesforce and external applications. They are required to configure authentication flows, define access policies, and enable secure integration for external websites using Salesforce Identity services.

B. Authentication Providers
Authentication Providers enable social login and external identity federation (Google, Facebook, etc.). They allow users to authenticate using third-party identity systems and map external identities into Salesforce customer records. This is the core feature for social sign-in.

D. Embedded Login
Embedded Login allows Salesforce authentication and registration UI to be embedded directly into a B2C website. It is essential when the external system does not support SAML or OAuth, providing seamless login without requiring protocol implementation on the website.

🔴 Incorrect Options:

C. Delegated Authentication
Delegated Authentication forwards password validation to an external system. It is not designed for social login or identity federation and does not support modern customer authentication experiences.

E. Identity Connect
Identity Connect is used for syncing enterprise users between Active Directory and Salesforce. It is intended for internal workforce identity management, not B2C social sign-in or customer authentication.

🔧 Reference:
→ Salesforce Identity – Authentication Providers and Social Sign-On
This document explains how Salesforce uses Authentication Providers, Connected Apps, and Embedded Login to enable social sign-in and external customer authentication for B2C websites.

Explanation:

This question tests core OAuth 2.0 Web Server (Authorization Code) Flow concepts. This flow is used for server-side applications and involves exchanging an authorization code for tokens. The key elements are:

Controlled access via scopes
Secure token exchange using client credentials
Use of access tokens to call protected resources

🟢 Correct Options:

C. Scopes
Scopes define the level of access the application is requesting from the user. In the Web Server Flow, scopes are included in the authorization request and determine what resources the application can access in Salesforce. This enables fine-grained access control.

D. Access Token
The access token is issued after the authorization code is exchanged. It is used by the application to access protected Salesforce resources (APIs) on behalf of the user. It is a core component of every OAuth flow.

E. Client Secret
The client secret is used along with the client ID during the token exchange step. It authenticates the application (server-side) to Salesforce, ensuring that only trusted applications can exchange authorization codes for tokens.

🔴 Incorrect options:

A. Verification URL
This is not a standard OAuth concept in the Web Server Flow. It is not used in authorization code exchange or token handling within Salesforce OAuth flows.

B. Authentication Token
This is not an official OAuth 2.0 term. OAuth uses access tokens and refresh tokens, not “authentication tokens,” making this option incorrect.

🔧 Reference:
→ OAuth 2.0 Authorization Code (Web Server) Flow in Salesforce
This documentation explains how the Web Server Flow uses scopes, client credentials (client secret), and access tokens to securely authorize and access Salesforce resources.