Explanation:

This scenario involves multi‑channel identity management for B2C Commerce, Service Cloud, and Experience Cloud, with a focus on social login (Google, Facebook) for a seamless customer experience.

Key needs:
Single identity across commerce and service portal.
Social login support.
Centralized authentication for Experience Cloud and B2C Commerce.

Let’s evaluate each option:

A. Define a user registration handler to support user provisioning and authentication via social services like Google and Facebook.
Correct. In Experience Cloud, you can configure Authentication Providers (like Google, Facebook) using OpenID Connect or SAML. A Registration Handler (Apex class) processes the social login data and creates/updates the user record in Salesforce, enabling seamless social sign‑on for the service portal.

B. Leverage Salesforce Identity as the identity provider to centralize authentication for both Experience Cloud and B2C Commerce in one place.
Correct. Salesforce Identity (part of Salesforce Platform) can act as the central Identity Provider (IdP) using SAML or OIDC.

Experience Cloud can use Salesforce Identity for login.
B2C Commerce can be configured to use Salesforce Identity as an external IdP (via SAML), allowing customers to use the same credentials for storefront and portal.
This provides a unified login experience.

C. Leverage B2C Commerce as the identity provider for both Storefront and the Service Portal.
Incorrect. While B2C Commerce manages customer accounts for the storefront, it is not designed to be an IdP for external systems like Experience Cloud. Experience Cloud should be the IdP (or use Salesforce Identity) due to its stronger identity management, social login support, and integration with Service Cloud data.

D. Use Salesforce CDP, which automatically syncs profiles and authentication information across systems.
Incorrect. CDP unifies customer data for segmentation and insights, but does NOT handle authentication or sync login credentials. CDP cannot act as an identity provider or manage social login flows.

Key Concepts
Social Login in Experience Cloud: Configure Authentication Providers (Google, Facebook) with a Registration Handler Apex class.
Salesforce Identity as IdP: Provides single sign‑on (SSO) across Experience Cloud and B2C Commerce via SAML/OIDC.
B2C Commerce External Authentication: Supports SAML 2.0 to delegate authentication to an external IdP (like Salesforce Identity).
Unified Customer Identity: Use the same unique customer ID (e.g., Salesforce Contact ID) across B2C Commerce and Experience Cloud to link profiles.

Explanation:

To reduce Salesforce data storage while still letting users access ERP invoice records in Salesforce, the right pattern is to leave the invoices in the ERP and surface them in Salesforce as External Objects via Salesforce Connect.

External Objects let Salesforce display and relate records that aren’t stored in Salesforce, which directly addresses the storage problem.

Because the invoices are read-only, this is an ideal use case for Salesforce Connect (no need to persist/edit the data in Salesforce).

If the ERP doesn’t expose OData, you can use a custom Apex adapter to connect Salesforce Connect to the ERP’s API.

Why the other options are wrong

A. Change Data Capture and C. Platform Events still imply you are synchronizing/storing invoice records (or their changes) in Salesforce, which doesn’t solve the “40% storage” issue.

B. Build a custom solution could work, but it’s not the best practice / standard capability when Salesforce Connect is purpose-built for this exact requirement (virtualize large read-only datasets without storage impact).

Bottom line:
Use Salesforce Connect + External Objects to virtualize ERP invoices inside Salesforce and dramatically reduce org storage footprint.

Explanation:

This question addresses how CDP (Customer Data Platform) unifies customer profiles and shares those unified identities with B2C Commerce.
Core flow:
CDP ingests customer data from multiple sources (including B2C Commerce).
CDP uses matching rules to merge records into Unified Individuals.
CDP creates segments (audiences) from those Individuals.
Those segments can be activated (sent) back to B2C Commerce as Customer Groups for personalization.

Let’s evaluate each option:

A. Create Data Segments within CDP and create customer groups within B2C Commerce with the CDP Data Segments
Incorrect. While Data Segments in CDP can be activated to B2C Commerce as Customer Groups, the option skips the crucial step of creating Unified Individuals first. You must first unify profiles into Individuals before segmenting.

B. Create Customer Groups within B2C Commerce and create data segments within CDP with CDP Data Segments
Incorrect. This reverses the flow. Customer Groups in B2C Commerce are typically the destination for CDP segments, not the source. Also, you don’t “create data segments within CDP with CDP Data Segments” — that’s circular.

C. Create Individuals within CDP and create customer groups within B2C Commerce with the correct segments
Correct. This describes the proper sequence:
CDP creates Unified Individuals by merging records from B2C Commerce and other sources using matching rules.
CDP builds Data Segments from those Individuals.
Activate those segments to B2C Commerce as Customer Groups (via the Commerce Cloud CDP Connector).
This enables B2C Commerce to recognize the unified customer for personalization.

D. Create Data Segments within CDP and create customers within B2C Commerce with the CDP Data Segments
Incorrect. You do not create customers in B2C Commerce “with CDP Data Segments.” Customers in B2C Commerce are created via registration or order import. CDP segments are used to group existing customers (Customer Groups) for targeting, not to create customer records.

Key Concepts / References:

CDP Unified Individual: The golden record representing a single person across all source systems.
CDP Data Segment: A marketer‑defined audience built from Unified Individuals.
Commerce Cloud CDP Connector: Pushes CDP segments to B2C Commerce as Customer Groups, which can be used for promotions, pricing, and personalization.
Identity Resolution Flow: Source Data → CDP Ingestion → Matching & Unification → Segmentation → Activation to B2C Commerce.

Explanation:

To accomplish automatic case routing based on a customer's spend-based tier level in 2026, a Solution Architect should configure A. Assignment Rules and B. Queues.

A. Assignment Rules
The Logic Engine: Case Assignment Rules are the standard Salesforce tool used to automate the routing of cases.
Tier-Based Filtering: The architect would create rule entries based on the "Tier Level" field (which is typically synced from B2C Commerce or calculated in Service Cloud). For example: "If Tier Equals 'Gold', assign to the Gold Support Team."
Efficiency: This ensures that as soon as a case is created (via Web-to-Case, Email-to-Case, or the Commerce-Service Connector), it is evaluated against the business logic and sent to the appropriate destination without manual intervention.

B. Queues
The Destination: Queues represent the "separate support teams" mentioned in the requirement.
Workload Management: A Solution Architect would define specific queues for each tier (e.g., "Standard Tier Queue," "Platinum Tier Queue").
Team Access: By assigning the cases to these queues via the Assignment Rules (Option A), the members of those specific support teams can manage their own workloads and prioritize cases according to the organization's service level agreements (SLAs).

Why other options are incorrect:

C. Support Processes (Incorrect): A Support Process defines the status values (lifecycle) a case moves through (e.g., New → Working → Closed). It does not control the routing or assignment of the case to a specific team.

D. Auto Response Rules (Incorrect): These are used to send an automated email to the customer (the requester) to acknowledge that their case was received. While they can be filtered by tier to send a "Platinum-branded" reply, they do not assist in routing the case to the internal support team.

Architectural Note for 2026
For high-volume B2C environments, architects often recommend using Omni-Channel in conjunction with Queues. However, for the primary "automatic routing" mechanism required by the exam, the combination of Assignment Rules and Queues remains the fundamental standard.

Salesforce Help: Case Assignment Rules

Explanation:

In this scenario, Experience Cloud (community users) acts as the Identity Provider (IdP) for B2C Commerce storefronts via Social Sign-On or Salesforce as IdP authentication. Customers log in once to the community and are seamlessly authenticated to the commerce site(s), creating a unified login experience.

When Experience Cloud serves as the IdP and source of truth for identity:

The community user record (backed by Contact or Person Account in the Core org) becomes the primary customer profile.
Core profile data such as name, email, username, and Salesforce ID must be maintained in Experience Cloud because these fields drive authentication, single sign-on, and identity resolution across the commerce sites.
The Salesforce User/Contact ID from the community becomes the unified key that B2C Commerce uses (via b2c-crm-sync or authentication flow) to link or create the registered customer profile in Commerce.

Why the other options are not primary in Experience Cloud:

B. Shipping address
Shipping addresses are transactional and primarily captured/managed during checkout in B2C Commerce (Customer Address Book). They can sync to Service Cloud/Experience Cloud, but B2C Commerce is the usual system of record.

C. Payment methods
Payment tokens/instruments are securely stored in B2C Commerce (or third-party payment processors). They are not stored in Experience Cloud for security and PCI compliance reasons.

D. Communication preferences
Marketing preferences (opt-ins, channel subscriptions) are typically managed in Marketing Cloud (Preference Center) or synchronized to Service Cloud, not primarily in Experience Cloud.

Maintaining core identity data in Experience Cloud ensures reliable authentication and a single customer identity across communities and commerce sites.

References:
Salesforce Help: "Salesforce as Identity Provider for B2C Commerce" and Social Sign-On flows.

B2C Solution Architect exam emphasis on identity provider roles and core profile data as the anchor for unification in community-driven authentication scenarios.