Explanation:

This question tests your knowledge of Salesforce audit tools for user authentication. The requirement is to audit login attempts, track authentication methods, and spot suspicious behavior. Salesforce provides native monitoring for this via Login History.

✔️ Correct Option:

B. Salesforce Login History
Login History captures every login attempt for all users, including successful and failed logins, login time, source IP, login type, browser, platform, application, and authentication method like SAML SSO, username/password, or OAuth. Admins can view and export it from Setup, or query the LoginHistory object. It’s the primary tool to audit and verify user activity during and after login, and to identify anomalies or unauthorized access.

❌ Incorrect options:

A. Customer Account Processes
This is not a Salesforce security or auditing feature. There’s no standard “Customer Account Processes” tool for monitoring logins. This option is a distractor.

C. Salesforce Shield
Salesforce Shield includes Event Monitoring, Platform Encryption, and Field Audit Trail. Event Monitoring can provide deeper login forensics, but the specific “Salesforce Shield” product name isn’t the direct answer for basic login auditing. Login History is available in all editions without Shield and is the exact tool named for this purpose. If the question listed “Event Monitoring,” it could be debated, but “Salesforce Login History” is the most direct and universally available answer.

D. Salesforce Lightning Flow
Flows automate business processes. They don’t natively audit or report on login activity. While you could build custom logic with flows triggered on login, Salesforce already provides Login History for this exact use case, so Flow is not the right tool.

🔧 Reference:
→ Salesforce Help – Monitor Login History – Describes how Login History tracks user logins, authentication methods, IP addresses, and success/failure to help identify unauthorized access.

Explanation:

This question tests knowledge of the key architectural differences between SAML and OIDC when Salesforce acts as an Identity Provider. Both protocols support SSO, but they serve different purposes beyond authentication. The determining factor in choosing one over the other lies in whether the SP needs to make authorized API calls back to Salesforce after login.

✅ B. The SP needs to perform API calls back to Salesforce on behalf of the user after the user logs in to the service provider.
OIDC is built on OAuth 2.0, which means it not only authenticates the user but also issues an access token that the SP can use to make authorized API calls back to Salesforce on behalf of the logged-in user. SAML only handles authentication and does not provide an access token for subsequent API interactions, making OIDC the clear choice when post-login API access is required.

❌ A. OIDC is more secure than SAML and therefore is the obvious choice.
This is factually incorrect. Both SAML and OIDC are industry-standard, secure protocols when properly implemented. Security alone is not a valid differentiator between the two. The choice should be based on functional requirements such as API access needs, not a blanket security comparison between the protocols.

❌ C. They are equivalent protocols and there is no real reason to choose one over the other.
SAML and OIDC are not equivalent — they have fundamentally different capabilities. SAML is purely an authentication and SSO protocol using XML assertions, while OIDC extends OAuth 2.0 to include identity and access token issuance. Treating them as interchangeable ignores critical architectural distinctions that impact integration design.

❌ D. If the user has a session on Salesforce, you do not want them to be prompted for a username and password when they login to the SP.
This describes Single Sign-On (SSO) behavior, which is supported by both SAML and OIDC equally. It is not a differentiating factor for choosing one protocol over the other. SSO session reuse cannot serve as the deciding criterion when both protocols deliver the same outcome in this scenario.

🔧 Reference:
→ Configure Salesforce as an Identity Provider – Salesforce Help
Confirms that OIDC provides OAuth-based access tokens enabling SP-initiated API calls back to Salesforce, distinguishing it from SAML which is limited to authentication assertions only.

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.

Explanation:

This question tests the core value of Customer 360 Identity in a Customer 360 strategy. The main benefits are centralized identity across brands and channels, plus linking anonymous and known activity into one identity view. That helps organizations build a single trusted customer profile and understand the full journey.

Option A
❌ Customer 360 Identity automatically integrates with Customer 360 Data Manager and Customer 360 Audiences to seamlessly populate all user data.
This is too absolute. Customer 360 Identity can work with other Salesforce products, but it does not automatically populate all user data into every related product without configuration and data integration design.

Option B
✔️ Customer 360 Identity supports multiple brands so you can deliver centralized identity services and correlation of user activity, even if it spans multiple corporate brands and user experiences.
This is a key benefit because it lets one identity layer serve multiple brands while still keeping a consistent view of the customer. It helps unify identity and activity across different digital experiences without creating separate identity silos for each brand.

Option C
❌ Customer 360 Identity enables an organization to build a simple login for each of its customers, giving the organization an understanding of the user’s login activity across all its digital properties and applications.
This is partly true but too narrow. Customer 360 Identity is not just about login simplicity; its value is broader, covering identity correlation and customer journey unification across sign-up, sign-in, and ongoing activity.

Option D
✔️ Customer 360 Identity not only provides a unified sign up and sign in experience, but also tracks anonymous user activity prior to signing up so organizations can understand user activity before and after the users identify themselves.
This is a major Customer 360 Identity advantage because it connects anonymous behavior to known identity after sign-up. That gives organizations a fuller view of the customer journey and improves the quality of identity resolution across channels.

🔧 Reference:
→ Customer 360 Identity
— Confirms Salesforce Customer 360 Identity is focused on unified customer identity and journey tracking across experiences.

Explanation:

This scenario asks for a combination of SSO (for access) and Automated Lifecycle Management (for status changes) using modern cloud standards.

Requirement 1 (Provisioning/Deprovisioning): The key phrase here is "Change of a user status... triggers provisioning or deprovisioning."
Requirement 2 (SSO): Setting up Salesforce as a SAML Service Provider (SP) is the standard way to allow users to authenticate via a Central IAM Service (the Identity Provider).

SCIM is an HTTP-based protocol specifically designed to manage user identities across cloud applications. When a user is deactivated or their role changes in the Central IAM, the IAM service sends a REST-based SCIM command to Salesforce to instantly update or deactivate that user.

Why other options are incorrect:

Option A (JIT Provisioning):
Just-in-Time (JIT) provisioning only works when a user logs in. It can create or update a user, but it cannot deprovision a user who isn't logging in. If an employee is fired and disabled in the central IAM, JIT would never trigger to disable them in Salesforce.

Option B (Registration Handler):
Registration Handlers are used with OpenID Connect (OAuth), not SAML. Even then, like JIT, they only trigger during the authentication event and cannot handle background deprovisioning.

Option D (Identity Connect):
Identity Connect is a specific tool used primarily to sync on-premises Microsoft Active Directory with Salesforce. Since the requirement specifies a "cloud-based IAM Service," a standard protocol like SCIM is the preferred architectural choice over a specific AD-connector tool.

🔧 Reference:
→ Salesforce Help: Provision Users with SCIM
This documentation confirms that Salesforce supports the SCIM 2.0 standard to allow external identity systems to manage the full lifecycle of Salesforce user records.