Explanation:

In a Single Sign-On (SSO) scenario using OAuth or SAML, the roles of Identity Provider (IdP) and Service Provider (SP) are defined as follows:
Identity Provider (IdP): Authenticates the user and issues identity tokens (e.g., Google, Facebook).
Service Provider (SP): Consumes the identity token and grants access to its services (e.g., Salesforce Experience Cloud).
In this case:
Salesforce hosts the Customer Community, so it acts as the Service Provider.
Google and Facebook are external login options, meaning they authenticate users and pass identity tokens to Salesforce — they are the Identity Providers.

❌ Why the other options are incorrect:
A. Google is the service provider and Facebook is the identity provider: Incorrect — Google is not hosting the community.
C. Facebook is the service provider and Salesforce is the identity provider: Incorrect — Salesforce is the destination, not the source of authentication.

🔗 Reference:
Salesforce External Identity Providers
Login with Google or Facebook in Salesforce

Explanation:

Requirement: The Salesforce customer is implementing Sales Cloud and a custom pricing application exposed via a Canvas app for call center agents. An enterprise SSO solution authenticates users, and agents should access the Canvas app without logging into the pricing application separately.
Canvas App Context: Salesforce Canvas allows external applications to be embedded within Salesforce (e.g., in a Visualforce page or Lightning component). For seamless integration with SSO, the Canvas app must authenticate users without requiring separate logins, leveraging the enterprise SSO solution and Salesforce as the Identity Provider (IdP) or Service Provider (SP).

Option Analysis

A. Select "Enable as a Canvas Personal App" in the connected app settings.
The "Enable as a Canvas Personal App" setting allows individual users to install and use a Canvas app in their personal Salesforce environment (e.g., for personal customization). It’s not suitable for enterprise-wide deployments like this scenario, where the Canvas app is for call center agents and managed centrally. This setting doesn’t address SSO integration or seamless login.
Verdict: Incorrect.

B. Enable OAuth settings in the connected app with required OAuth scopes for the pricing application.
Canvas apps are configured as Connected Apps in Salesforce, and enabling OAuth settings allows the Canvas app to authenticate users via Salesforce’s OAuth 2.0 flows (e.g., Web Server or JWT Bearer Flow). By specifying required OAuth scopes (e.g., api, web, or custom scopes for the pricing app), the Canvas app can access Salesforce data or external app resources on behalf of the user. When combined with the enterprise SSO solution (e.g., Salesforce as IdP or federated SSO), OAuth ensures agents are authenticated seamlessly without needing to log into the pricing app separately.
Why It Fits: OAuth is a standard for Canvas app authentication, and scopes define the access level, ensuring secure, SSO-enabled access to the pricing app embedded in Salesforce.
Verdict: Correct.

C. Configure the Canvas app as a connected app and set Admin-approved users as pre-authorized.
Configuring the Canvas app as a Connected App allows it to integrate with Salesforce and leverage SSO. Setting “Admin-approved users are pre-authorized” in the Connected App settings ensures that only designated users (e.g., call center agents) can access the Canvas app without additional authentication prompts. This works with the enterprise SSO solution, as Salesforce (or the external IdP) handles authentication, and the pre-authorization ensures seamless access to the pricing app via the Canvas app without requiring separate logins.
Why It Fits: Pre-authorization simplifies access for approved users, aligning with the requirement for no additional login to the pricing app.
Verdict: Correct.

D. Enable SAML in the connected app and Security Assertion Markup Language (SAML) Initiation Method as Service Provider Initiated.
While SAML is a valid SSO protocol, Canvas apps primarily use OAuth for authentication and authorization, not SAML. The “SAML Initiation Method” setting is relevant for Connected Apps using SAML SSO, but Canvas apps rely on signed requests or OAuth for integration with Salesforce. Enabling SAML for the Connected App doesn’t align with Canvas app best practices and may not support seamless embedding of the pricing app within Salesforce. The enterprise SSO solution can still be used with OAuth-based Canvas authentication.
Verdict: Incorrect.

Why B and C are Correct
B: Enabling OAuth in the Connected App settings allows the Canvas app to authenticate users via Salesforce’s OAuth flows, leveraging the enterprise SSO solution (e.g., Salesforce as IdP or federated with an external IdP). Required OAuth scopes ensure the pricing app has appropriate access to Salesforce data or resources, enabling seamless integration without separate logins.
C: Setting admin-approved users as pre-authorized ensures that call center agents, authenticated via the enterprise SSO solution, can access the Canvas app without additional prompts. This streamlines the user experience and aligns with the requirement for no separate login to the pricing app.

References
Salesforce Help: Canvas App Authentication
Salesforce Help: Connected App OAuth Settings
Trailhead: Canvas Apps

Explanation:

External partners (delivery providers)
The users described—delivery providers who review and update accounts, download files, and check calendars—are considered partners, not customers. This immediately narrows the choice to a partner-based license.
High volume of logins
The key detail in this question is the high login volume: 13.5 million unique logins per month for 2.5 million users.
Member-based licenses (like the standard Partner Community License) charge a fixed price per named user. With 2.5 million users, this would be prohibitively expensive.
Login-based licenses (like the Partner Community Login License) are priced based on the number of logins. A login is typically a "daily unique login," meaning multiple logins on the same day by the same user only consume one license. This is designed for high-volume, occasional-access scenarios, making it the most cost-effective solution here.
Required access capabilities
The tasks required by the partners—updating accounts, downloading files, and accessing calendars—are all supported by the Partner Community license type. The login-based version offers the same access capabilities but with a different, more suitable pricing model for this volume.

Why other options are incorrect
A. External Apps License:
The External Apps license is used for custom, branded digital experiences but doesn't inherently imply a business-to-business partner relationship. While it could theoretically be used, it may not be the best fit for partner-specific functionality and pricing is also available on a per-login basis, but the Partner license is the most direct solution for B2B portal functionality.
B. Partner Community License:
This is a member-based license, which charges per named user, regardless of how often they log in. At 2.5 million users, this would be significantly more expensive than paying per login for a much higher number of logins.
D. Customer Community plus Login License:
The users are explicitly identified as "external partners (delivery providers)." A Customer license is for business-to-consumer (B2C) scenarios and has a different set of permissions and capabilities, such as not allowing access to certain sales objects crucial for partner collaboration.

Explanation:

The JWT Bearer Flow is designed specifically for server-to-server integrations where:
🔐 No end-user interaction is required.
🔒 Security is maximized by using signed JWT tokens.
🔄 The third-party system can authenticate itself to Salesforce using a pre-established trust (via a certificate or shared secret).
This makes it ideal for integrations where a backend service (like a third-party system) needs to authenticate and call Salesforce REST APIs without prompting a user to log in.

❌ Why the other options don’t fit:
B. Web Server Flow: Requires end-user interaction and is used when a user logs in via a browser. Not suitable for headless server-to-server scenarios.
C. User Agent Flow: Also requires user interaction and is typically used in client-side apps like mobile or single-page apps.
D. Username-Password Flow: Although it avoids user interaction, it requires storing user credentials, which is a security risk and not recommended for third-party integrations.

🔗 Reference:
Salesforce JWT Bearer Flow Documentation
Salesforce OAuth Flows Overview

Explanation:

The key detail in the requirement is that users start from "a custom web page that UC manages." This custom web page is essentially acting as a portal or dashboard.

Let's break down the flow:

The Starting Point:
The user is already on a web page controlled by UC. This page is logically an extension of the Identity Provider's (IdP) domain or is tightly integrated with it. It is not one of the individual applications (Service Providers).
The User Action:
From this central page, the user clicks a link to access Salesforce or another SSO-enabled application.

The Recommended Flow: IdP-Initiated SSO

In this flow, the user is already authenticated with the IdP (or will be prompted to log in by the portal page itself).
When the user clicks a link to an application (e.g., Salesforce), the portal/IdP generates a SAML assertion and initiates a POST request to the Service Provider's (e.g., Salesforce's) SAML endpoint.
The user is seamlessly logged into the target application without having to navigate to that application's login page first.
This flow is perfectly suited for a company portal where users launch their applications.

Why the other options are incorrect:

A. SP-Initiated with Deep Linking & B. SP-Initiated:
These are the same in practice, as "Deep Linking" is just a feature of SP-Initiated flow that preserves the intended resource. In an SP-Initiated flow, the user starts at the Service Provider (e.g., they go directly to login.salesforce.com or an app-specific URL). The SP then redirects the user to the IdP to authenticate. This contradicts the requirement because UC wants users to start from their own custom page, not from the application's login URL.
D. User-Agent:
This is not a standard name for a SAML flow. The User-Agent (the web browser) is simply the component that facilitates the redirects and POST requests in both IdP-Initiated and SP-Initiated flows. It is not a flow itself.

Reference:
Salesforce Help: "SAML Login Flows": This document clearly distinguishes between the two flows.
Key Quote for IdP-Initiated: "The user accesses the identity provider (for example, by going to a company portal page)... The identity provider... sends a SAML response to the service provider."
Key Quote for SP-Initiated: "The user accesses the service provider... The service provider... redirects the user to the identity provider for authentication."
URL: https://help.salesforce.com/s/articleView?id=sf.identity_provider_about_saml_login_flows.htm&type=5

In summary,
when the user's journey begins at a central portal or dashboard managed by the company (the Identity Provider), the IdP-Initiated SSO flow is the architecturally correct choice.