Explanation:

Salesforce Order Management (SOM) is the recommended, productized solution for multi-brand, moderate-to-high volume order processing (2,000 orders/hour is well within capacity). It provides fulfillment orchestration, order lifecycle management, and native integration with B2C Commerce while leveraging the Core platform.
Why these three are correct:

✅ B. B2C Commerce order management does not support complex or advanced use cases.
B2C Commerce's native Order Management APIs (Order Groovy scripts, hooks) are designed for basic post-checkout processing (export, simple status updates). They lack advanced capabilities like multi-location fulfillment orchestration, returns management, payment reconciliation, change orders, or distributed order management—features SOM provides out-of-the-box. For complex or growing needs, native B2C Commerce OM is insufficient.

✅ C. The existing Service Cloud implementation team could extend the Salesforce Order Management product to the existing org.
SOM is built on the Salesforce Core platform (same org as Service Cloud). It can be enabled in an existing Service Cloud org (with appropriate licensing). The existing team can configure/extend SOM using declarative tools (flows, custom objects) or Apex, leveraging their familiarity with the org—no new platform to learn.

✅ E. Salesforce Order Management shares the same database with Service Cloud while other solutions need to build additional integration.
SOM runs natively in the Core org (same database as Service Cloud). Orders, Order Summaries, and fulfillment data are accessible directly to Service Cloud agents (e.g., related lists on Person Accounts/Cases) without additional synchronization layers. Custom or B2C-native solutions would require extra integrations to achieve the same visibility.

Why the others are incorrect:

A: SOM complements, not replaces, the Service Cloud Connector (b2c-crm-sync). Customer/order sync for agent visibility still uses the connector; SOM handles fulfillment lifecycle.

D: SOM's B2C Commerce connector supports one-to-one realm-to-org ingestion. Synchronizing to multiple Core orgs from one realm requires additional customization or connectors (not native). The company has two Core orgs, so this statement is inaccurate.

References:
Salesforce Help: Order Management Overview and B2C Commerce connector limitations.
B2C Solution Architect resources: SOM vs. native B2C OM vs. custom for scalability and integration depth.

Explanation:

To support the customer service representative (CSR) in purchasing and reviewing these complex, component-based configurable products in 2026, a Solution Architect should recommend solutions that leverage real-time data from the storefront.
The two correct answers are C and D.

✅ C. Use hooks to extend the existing Open Commerce API (OCAPI) product endpoint with additional information about the custom product options and component availability in real time to support a custom experience in Service Cloud.
Real-Time Accuracy: Because inventory for this table is tracked at the component level (legs, hardware, etc.), the CSR needs real-time visibility into what is in stock. Extending the native OCAPI product endpoint via hooks is the architecturally sound way to inject custom logic (such as component availability) into the standard API response. Salesforce B2C Commerce OCAPI Hooks.
Custom Experience: This allows a custom Lightning Web Component (LWC) in the Service Console to call B2C Commerce and display the exact same configuration options available to the customer, ensuring the CSR can accurately assist with complex product questions.

✅ D. Use Customer Service Representative (CSR) Order on Behalf Of to access the existing B2C Commerce storefront as a CSR acting on behalf of a customer when making purchases or reviewing custom products.
Leveraging Existing Logic: The merchant has already built the complex configuration logic on the storefront. By using the Order on Behalf Of (OOBO) functionality, the CSR can "launch" into the storefront directly from the Service Console. Service Cloud Connector for B2C Commerce.
Functional Parity: This ensures the CSR sees exactly what the customer sees, including the custom UI for selecting table tops and hardware. It is the fastest path to ROI because it reuses the existing storefront investment rather than rebuilding the configuration logic inside Service Cloud.

Why other options are less optimal for 2026:

A (Incorrect): While creating a new custom OCAPI endpoint is possible, it is considered less efficient than extending the existing product endpoint (Option C). Salesforce best practices for 2026 prioritize extending standard resources to maintain better compatibility with platform updates.

B (Incorrect): A nightly export is completely inappropriate for this use case. Inventory for components changes throughout the day; a nightly sync would lead to the CSR attempting to sell items that are out of stock, resulting in a poor customer experience and order fulfillment errors.

Architectural Tip:
For the Arch-302 exam, always prioritize Real-Time Integration (APIs) or Session Federation (OOBO) when a business process requires synchronized logic between two clouds. Avoid batch processing (nightly jobs) for any data that is highly volatile, such as inventory.

Explanation:

✅ B. Ability to de-duplicate and create a single customer identity
Service Cloud (Salesforce Platform) supports customer identity management and deduplication patterns:
Matching/Duplicate Rules
Customer 360 identity modeling (Account/Contact/Person Account/Individual)
Identity integrations (SSO/Identity) and consistent customer records across service interactions
This is a common Service Cloud value conversation when the business wants a unified customer view for service across channels, including social.

✅ C. Ability to allow the agent to see purchase history to support case management
Service Cloud’s core value for call centers is case management + a 360° agent console. When integrated with B2C Commerce (e.g., via the B2C Commerce–Service Cloud connector), agents can view order/purchase history and use it to resolve issues (returns, shipment problems, warranty questions, etc.) directly in the service workflow.

Why not the others
A. Create a B2C storefront using Digital Experiences — Experience Cloud can support portals, but B2C Commerce is the storefront platform; this isn’t the right “Service Cloud value” point for online ordering.

D. Have a customer leave a journey when they have an escalated case — that’s a Marketing Cloud / orchestration concept (integration between service events and journeys), not a core Service Cloud differentiator.

If your exam version expects only “Service Cloud + digital engagement,” an alternative second pick sometimes seen is Digital Engagement (social channels, messaging, etc.)—but since it’s not listed, B is the best fit among the options.

Explanation:

✅ Why Option C Is Correct: Single Tenant + Business Units per Site
Reasoning:
Best practice is to use one Marketing Cloud tenant for the organization to centralize governance, security, and licensing.
Within that tenant, Business Units (BUs) are created for each site (Australia, New Zealand, Singapore).
This allows each country team to manage localized campaigns, automations, and data, while still rolling up reporting and compliance under one tenant.
Realms in B2C Commerce are technical constructs for site hosting, but Marketing Cloud segmentation should align with business/site operations, not realms.
Outcome: Efficient, scalable setup with unified governance and localized execution.

❌ Why Option A Is Incorrect: Separate Tenant per Site
Multiple tenants would fragment data, increase cost, and complicate governance.
Not recommended unless there are strict legal or compliance requirements per country (not mentioned here).

❌ Why Option B Is Incorrect: Separate Tenant per Realm
Realms are technical hosting constructs in Commerce Cloud, not business divisions.
Mapping tenants to realms would misalign Marketing Cloud with business operations.

❌ Why Option D Is Incorrect: Business Units per Realm
This would only give two BUs (ANZ, SE Asia), which doesn’t reflect the need for site-level segmentation (Australia, New Zealand, Singapore).
Each site should have its own BU for localized marketing.

Key Takeaways (Flashcard Style)
C: Correct → Single tenant, BUs per site (Australia, NZ, Singapore).
A: Wrong → Multiple tenants = fragmented, costly.
B: Wrong → Realms ≠ business segmentation.
D: Wrong → BUs per realm misses site-level granularity.

✅ In summary: The Solution Architect should recommend C (single Marketing Cloud tenant with Business Units mapped to each site) to ensure scalable, compliant, and localized marketing automation across Australia, New Zealand, and Singapore.

Explanation:

To enable an Abandoned Cart Journey in Marketing Cloud triggered by real-time or near-real-time cart activity in B2C Commerce, the journey relies on behavioral events (cart add/remove/view) captured from the storefront.

Why these two are correct:

A. Integrate product, order, and customer data feeds into Marketing Cloud Data Extensions
Abandoned cart journeys require contextual data (e.g., abandoned products, SKUs, prices, images, customer email) to personalize recovery emails. This data (products, orders, customers) is synchronized from B2C Commerce into Marketing Cloud Data Extensions (via the Marketing Cloud Cartridge/Einstein Personalization Connector). These DEs enrich the journey entry event with details for dynamic content blocks and segmentation.

D. Implement the Marketing Cloud collect.js through the storefront by using the Connector's reference implementation
The collect.js tracking code (part of Marketing Cloud Personalization/Einstein) is the primary mechanism for capturing real-time cart events on the storefront. When implemented via the Marketing Cloud Connector Cartridge (or Einstein cartridge reference implementation), it sends cart abandonment events to Marketing Cloud. These events serve as entry sources in Journey Builder for abandoned cart flows (e.g., "Cart Abandonment" event triggers the journey).

Why the others are incorrect:

B: Service Cloud integration is valuable for agent visibility or OOBO, but not required for abandoned cart journeys in Marketing Cloud.
C: MuleSoft can be used for custom integrations, but the standard, recommended approach for abandoned cart is the native Marketing Cloud Cartridge + collect.js—no MuleSoft needed.

This is Salesforce's documented best practice for event-driven abandoned cart recovery.

References:
Salesforce Help: "Abandoned Cart Recovery" with B2C Commerce and Marketing Cloud.
Marketing Cloud Personalization Builder: collect.js implementation for cart events.
B2C Solution Architect exam focus on collect.js as the key enabler for behavioral journeys like abandoned cart.