Explanation:

This question is about Salesforce Identity provisioning with approval control before creating external accounts (Concur). The requirement is clear:

Salesforce is the Identity Provider
Concur is the Service Provider
User accounts in Concur must be created only after approval in Salesforce

So the solution must use Salesforce User Provisioning + approval workflow integration via Connected Apps.

🟢 Correct Options:

B. Create an approval process for UserProvisioningRequest object associated with the provisioning flow.
This is correct because Salesforce uses the UserProvisioningRequest object to manage provisioning events. By attaching an approval process to this object, the organization can enforce governance so that external account creation (like Concur) only proceeds after explicit approval in Salesforce.

C. Create a connected app for Concur in Salesforce.
This is required because Concur must be integrated as an external system via a Connected App. It establishes trust, defines OAuth settings, and enables provisioning and identity integration between Salesforce and Concur.

D. Enable User Provisioning for the connected app.
This is essential because enabling User Provisioning allows Salesforce to automatically create, update, or deactivate user accounts in external applications like Concur based on Salesforce identity data and approval workflows.

🔴 Incorrect options:

A. Create an approval process for a custom object associated with the provisioning flow.
This is incorrect because Salesforce provisioning workflows are not driven by custom objects in this context. The correct object is UserProvisioningRequest, which is purpose-built for provisioning lifecycle management.

E. Create an approval process for User object associated with the provisioning flow.
This is incorrect because the User object represents Salesforce internal users, not provisioning requests for external systems. Approvals must be applied to provisioning requests, not directly to user records.

🔧 Reference:
→ Salesforce Identity – User Provisioning for Connected Apps and Approval Processes
This documentation explains how User Provisioning uses Connected Apps and UserProvisioningRequest approval processes to control when external accounts are created or updated in third-party systems like Concur.

Explanation:

This is a classic machine-to-machine / system integration scenario.

Requirement
A custom order fulfillment app (external system) needs to securely access Salesforce data via APIs. It must use the OAuth 2.0 protocol.

The correct and recommended approach is to create a Connected App in Salesforce and define the appropriate OAuth Scopes.

Why Option D is Correct

Connected App acts as the trusted application that represents the order fulfillment app in Salesforce.

OAuth Scopes define exactly what data and operations the app is allowed to perform (e.g., api, refresh_token, offline_access, full, custom scopes, etc.).

Since this is a backend system integration (not a user-facing web app), the architect will most likely use one of these OAuth flows:

JWT Bearer Token Flow (most secure and recommended for server-to-server)
Client Credentials Flow (if no specific user context is needed)

Both flows require a Connected App with proper OAuth settings and scopes.

Why the other options are incorrect

A. OAuth Token
This is not a configuration object. An OAuth token is the result of the authorization process, not something you “use” to set up the integration.

B. Genre Age Integration
This looks like a typo or nonsense option (possibly meant to say “Generic Integration” or “Named Credential”). Either way, it is not a valid Salesforce feature for this use case.

C. Authentication Providers
Authentication Providers are used when you want to allow users to log in to Salesforce using external identity providers (e.g., Google, Facebook, Azure AD). They are not used when an external app wants to call Salesforce APIs.

Exam Takeaway

When an external application/system needs to integrate with Salesforce APIs using OAuth 2.0, the standard and correct pattern is:

Connected App + OAuth Scopes + Appropriate OAuth Flow (usually JWT Bearer or Client Credentials for backend integrations)

This question tests whether you understand the fundamental building block for secure API access in Salesforce.

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 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 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.