Free Salesforce-B2C-Commerce-Cloud-Developer Practice Test Questions (2026)

Explanation:

When using the B2C Commerce Service Framework, different service types (HTTP, FTP, SOAP) require different setup steps.

For SOAP (Web Services), the platform must instantiate a specific "Service Client" based on the WSDL (Web Service Description Language) file provided. The initServiceClient callback is unique to SOAP integrations. Its purpose is to allow the developer to initialize the dw.ws.WebReference or the specific SOAP client object before any requests are made. HTTP services do not use this because they work with generic HTTP clients that do not require a pre-compiled contract/WSDL.

Why the Incorrect Answers are Wrong

B. createRequest: This is required for all service types to define the payload being sent.
C. mockCall: This is optional for all service types to provide testing data.
D. parseResponse: This is required for all service types to convert the raw response (XML, JSON, etc.) into a usable JavaScript object.

Reference
dw.svc.ServiceCallback API Reference
Infocenter: SOAP Services

Explanation:

In Salesforce B2C Commerce, personalizing content based on whether a customer is logged in or browsing as a guest is a very common business requirement. The platform provides built-in, declarative mechanisms to handle this scenario efficiently, without requiring custom code or complex logic. Understanding which tool is designed for this purpose is essential for both real-world development and the Salesforce Certified B2C Commerce Cloud Developer (Comm-Dev-101) exam.

The key concepts involved in this question are:
- Content Slots
- Customer Groups (Registered vs. Unregistered)
- Content targeting in Business Manager

✅ Why Answer B Is Correct
Set the Content Slot configuration so it is based on the system customer group registered, versus unregistered.

Content Slots in Salesforce B2C Commerce are specifically designed to deliver dynamic, targeted content based on conditions such as:
- Customer groups
- Time schedules
- Campaigns
- Source codes

Salesforce provides system-defined customer groups, including:
- Registered (logged-in customers)
- Unregistered (guest users)

By configuring a Content Slot to target these system customer groups, a developer or merchant can:
- Show one content asset to logged-in users
- Show a different content asset to guest users
- Manage everything directly in Business Manager
- Avoid writing custom code
- Maintain upgrade safety and best practices

This approach is:
- Fully supported by Salesforce
- Easy for merchants to manage
- Optimized for performance and caching
- The recommended solution for conditional content rendering

Therefore, option B is the correct answer.

❌ Why the Other Options Are Incorrect

❌ A. Write specific custom code in the Content Asset for a customer that is a registered, versus unregistered, user
Content Assets are primarily intended to store content, not complex logic. While ISML expressions can be used, embedding conditional logic based on login status:
- Violates separation of concerns
- Makes content harder for merchants to manage
- Is not the recommended Salesforce approach

Salesforce strongly encourages configuration over customization, making this option incorrect.

❌ C. Set the Content Asset configuration for a customer that is a registered, versus unregistered, user
Content Assets do not support customer-group-based targeting by themselves. They are static content objects. Targeting logic must be applied at the Content Slot level, not at the Content Asset level.

Because Content Assets cannot independently determine whether a user is registered or unregistered, this option is incorrect.

❌ D. Add specific custom messages in Page Designer for a customer that is a registered, versus unregistered, user
Page Designer is used for:
- Building page layouts
- Creating reusable components
- Managing visual structure

While Page Designer can support personalization through advanced configuration, it is not the correct or simplest tool for basic login-based content targeting. Using Page Designer for this requirement would:
- Add unnecessary complexity
- Reduce maintainability
- Over-engineer a simple personalization use case

Salesforce expects developers to use Content Slots for this scenario.

Key Exam Insight
For Comm-Dev-101 questions, remember this rule of thumb:

If the requirement is “show different content based on customer type,” the answer is almost always Content Slots + Customer Groups.

Salesforce exam questions often try to trick candidates into choosing:
- Custom code
- Page Designer
- Content Asset logic

But the correct answer favors declarative Business Manager configuration whenever possible.

References
Salesforce B2C Commerce Documentation – Content Slots
Salesforce B2C Commerce Documentation – Customer Groups

Explanation:

In Business Manager, "CREDIT_CARD" is typically defined as a single Payment Method. However, within that method, you must specify which individual card brands (types) are accepted. If the merchant already has a credit card payment method set up, the developer does not need to create a new processor or preference; they simply need to navigate to the settings of the existing Credit Card method and ensure "Amex" or "American Express" is added to the list of Card Types and set to "Enabled."

Why Answer A is Correct: Credit Card Type Mapping
In B2C Commerce, the relationship between payments is hierarchical:
- Payment Method: The broad category (e.g., Credit Card, PayPal).
- Payment Card: The specific brand (e.g., Visa, Mastercard, American Express).

When a shopper enters their card number on the storefront, the system uses "Luhn" validation and bin-range checking to identify the card type. If American Express is not explicitly enabled in the Payment Methods module under the Credit Card details, the system will reject the card as "invalid" or "unsupported," even if the merchant's actual bank/processor is capable of handling the transaction. Enabling it here allows the platform to recognize the card and pass the data to the associated payment processor.

Why the Incorrect Answers are Wrong
B. Add American Express into the Order settings in Site Preferences: Site Preferences contain general settings for the storefront (like order prefixing or stock thresholds), but they do not control the specific financial attributes or brand acceptance of payment methods.

C. In Payment Processor, create American Express as a payment type: A Payment Processor (e.g., CyberSource, Adyen, Stripe) is the technical link between the site and the bank. You typically have one processor for all credit cards. You do not create individual processors for each card brand; instead, you configure the "Credit Card" method to point to a single processor that handles all brands.

D. Add American Express as a Payment Preference in Site Preferences: This is a distractor. While there are "Site Preferences," there is no specific "Payment Preference" module used to enable individual credit card brands. All brand-level configuration happens within the Merchant Tools > Ordering > Payment Methods module.

Implementation Workflow for Developers
To complete this requirement, a developer or administrator follows these steps:

1. Navigate: Go to Merchant Tools > Ordering > Payment Methods.
2. Select Method: Click on the method with ID CREDIT_CARD.
3. Card Types: Scroll to the "Card Types" section.
4. Enable: Find "Amex" or "American Express" in the list. Check the box for "Enabled."
5. Verify: Ensure the "Payment Processor" assigned to the Credit Card method is configured on the backend to accept Amex (this is done through the third-party gateway portal, not just Business Manager).

Reference
Salesforce B2C Commerce Help: Managing Payment Cards
Infocenter: Payment Methods and Card Types

Explanation:

In Salesforce B2C Commerce, localization and internationalization (i18n) are handled through resource bundles, which are implemented as .properties files. These files contain key–value pairs used to translate text displayed on the Storefront into different languages and locales.

This question asks where the developer should store .properties files for a newly added French (fr) locale, which is a very common exam topic for the Salesforce Certified B2C Commerce Cloud Developer (Comm-Dev-101) exam.

To answer correctly, it’s important to understand:
How B2C Commerce loads message resources
The required directory structure
The separation between templates and resources

✅ Why Answer C Is Correct
cartridge/resources
Salesforce B2C Commerce expects all localization .properties files to be stored in the resources directory at the root of a cartridge.

Correct Structure Example
cartridge/
├── controllers/
├── models/
├── scripts/
├── templates/
└── resources/
├── messages.properties
├── messages_fr.properties
├── checkout.properties
└── checkout_fr.properties

Key points:
The resources folder is the only valid location for message bundles
Locale-specific translations are handled by file naming, not subfolders
For French, the file name ends with _fr.properties
Salesforce automatically resolves the correct file based on the site’s locale

This design allows:
Centralized localization management
Reuse of translations across templates and controllers
Automatic fallback to default language when a translation is missing

Because Salesforce only scans cartridge/resources for message bundles, option C is correct.

❌ Why the Other Options Are Incorrect
❌ A. cartridge/templates/fr
This option is incorrect because:
The templates directory is used only for ISML templates
Localization is not directory-based
Salesforce does not load .properties files from locale-specific folders
Translations are resolved by file naming conventions, not folder structure.

❌ B. cartridge/templates/resources
This is incorrect because:
Resource bundles must be at the cartridge root level
Salesforce does not scan nested resources folders inside templates
Mixing templates and resources breaks platform conventions

❌ D. cartridge/templates/resources/f
This option is incorrect for multiple reasons:
Invalid folder structure
Incorrect locale handling (f instead of fr)
Unsupported path for message bundles
Salesforce will completely ignore .properties files placed here.

Key Exam Insight
For Comm-Dev-101, remember this rule exactly:
All localization .properties files must be placed in cartridge/resources, and locales are defined by the file name, not by folders.

If you see:
messages_fr.properties
checkout_fr.properties
They always live in:
👉 cartridge/resources

References
Salesforce B2C Commerce Documentation – Localization and Internationalization
Salesforce B2C Commerce Developer Guide – Resource Bundles
Salesforce ISML and Localization Best Practices
Salesforce B2C Commerce API Reference – Resource Handling

Explanation:

✅ Why B is Correct
Salesforce B2C Commerce shipping methods are configured in Business Manager with qualifiers and exclusions. The best practice is to handle promotional exceptions through configuration, not custom code.

In this scenario:
The existing shipping method "Free Standard Ground Shipping" excludes all televisions under the electronics-televisions category.

Marketing wants to override this exclusion for a specific brand (XyzTv) for a limited time.

The correct approach is to add an exception (allow list) to the exclusion rules of the shipping method. This way, televisions from brand XyzTv bypass the category exclusion and qualify for free shipping.

This solution is:
Configurable — no code changes required, handled in Business Manager.
Maintainable — easy to remove after the 3-month promotion ends.
Best practice — leverages built-in shipping method qualifiers/exclusions instead of custom logic.

❌ Why the Other Options Are Incorrect
A. Create a new shipping method and label it "Free Standard Ground Shipping". Give it the qualifier 'brand equals XyzTv', and add it to the checkout options.
This duplicates the shipping method unnecessarily. Multiple methods with the same label confuse customers and complicate maintenance. Promotions should be handled via qualifiers/exclusions, not duplicate methods.

C. Extend the CheckoutShippingServices controller using module.superModule and add an exception for the specified brand.
This introduces custom code into checkout logic, which is not recommended for shipping method configuration. It increases complexity, reduces maintainability, and violates best practices.

D. Extend the code in cartridge/models/shipping/shippingMethod.js using module.superModule and add an exception for the specified brand.
Similar to option C, this hardcodes business rules into the model layer. Shipping rules should remain configurable in Business Manager, not embedded in code. This approach makes future promotions harder to manage.

📚 References
Salesforce B2C Commerce Documentation – Shipping Methods and Qualifiers
Salesforce Trailhead: Configure Shipping Methods in Business Manager

Explanation:

To meet the requirement of tracking customer interest in out-of-stock products and sending notifications when they’re back in stock, the best approach is to use a custom object. This allows you to:

Store SKUs of out-of-stock products the customer is interested in
Store the customer’s email address, whether they are registered or a guest
Query and trigger notifications when inventory is replenished

✅ Why use a custom object?
Flexible schema: You can define attributes like skuList, email, timestamp, status, etc.
Site-independent or site-specific: Can be scoped globally or per site
Easily queried: For batch jobs or real-time triggers
Avoids polluting system objects like Profile or Product

❌ Why the other options are incorrect

A. Add to Profile object Not suitable for guest users, and misuses the Profile object for transactional data.
B. Create a new system object type You cannot create new system object types — only custom object types.
D. Add emails to Product object This violates data separation principles and doesn’t scale well. Products should not store customer-specific data.

📘 References:
Salesforce Help – Send Back-in-Stock Notifications
Salesforce Developer Docs – Use Custom Object Definitions
Back-in-Stock Notification Workflow

Explanation:

What is CSRF in B2C Commerce?
Cross Site Request Forgery (CSRF) protection is enabled by default in B2C Commerce to prevent malicious users from submitting unauthorized requests on behalf of a legitimate user.

To avoid CSRF errors:
A CSRF token must be included in any form submission or AJAX request.
The CSRF token must be generated and embedded correctly on the page.

✅ Why A is Correct
"Add the token in the ISML template"
CSRF tokens must be rendered inside forms.
The ISML tag ${csrf.token} is required in the form for server-side CSRF validation.

Example:
< form action = " $ { URLUtils. https('Account- Login' )} " method = " post ">
< input type = " hidden " name= " $ { csrf. tokenName} " value = " ${ csrf. token } " >
< / form >

✅ Why D is Correct
"Add csrfProtection.generateToken as a middleware step in the controller"
The CSRF token is only generated and added to the view when this middleware is called.
Without this, the ISML will not have a valid token to embed.
Example:
server.get('Login', csrfProtection.generateToken, function (req, res, next) {
res.render('account/login', {
csrf: {
tokenName: 'csrf_token',
token: req.csrfToken
}
});
return next();
});

❌ Why B is Wrong:
"Extend the CSRF token validity to avoid timeouts"
While token expiration could be a problem, extending validity is not a solution unless you are 100% sure it’s timing out.
In most CSRF issues, the real problem is missing or mismatched tokens, not timeouts.

❌ Why C is Wrong:
"Delete the existing CSRF whitelists in Business Manager"
This is risky and irrelevant. Whitelisting disables CSRF checks for specified endpoints — deleting the whitelist could cause more CSRF errors, not fewer.
It’s not a solution to the problem of tokens missing in requests.

📚 References:
Salesforce B2C Commerce CSRF Protection Guide
Salesforce ISML Form Example

Explanation

This question targets search relevance and merchandising controls in Salesforce B2C Commerce, specifically how to prevent low-stock or nearly unavailable products from appearing at the top of search results. The key clues in the requirement are:

Customers are seeing low stock items at the top of search results
This is hurting customer experience and conversion
The solution should improve the search and navigation journey

In B2C Commerce, this is not a data cleanup problem and not a catalog-hiding problem. It is a search ranking problem, and Salesforce provides a built-in, configurable solution for exactly this scenario.

✅ Why Answer C Is Correct
Set an availability low ranking threshold in Search Preferences

Salesforce B2C Commerce includes Search Preferences that directly influence how products are ranked in search results. One of the most important (and often tested) settings is the availability ranking threshold.

What the Availability Low Ranking Threshold Does
It reduces the ranking score of products that fall below a defined availability level
Products with low ATS (Available-To-Sell) are automatically pushed lower in search results
Products are not hidden—they are simply deprioritized

This preserves discoverability while improving conversion

This approach:
Keeps popular, in-stock items at the top
Prevents customer frustration from clicking low-availability products
Does not require code changes
Does not require jobs or manual catalog manipulation
Is fully merchant-configurable in Business Manager

Because the problem is ranking, not visibility, the availability low ranking threshold is the best-practice and intended solution, making option C the correct answer.

❌ Why the Other Options Are Incorrect

A. Select “Show Orderable Products Only” at the root level
This option hides out-of-stock products entirely, which is often not desirable:
Customers may still want to browse unavailable products
It can break SEO and landing pages
It does not address low stock, only no stock

The problem is not that products are unavailable—it’s that low-stock products are ranked too high. This option is too aggressive and does not match the requirement.

B. Enter a higher boost factor for availability in Searchable Attributes
Boost factors in Searchable Attributes influence text relevance, not inventory-based ranking.

Availability is handled by:
Search Preferences
Inventory-aware ranking logic

Boosting availability here would not reliably solve the problem and misunderstands how Salesforce search ranking works.

D. Create a job that hides unavailable products hourly
This is poor practice and introduces multiple risks:
Hiding products dynamically can cause catalog instability
It impacts SEO and customer trust
Jobs add operational overhead

This treats a ranking issue as a catalog maintenance issue

Salesforce explicitly provides ranking controls to avoid this type of workaround.

Key Exam Insight
For the Salesforce Certified B2C Commerce Cloud Developer (Comm-Dev-101) exam, remember this rule:
If the problem is about search order or ranking, the solution is almost always in Search Preferences—not code, jobs, or catalog hiding.

Salesforce exam questions strongly favor:
Declarative configuration
Search relevance tuning
Merchant-manageable solutions

References
Salesforce B2C Commerce Documentation – Search Preferences
Salesforce Business Manager User Guide – Search and Ranking

Explanation:

This requirement has two critical dimensions:

Product-Specific Data: The certification is tied to individual products (smartphone, hairdryer).
Site-Specific Values: The correct certificate (A, B, C, D) depends on the site (US vs. Europe) from which the product is viewed.
The solution must map a product to its correct certificate per site. A Site-specific custom attribute on the Product system object type is designed precisely for this.
A developer would create a custom attribute (e.g., certificationLogo) on the Product type.
When setting the attribute's Scope, they would select "Site Specific". This creates a separate value field for this attribute for each site in the instance.

In Business Manager, the merchant can then edit the product in the US site catalog and set certificationLogo to "A", and edit the same product in the European site catalog and set certificationLogo to "B".

In the product.isml template, the code would simply reference ${{product.custom.certificationLogo}}. The platform automatically resolves this to the value specific to the current site's context.

References:
Attribute Scopes: System object attributes can be Global (one value for all sites) or Site-specific (independent values per site).
Site-Specific Catalog Data: When a product is shared across sites via a master catalog, site-specific attributes allow for localized variations of product data.
Implementation: The attribute is configured in Business Manager > Administration > Site Development > System Object Types > Product > Attribute Definitions.

Why Other Options Are Incorrect:

A. Add a Localizable custom attribute to the Certificate system object type.
This is architecturally wrong. It implies creating a separate "Certificate" object type and establishing a relationship. This is overly complex for a simple logo display. More importantly, "Localizable" refers to translating text for different languages, not assigning different values based on site. The core requirement is per-site values, not translations.

B. Add an Image custom preference to the SitePreference system object type.
Site Preferences are for global site configuration (e.g., contact email, default page size). They are not suited for storing data that varies per product. You cannot have a single site preference that holds different certification logos for thousands of individual products.

D. Add a Localizable custom preference to the SitePreference system object type.
This compounds the errors of B and A. Site Preferences are not product-aware, and "Localizable" again addresses language translation, not the site-specific product data requirement.

Key Distinction:
The requirement is for product metadata that varies by site, which is the textbook use case for a site-specific product attribute.

Explanation:

In the SFRA middleware architecture, the server.append method is specifically designed to add new logic to the end of an existing middleware chain without overwriting the base code.

Preserving Base Logic: Using append ensures that the original middleware (e.g., in app_storefront_base) executes fully. This maintains the core functionality while allowing your custom cartridge to add or modify data.
Modifying viewData: It is the standard way to retrieve the existing viewData object via res.getViewData(), inject new properties, and then update it with res.setViewData(data) before the template renders.
Upgrade Compatibility: This approach adheres to the modular nature of SFRA. It allows for easier platform upgrades because the base cartridges remain untouched, and custom logic is isolated in an overlay cartridge.

Why Other Options are Incorrect

A. Replace the callback function:
Replacing a route is a "heavy" operation. It should only be done if the original logic must be completely discarded. For simply adding data, replacing the route creates technical debt as you must now maintain a copy of the original logic, which won't receive automatic platform updates.
B. Use the "extend" method:
While server.extend is used to inherit functionality from a superModule controller, it is not the method used to add a step to a specific route's execution chain. extend brings in the routes, but append, prepend, or replace are used to actually modify them.
C. Copy the existing route:
This is a direct violation of SFRA best practices. Copy-pasting code leads to "code rot" and makes the site extremely difficult to upgrade, as security patches or feature improvements in the base cartridge will not be reflected in your copied version.

References
Customize SFRA Controllers and Routes | Infocenter
SFRA Features and Components - Salesforce Developers
Customize SFRA | Storefront Reference Architecture (SFRA)