B2C-Solution-Architect Practice Test Questions

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.

A.   The name and description for the shipping method are not set up correctly in B2C Commerce or Service Cloud for the requested locale.

D.   The ShippingMethods data extension is missing the label and description field for the corresponding locale.

Explanation:

Order confirmation emails in this multi-locale, multi-cloud setup are transactional emails sent from Marketing Cloud, triggered either by B2C Commerce (via the Marketing Cloud Connector cartridge and Transactional Messaging API) or by Service Cloud (via Marketing Cloud Connect triggered sends). Dynamic content such as shipping method name and description is typically pulled from B2C Commerce data (e.g., order summary or shipping method details) and inserted into the email using AMPscript or personalization strings.

Common reasons why shipping method name and description specifically can appear missing or in the wrong language (while other translated content works fine):

Option A (Correct): The name and description for the shipping method are not set up correctly in B2C Commerce or Service Cloud for the requested locale.
In B2C Commerce, shipping methods are configured in Business Manager with locale-specific display names and descriptions. If these fields are left blank or only populated for en_US (or the primary locale), no translated value will be available when the order is placed in another locale. The connector passes the shipping method ID and the requested locale to Marketing Cloud, but if no translation exists in B2C Commerce, the email will receive null/empty values for name and description—even though other content (e.g., product names, static email text) is correctly translated via Marketing Cloud content blocks or B2C catalog translations.

Option D (Correct): The ShippingMethods data extension is missing the label and description field for the corresponding locale.
Many implementations import or synchronize the shipping methods catalog into a ShippingMethods data extension in Marketing Cloud (often via Automation Studio or connector). This DE is then used in AMPscript Lookup functions to retrieve localized name/description based on the shipping method ID and locale passed from the order trigger. If the data extension rows lack populated label and description columns for non-en_US locales (or use flat fields instead of locale-specific columns like label_fr_FR, description_es_ES), the lookup will return empty values for those languages.

Option B (Incorrect): The subscriber's preferred locale in Marketing Cloud affects default language fallback for journeys and preference center, but transactional order confirmation emails are driven by the order/checkout locale from B2C Commerce (or case locale from Service Cloud), not the subscriber's profile locale. Missing shipping details are not caused by this.

Option C (Incorrect): The locale in the email template body (e.g., via Content Builder language variants or AMPscript SetLanguage) controls static content translation, but dynamic shipping method details are pulled separately via data from the trigger or lookups. Correct template locale settings explain why other content translates properly, but not the shipping method fields.

References:
Salesforce Help: B2C Commerce Connector – Shipping method localization handled in Business Manager; passed values depend on locale-specific configuration.
Marketing Cloud Documentation: Transactional Messaging API and order trigger payloads include locale context; recommended to use localized ShippingMethods DE for dynamic lookups.
B2C Solution Architect exam topics: Multi-locale considerations, data synchronization for transactional emails, and common pitfalls with shipping/payment method localization.

A.   NTO can use Marketing Cloud REST API for integrating with Service Cloud.

D.   NTO can use Marketing Cloud SOAP API for integrating with Service Cloud.

Explanation

Option A (✅ Correct):
The Marketing Cloud REST API is widely used for programmatic integrations. It supports operations such as managing contacts, journeys, triggered sends, and data extensions. REST is modern, flexible, and well-suited for integrating Service Cloud portals with Marketing Cloud.

Option B (❌ Incorrect):
Marketing Cloud REST API calls are synchronous, not asynchronous. Timeout values are not defined as 120 or 300 seconds in the way described here. This statement is misleading and incorrect.

Option C (❌ Incorrect):
The Marketing Cloud REST API uses JSON, not XML, for request and response bodies. XML is used by the SOAP API, not REST. Therefore, this statement is inaccurate.

Option D (✅ Correct):
The Marketing Cloud SOAP API is still relevant for certain operations, especially around email sends, subscribers, and lists. While REST is preferred for most modern use cases, SOAP can complement REST when legacy or specific functionality is required. A Solution Architect should highlight that both APIs are available and can be leveraged depending on the use case.

🔑 Key Takeaway
For programmatic integration between Service Cloud and Marketing Cloud:
Use REST API for modern, flexible operations (contacts, journeys, data extensions).
Use SOAP API for legacy or subscriber/list management use cases.
Avoid misconceptions: REST uses JSON, not XML, and calls are synchronous.

📚 References
Salesforce Developers: Marketing Cloud REST API Overview
Salesforce Developers: Marketing Cloud SOAP API Overview

B.   Allows agents to more easily access customer data to better support customers when they call in

C.   Allows agents to use SSO to log into B2C Commerce and Service Cloud using the same credentials

Explanation:

B. Allows agents to more easily access customer data to better support customers when they call in.
Why it is correct: In the current state, agents use spreadsheets and cannot easily access the ordering system. A connected B2C solution (Service Cloud + B2C Commerce) provides a Unified Customer View. Using tools like the Service Cloud Connector, agents can view a customer's entire order history, profile details, and previous support interactions in a single console. This eliminates the "valuable time" lost switching between systems and directly addresses the customer satisfaction (CSAT) issue.

C. Allows agents to use SSO to log into B2C Commerce and Service Cloud using the same credentials.
Why it is correct: From a functional and business value perspective, Single Sign-On (SSO) reduces friction for the agent. In a connected solution, agents often need to "Order on Behalf of" a customer or check real-time inventory in the B2C Commerce Business Manager. SSO ensures they can move between the Service Console and Commerce tools seamlessly without managing multiple passwords, which improves operational efficiency and security.

Detailed Analysis of Incorrect Answers
A. Provides a better interface for agents using Service Cloud and B2C Commerce with Heroku.
Why it is incorrect: While Heroku can be part of a Salesforce architecture, it is generally used for custom high-scale apps or data offloading. The standard "Connected B2C Solution" refers to the native integration between Service Cloud and B2C Commerce. Introducing Heroku as a core requirement for a "better interface" adds unnecessary complexity; the Service Console already provides the optimized interface needed for this use case.

D. Increases spend ROI as fewer service agents will be needed, which can allow for more sales agents.
Why it is incorrect: While a connected solution improves ROI through efficiency, it is a "trap" to assume the goal is to reduce the number of agents. In architectural theory, a connected solution is designed to scale support and improve the quality of service. While it could lead to headcount changes, the primary business value is improved customer experience and agent productivity, not necessarily a 1:1 replacement of service staff with sales staff.

References
Salesforce Architects: Functional Capabilities and Business Value — Outlines how unified data drives agent productivity.
Salesforce Help: B2C Commerce Integration with Service Cloud — Discusses the benefits of cross-cloud visibility for agents.
Salesforce Trailhead: B2C Solution Architect: Discovery and Customer Success — Covers identifying business value in multi-cloud transformations.

D.   Use the Apex callout to retrieve the latest information from the external system during the loan application process.

Explanation:

Why D is correct
When a company already has an external system of record for pricing and discount rules, Salesforce best practice is to reuse that system’s logic, not duplicate it.

Using an Apex callout allows Salesforce to:
- Invoke the external pricing/quotation API in real time during the loan application flow
- Always use the latest, authoritative pricing and discount rules
- Avoid data drift and maintenance risk from duplicated logic
- Support complex, conditional, or frequently changing pricing rules

This pattern is commonly used in financial services where pricing logic is regulated, complex, and centrally governed.

Why the other options are not recommended
A. Rebuild the logic using Apex
❌ Anti-pattern
- Duplicates business logic
- High maintenance and compliance risk
- Increases chances of inconsistent pricing between systems

B. Use Process Builder API callout component
❌ Not suitable
- Process Builder is deprecated in favor of Flow
- Limited error handling and control
- Not ideal for complex or high-reliability real-time integrations

C. Use an external object to store pricing and discount information
❌ Read-only and static use case
- External Objects are best for browsing data, not for executing dynamic pricing logic
- Does not handle real-time calculation or rule execution

Key exam takeaway
When Salesforce must consume complex, authoritative business logic from an external system in real time, the correct pattern is:
Apex callout to the external system’s API