A.   Set the value of the Style Sheet URL setting to match the publicly-accessible URL of the style sheet the organization wants to use.

Explanation:

In a multi-cloud solution involving Service Cloud and B2C Commerce, achieving brand consistency across different platforms (like a self-service portal and a storefront) is a key architectural requirement.

Publicly-Accessible CSS: The most efficient way to ensure the Service Cloud self-service portal mirrors the B2C Commerce storefront is to reference the same CSS file. Salesforce Service Cloud allows you to specify a Style Sheet URL in the portal settings.

Centralized Branding: By hosting the CSS file on a publicly accessible web server (or within the B2C Commerce instance itself) and pointing the Service Cloud portal to that URL, any global brand updates made to the CSS will automatically reflect in both the storefront and the portal.

Self-Service Implementation: According to the official Self-Service Portal Implementation Guide, one of the primary customization steps is to "Enter the URL of the style sheet in the Self-Service settings" to control branding.

Why other options are incorrect

B: There is no standard setting called "Portal Theme URL" in Service Cloud; the correct field is specifically named the Style Sheet URL.

C & D: Manually copying/pasting code or uploading files creates a "maintenance nightmare." If the company updates its brand theme in B2C Commerce, the Architect would have to manually update the portal again. These methods do not support a "seamless" or "scalable" multi-cloud architecture.

Key Domain Context (2026 Exam)

Functional Capabilities and Business Value (19%): This domain tests your ability to use native product features (like Service Cloud portal settings) to deliver business requirements such as brand consistency.

Architecture Design (18%): A Solution Architect must prioritize "reusability" and "scalability." Referencing a single central style sheet is a more robust design than duplicating code across systems.

B.   Customer journey flow

Explanation

In the Salesforce B2C multi-cloud architecture, each system has a primary domain where it acts as the system of record (single source of truth):

Why B is Correct:

Marketing Cloud's Core Function: Marketing Cloud is fundamentally a Marketing Engagement and Journey Orchestration platform. Its primary role is to:
- Design, execute, and manage multi-step customer communication journeys (e.g., welcome series, post-purchase nurture, re-engagement campaigns).
- Track interaction history (email sends, opens, clicks, SMS deliveries) and use that data to personalize the next best step in a journey.
The "journey flow" logic—the decision splits, wait times, triggers, and paths—lives natively and authoritatively within Marketing Cloud. No other cloud in this trio manages this.

Why A is Incorrect:

Demographic/Profile Data (Name, Address, Email): The single source of truth for customer identity and core attributes should be Service Cloud (or the core Salesforce Platform, i.e., the Contact/Account object). This is the Golden Record. Marketing Cloud subscribes to this data via Marketing Cloud Connect or integrations. Marketing Cloud may extend this with marketing-specific attributes (e.g., EmailOptInDate), but the canonical name, address, and email should come from Service Cloud.

Why C is Incorrect:

Order History: The system of record for transactions and orders is B2C Commerce. It manages the entire order lifecycle (cart creation, payment capture, fulfillment status). This data is shared with Service Cloud for service cases and with Marketing Cloud for journey triggers (e.g., "Order Confirmation" email) and reporting, but the authoritative source is B2C Commerce.

Why D is Incorrect:

Customer Product Affinity: This is typically derived from behavioral and transactional data. The raw data comes from B2C Commerce (product views, add-to-carts, purchases). While Marketing Cloud can calculate engagement scores and use them in journeys, the foundational product interaction data originates in Commerce. In a sophisticated architecture, a centralized customer data platform (like Salesforce Data Cloud) might become the source for a unified affinity score, but among these three, it is not Marketing Cloud's native domain.

Architectural Reference & Key Concept

Reference: Salesforce Multi-Cloud Architecture Principles & Domain-Driven Design. This tests the understanding of the System of Record pattern for key data domains across the B2C suite.

Key Concept:
- Service Cloud (Core Platform): Single Source of Truth for Customer Identity (Who is the customer?).
- B2C Commerce: Single Source of Truth for Commerce Transactions (What did they buy?).
- Marketing Cloud: Single Source of Truth for Communication Journeys and Engagement History (How and when did we talk to them?).

The Solution Architect must guide NTO to build their data strategy around these domain authorities. Marketing Cloud is the brain for orchestrating when and how to communicate based on data sourced from the other systems. Attempting to make it the source of identity or order data creates duplication, inconsistency, and integration debt.

A.   Lifetime engagement tracking and history, other data for personalization or segmentation should be mastered in Marketing Cloud

D.   Store primary attributes (name, address, birthday, phone, and email) about the customer in Service Cloud

Explanation

Option A (✅ Correct):
Marketing Cloud is the system of record for engagement data—email sends, opens, clicks, journey participation, and segmentation attributes. It is designed to track lifetime engagement history and manage personalization data. This ensures that campaigns and journeys are based on accurate behavioral and preference data.

Option B (❌ Incorrect):
Heroku is not the system of record for ecommerce transactions. B2C Commerce is the authoritative source for orders, promotions, and product affinity. Heroku may be used for custom apps or extensions, but it is not the master system for transactional data.

Option C (❌ Incorrect):
User consent, compliance preferences, and customer journey flow should not be mastered in B2C Commerce. Consent and compliance preferences belong in Service Cloud (or Customer 360/Privacy Center), while journey orchestration belongs in Marketing Cloud. B2C Commerce is focused on transactional and storefront data, not compliance or journey orchestration.

Option D (✅ Correct):
Service Cloud is the system of record for customer identity and primary attributes (name, address, birthday, phone, email). It acts as the customer master across the multi-cloud architecture. Marketing Cloud consumes these attributes for personalization, but Service Cloud owns them.

🔑 Key Takeaway
In a multi-cloud Salesforce architecture:

- Service Cloud → Master for customer identity and core attributes.
- B2C Commerce → Master for transactional data (orders, carts, promotions).
- Marketing Cloud → Master for engagement history, journeys, and personalization attributes.
- Heroku → Extension platform, not a system of record.

📚 References
Salesforce Architect Guide: Multi-Cloud Data Strategy
Salesforce Help: Marketing Cloud Data Management
Salesforce Well-Architected Framework – Data Ownership

A.   Authentication credentials

Explanation:

Why A is correct
In this scenario, Experience Cloud (Communities) is acting as the Identity Provider (IdP) for commerce. When Experience Cloud is the IdP, it is the system responsible for authenticating users—meaning the login identity / authentication credentials are mastered there (via Salesforce Identity / Experience Cloud customer identity). Salesforce’s guidance on Customer Identity notes that you manage customer identity through Experience Cloud sites, including login/self-registration experiences.

And for B2C Commerce identity provider setups (e.g., via SLAS), when an external IdP is used, shopper credentials are stored in the external identity system rather than in B2C Commerce—which aligns with Experience Cloud being the SoR for credentials in this architecture.

Why the other options are not Experience Cloud systems of record

B. Address book
Typically mastered in commerce / customer profile (e.g., B2C Commerce customer address book) or CRM depending on the operating model—not the community/IdP layer.

C. Wishlist
This is a commerce-domain artifact and is usually mastered in B2C Commerce.

D. Payment information
Should be mastered in payments systems / tokenization providers or commerce payments capabilities—not in Experience Cloud (and generally not stored directly due to PCI/security requirements).

A.   Need for additional handling of consent, preferences, and compliance for converted leads in Marketing Cloud

C.   Leads are unique contact records in Marketing Cloud

Explanation:

A. Need for additional handling of consent, preferences, and compliance for converted leads in Marketing Cloud
Why it is correct: In Salesforce (Sales/Service Cloud), converting a Lead into a Contact/Account record effectively creates a new 18-digit ID. Because Marketing Cloud treats the Subscriber Key as the unique identifier, the consent and opt-out preferences stored against the Lead ID do not automatically transfer to the new Contact ID within Marketing Cloud's system tables.
Architectural Impact: The architect must design a process (often using Automation Studio or custom triggers) to ensure that if a customer unsubscribed as a Lead, they remain unsubscribed once they become a Contact to ensure GDPR/TCPA compliance.

C. Leads are unique contact records in Marketing Cloud
Why it is correct: Marketing Cloud is "Contact-based," but its definition of a Contact is any record in the All Subscribers table. When you sync a Lead record from Sales Cloud to Marketing Cloud, it consumes one "Contact" license. When that Lead is converted to a Contact in Sales Cloud, a second unique record is created in Marketing Cloud with a different Subscriber Key (the Contact ID).
Billing/Data Impact: This effectively doubles the contact count for that individual in Marketing Cloud until the old Lead record is deleted or suppressed, impacting license usage and billable contact limits.

Detailed Analysis of Incorrect Answers

B. Engagement history from the lead record will be natively available for contact record in Marketing Cloud
Why it is incorrect: As mentioned above, Marketing Cloud views the Lead and the Contact as two entirely separate entities because their Subscriber Keys (the primary keys) are different. Without a custom "Identity Stitching" solution or a CDP (Data Cloud), the engagement history (clicks, opens) associated with the Lead record will stay with the Lead record and will not "natively" merge into the new Contact record's history in Marketing Cloud.

D. Leads can have detrimental impact on quality of contact records in Sales Cloud
Why it is incorrect: While poor lead management can lead to duplicates, this is a general CRM data hygiene issue rather than an "architectural implication" of the proposed multi-cloud nurturing journey. In fact, using a Lead-management process is the standard way to protect the quality of Contact records by ensuring only qualified, "clean" data is converted into the permanent database.

References
Salesforce Help: Marketing Cloud Connect: Lead Conversion - Details how Subscriber Keys change during conversion.
Salesforce Architects: Identity Management for Multi-Cloud - Discusses the "Identity Gap" during lead-to-contact transitions.
Marketing Cloud Documentation: Definition of a Contact and Subscriber - Explains how both leads and contacts count toward the total contact limit.

C.   Recommend CDP to integrate with their existing marketing tools and create individual profiles into commerce with the Commerce COP Connector

Explanation:

Why C is correct
The CMO’s goal is not to replace existing marketing tools, but to integrate them and have commerce as the foundation (“commerce underlying all”).
Salesforce CDP (now Data Cloud / Data 360) is designed to ingest and unify customer data from multiple systems (including non-Salesforce sources via connectors) into a single customer profile that can then be activated back into downstream systems.
For the “commerce underlying all” part, Salesforce provides a B2C Commerce → CDP/Data Cloud connector (often referenced as the Commerce CDP connector / B2C Commerce connector) to bring commerce data into Data Cloud and unify it with other sources.
So C matches both constraints:
works with existing marketing tools (doesn’t force a new one),
uses the Commerce CDP connector to ground profiles and insights in commerce behavior/data.

Why the other options are wrong

A. Replace existing marketing tools with CDP
This contradicts the requirement: “They do not want to force a new marketing tool on all the business units.” CDP/Data Cloud complements tools; it doesn’t need to replace them.

B. Use CRM Analytics to integrate and create a single view
CRM Analytics can unify and visualize data for analytics, but it’s not the best “integration + customer profile unification + activation” layer for a multi-martech environment the way Data Cloud/CDP is positioned (especially with a dedicated B2C Commerce connector).

D. Recommend Marketing Cloud to integrate with existing marketing tools
Marketing Cloud is a marketing platform. Recommending it would effectively introduce a new marketing tool, which the business explicitly wants to avoid.

B.   Implement a separate business unit for each B2C Commerce storefront to ensure that each storefront has its own Marketing Cloud product catalog from which product recommendations will be driven.

D.   Implement abandoned cart using Marketing Cloud's Behavioral Trigger feature and create an abandonment journey for each storefront and their paired business unit. The B2C Commerce storefront must also be extended to re-create the customer's shopping cart with abandoned products.

Explanation:

Core Challenge: You have three distinct B2C Commerce storefronts. Each likely has its own product catalog (with potentially different products, IDs, and prices). Marketing Cloud's product recommendations (e.g., in Email Studio's dynamic content) are driven by a Product Catalog that is scoped to a single Business Unit.

Why B is Correct:
One-to-One Mapping is Best Practice: The cleanest, most maintainable architecture is to create a 1:1 relationship between a B2C Commerce storefront and a Marketing Cloud Business Unit. This allows each BU to have its own dedicated Product Catalog that perfectly mirrors its associated storefront's catalog.
Enables Accurate Recommendations: With separate catalogs, product recommendations in emails (like "You might also like...") will be accurate for that specific storefront's inventory. A single, shared catalog for three different storefronts would be inaccurate and unmanageable.

Why D is Correct:
Correct Technical Implementation of Abandoned Cart:
Trigger: Use Marketing Cloud's Behavioral Trigger (via the B2C Commerce cartridge) to fire an event when a cart is abandoned on a specific storefront.
Journey Scope: The abandonment journey should be built in the paired Business Unit (from option B) for that storefront, ensuring it uses the correct catalog and sender profile.
Critical Commerce-Side Requirement: The email can contain a link back to the cart, but B2C Commerce must be configured to restore the abandoned cart when the customer clicks. This typically involves custom logic in the storefront to look up the abandoned cart (via OrderMgr) and re-initialize the session. Marketing Cloud cannot magically restore the cart; it can only trigger the event and provide a link.
This option correctly describes the end-to-end, multi-cloud implementation.

Why A is Incorrect:
A single Business Unit cannot natively maintain multiple, storefront-specific product catalogs. Its product catalog is a single data set. Trying to share one catalog across three different storefronts would lead to wrong product IDs, incorrect pricing, and recommendations for products not available on that site. It is an unworkable architecture for the stated requirements.

Why C is Incorrect:
This repeats the flawed single-BU model of A. While Marketing Cloud Einstein can do predictive scoring, it does not have a magic mechanism to make a single product catalog automatically render storefront-specific recommendations. The fundamental data separation (three catalogs) is not addressed. It also glosses over the essential B2C Commerce development work needed to restore the cart.

Architectural Reference & Key Concept:
Reference: Marketing Cloud Connect for B2C Commerce Guide - Multi-Site Considerations & Abandoned Cart Setup.

Key Concept:
Business Unit Strategy for Multiple Storefronts: The architect must map technical boundaries (storefronts) to Marketing Cloud's organizational boundaries (BUs) to maintain data integrity, especially for master data like Product Catalogs.
End-to-End Journey Ownership: Implementing a cross-cloud use case like abandoned cart requires clear ownership per system. Marketing Cloud owns the orchestration and messaging; B2C Commerce owns the cart data persistence and session restoration. The architect must ensure both sides are designed.

The solution requires a segregated BU structure (B) for clean data separation and a correctly scoped, technically complete implementation of the abandoned cart use case (D) that involves development work in both clouds.

D.   Change Data Capture

Explanation:

The requirement is near-real-time synchronization of all changes (create, update, delete, undelete) on Salesforce records to an external custom retail loyalty application, with minimal performance impact on the Salesforce org (Experience Cloud + Service Cloud).

Option D (Correct): Change Data Capture (CDC) is the most appropriate mechanism.
It publishes events for create, update, delete, and undelete operations on supported objects (including custom objects) in near-real time.
Events are delivered via a publish-subscribe model (CometD streaming or Platform Events replay).
The external loyalty app subscribes to these events (e.g., via EmpConnector, CometD client, or replay via Platform Event replay IDs).
CDC has very low overhead on transactional performance because it is asynchronous and handled outside the transaction execution context.
No polling required, and it scales well for high-volume changes without governor limit concerns in the originating transaction.

Option A (Incorrect): Outbound Messages (part of Workflow Rules, now deprecated in favor of Flows) support only create and update (not delete/undelete), use SOAP, have reliability limitations (no guaranteed delivery retries beyond 24 hours), and are being phased out.

Option B (Incorrect): Triggered Send Definition is a Marketing Cloud-specific feature for sending transactional emails/SMS based on API events. It has no relevance to synchronizing data changes to an external loyalty system.

Option C (Incorrect): Apex Trigger Callout (synchronous or asynchronous HTTP callouts from triggers) can achieve real-time sync but has significant drawbacks:
Synchronous callouts block the transaction and risk timeouts.
Asynchronous (@future, Queueable) reduce blocking but still consume governor limits (e.g., async apex executions).
High-volume changes can exhaust limits and impact org performance.
Not recommended for large-scale, ongoing integrations.

References:
Salesforce Help: Change Data Capture – explicitly supports create/update/delete/undelete events with low performance impact and near-real-time delivery.
Integration Patterns and Practices Guide: Recommends CDC or Platform Events for near-real-time change propagation to external systems over callouts or outbound messages.
B2C Solution Architect exam topics: Integration strategies, performance considerations, and modern event-driven patterns (CDC, Platform Events) vs. legacy mechanisms.

A.   Enable Contact to Multiple Accounts

B.   Duplicate Matching Rules

Explanation
Option A (✅ Correct):
The Contact to Multiple Accounts feature allows a single Contact record to be related to multiple Accounts (e.g., parent company and subsidiaries). This prevents the need to create duplicate Contacts for the same person when they interact with multiple entities in the Account Hierarchy.
→ This is the best practice for modeling shared relationships across subsidiaries.

Option B (✅ Correct):
Duplicate Matching Rules (and Duplicate Rules) help prevent or detect duplicate Contacts during data migration or ongoing data entry. They can be configured to match on key fields (e.g., email, phone, name) and either block duplicates or alert users.
→ This ensures that only one Contact record exists per person, even across multiple Accounts.

Option C (❌ Incorrect):
Lightning Data Services is a client-side framework for building Lightning Components without Apex controllers. It does not address duplicate management or cross-account relationships. It’s not relevant to solving this problem.

Option D (❌ Incorrect):
Customer Data Platform (CDP / Data Cloud) is used for unifying customer profiles across multiple systems and clouds. While powerful, it is not necessary for solving duplicate Contacts within Salesforce itself. The problem can be solved natively with Contact to Multiple Accounts and Duplicate Rules.

🔑 Key Takeaway
To ensure a single Contact per person across subsidiaries:
Use Contact to Multiple Accounts to model relationships across the Account Hierarchy.
Configure Duplicate Matching Rules to prevent duplicate Contacts during migration and ongoing operations.
Avoid unnecessary complexity (CDP) or irrelevant features (Lightning Data Services).

📚 References
Salesforce Help: Contacts to Multiple Accounts
Salesforce Help: Duplicate Management Overview
Salesforce Architect Guide: Data Quality Best Practices

B.   Develop a custom solution in Service Cloud to consume and communicate with B2C Commerce APIs

Explanation:

Why it is correct: Since the company has explicitly ruled out middleware (like MuleSoft), the integration must be handled directly between the two platforms.

Direct Communication: Service Cloud can act as the initiator of the update. By using Apex (triggers or flow-driven asynchronous Apex), Service Cloud can make a REST API callout directly to the B2C Commerce Data OCAPI (Open Commerce API) or Salesforce Commerce Cloud (SCAPI).

ID Mapping: Because the prompt assumes a common ID already exists, the custom Apex code in Service Cloud can easily target the correct customer record in B2C Commerce and perform a PATCH or PUT request to update the attributes (like the customer name).

Detailed Analysis of Incorrect Answers
A. Send a platform event from Service Cloud and subscribe to it in B2C Commerce using the built-in functionality
Why it is incorrect: While Service Cloud is excellent at publishing Platform Events, B2C Commerce does not have "built-in functionality" to natively subscribe to Salesforce Platform Events. Subscribing to platform events requires a CometD client or a middle tier, which B2C Commerce lacks. To make this work, you would ironically need the middleware the company refused to implement.

C. Send an Outbound Message from Service Cloud and catch and handle the Outbound Message using the B2C Commerce APIs
Why it is incorrect: Outbound Messaging sends a SOAP message to a specific endpoint. B2C Commerce APIs (OCAPI/SCAPI) are REST-based and are not designed to "listen" for and parse incoming XML/SOAP messages formatted as Salesforce Outbound Messages. You would need a listener (middleware) to translate the Outbound Message into a format B2C Commerce understands.

D. Use change data capture (CDC) to send a message... and handle the message using B2C Commerce Service Cloud Connector
Why it is incorrect: This is a common point of confusion. The B2C Commerce "Service Cloud Connector" is a set of cartridges and Apex code, but it is primarily designed to facilitate the flow of data from Commerce to Service Cloud, or to allow Service Cloud to "pull" data (like via the Service Cloud Profile Link). It does not contain a native, out-of-the-box listener that automatically processes CDC events from Service Cloud to update the Commerce database.

References
Salesforce Architects: B2C Commerce Integration Patterns - Discusses the use of OCAPI/SCAPI for point-to-point integrations.
B2C Commerce Developer Center: Data OCAPI: Customer Resources - Documentation on how to update customer records via external API calls.
Salesforce Help: Apex Callouts - Explains how to integrate Salesforce with external services when middleware is absent.

D.   Sync Contact object.

Explanation:

In a Salesforce multi-cloud architecture, even when Person Accounts are enabled in Sales or Service Cloud, Marketing Cloud Connect primarily synchronizes and identifies individuals using the Contact object.

Marketing Cloud Subscriber Key: The architecture of Marketing Cloud centers on the Contact ID (or Subscriber Key). For a Person Account, Salesforce automatically creates an underlying Contact record. Synchronizing the Contact object ensures that the unique Contact ID is used as the SubscriberKey in Marketing Cloud.

Accessing Account Data: While the Contact object is the primary sync point, Marketing Cloud Connect allows you to pull in related fields from the Person Account (such as the PersonContactId) during the synchronization process to ensure all relevant consumer attributes are available for personalization.

Best Practice: Directly syncing the Contact object is the standard 2026 recommendation because many native Marketing Cloud features, such as Journey Builder and standard email tracking, are built to work with Contact-level IDs rather than Account-level IDs.

Why other options are incorrect
A. Sync Subscriber object: There is no "Subscriber" object in Sales Cloud to sync; "Subscriber" is a concept within Marketing Cloud that represents the synchronized record from Salesforce.

B. Sync Person Account object: While Person Accounts are records in the Account object, Marketing Cloud's engagement model specifically tracks individuals. Syncing the Account object alone would not provide the necessary native Contact-level identifiers required for a standard Subscriber Key.

C. Sync Individual object: The Individual object is used primarily for managing data privacy and consent preferences across the platform, not for primary identity synchronization of subscribers in Marketing Cloud.

Key Domain Context (2026 Exam)
Data Models and Management (25%): This question tests your ability to map CRM data models (Person Accounts) to Marketing Cloud data extensions while maintaining a consistent identity (Contact ID).
Integration (23%): Focuses on the configuration of Marketing Cloud Connect to ensure bidirectional data flow for B2C individuals.

A.   Fix the data quality issues in Service Cloud before migrating to Marketing Cloud.

C.   Map Contact, Lead, and Account objects within Marketing Cloud to enable personalization.

Explanation:

A. Fix the data quality issues in Service Cloud before migrating to Marketing Cloud.
Why this is correct: Marketing Cloud personalization and deliverability depend heavily on clean identity + valid email addresses. If Service Cloud has duplicates and incomplete/invalid emails, pushing that data into Marketing Cloud will:
- inflate contact counts,
- fragment engagement history across multiple Contact Keys,
- increase bounce rates and harm sender reputation,
- break personalization (wrong attributes, wrong customer).

So the best migration strategy is to remediate data quality at the source (Service Cloud) first, then integrate/sync.

C. Map Contact, Lead, and Account objects within Marketing Cloud to enable personalization.
Why this is correct: To send personalized communications, Marketing Cloud needs access to the right CRM attributes. With Marketing Cloud Connect / Synchronized Data Sources, you commonly synchronize CRM objects like:
- Contact (and/or Leads depending on business process),
- Account (for account-level attributes such as tier, segment, owner, etc.)

Then you map/use those fields in data extensions, journeys, and message content for personalization.

Why not B
B. Use CDP to synchronize data between Service Cloud and Marketing Cloud
CDP/Data Cloud can help unify profiles and activate data, but it’s not the core “migration strategy” answer here. It won’t automatically fix duplicates/invalid emails in Service Cloud, and it’s not required just to connect Service Cloud to Marketing Cloud.

Why not D
D. Build a custom connector … that will remove duplicates
That’s the wrong place to solve the problem. Deduplication should be handled in CRM/source systems using standard data governance tools and processes (duplicate rules, matching rules, cleansing), not via a bespoke connector that tries to “clean” during sync.