Free Salesforce B2C Commerce Developer Practice Test Questions (2026)

Explanation:

Key Requirements:
The merchant wants only products assigned to the Storefront catalog (not all products in the Master catalog).
Some products in the Master catalog are not linked to the Storefront catalog.

Why Option C?
✅ Site Import & Export with Category Filtering
The Site Import and Export module allows exporting products filtered by their assignment to Storefront catalog categories.

Steps:
Navigate to Merchant Tools > Products & Catalogs > Site Import & Export.
Select the Master catalog but filter by Storefront catalog categories.
Export only products linked to those categories.
Result: The export file contains exclusively products visible on the Storefront.

Why Not Other Options?
❌ A. Catalog Import & Export (Master Catalog + Category Assignment Search)
This exports the entire Master catalog (including unassigned products) unless manually filtered, which is inefficient.

❌ B. Export Both Catalogs in a Single Archive
This would include all Master catalog products, defeating the purpose of filtering for Storefront-specific items.

Reference:
Salesforce Docs: Site Import & Export
Best Practice: Use Site Import & Export for storefront-specific product data.

Explanation:

Why This Answer Is Correct
The requirement is classic for an AJAX endpoint: a client-side JavaScript request expects structured data (JSON) in response, which it will use to update the page dynamically without a full refresh. The res.json() method in SFRA (inherited from Express.js) is specifically designed for this purpose. It sets the correct Content-Type header to application/json and sends a JSON response. The developer can pass a JavaScript object to res.json(), which will be automatically serialized. This is the standard, clean, and efficient method for API endpoints that serve data to client-side logic. It aligns perfectly with the goal of providing “updated information” in a machine-readable format for JavaScript to process.

Why the Other Options Are Incorrect

B. res.render()
res.render() is used to process an ISML template and send the resulting HTML to the client. It is the standard method for rendering full or partial page views. Using it for an AJAX endpoint would be inefficient and inappropriate, as it would return HTML markup instead of lightweight JSON data. The client-side AJAX handler would then need to parse the HTML to extract data, which is cumbersome and brittle.

C. res.print()
res.print() (or Response.print() in the legacy DWScript API) is a low-level method that writes a raw string to the response stream. It does not set the Content-Type header to application/json. To use it for JSON, a developer would have to manually call JSON.stringify() on an object and then set the content type header, which is more verbose and error-prone than using the dedicated res.json() helper. It is not the best practice in the SFRA context.

Reference
SFRA Controller API Reference: Response Wrapper — Documents the res.json() method as the preferred way to send JSON responses.
Express.js API Documentation: res.json() — Underpins the SFRA implementation.

Explanation:

The question describes a situation where a web service integration succeeds (the call completes without throwing an exception or returning an error status), but the response contains an unexpected outcome. This unexpected result has the potential to cause side effects such as inconsistent data, incorrect business logic execution, subtle bugs, or future problems, even though the current operation did not fail outright.
This is a classic example of a non-fatal but noteworthy anomaly that developers must flag for future investigation.

Salesforce B2C Commerce Logging Levels – Overview
SFCC uses a standard logging hierarchy (similar to Log4j and most enterprise Java systems). Each level has a precise semantic purpose:

DEBUG → Very detailed, low-level diagnostic information (usually disabled in production)
INFO → Normal, expected, successful events (business-as-usual logging)
WARN → Unexpected conditions that are not critical failures but deserve attention (potential risk or side effects)
ERROR → Actual failures, exceptions, or serious problems that prevent normal operation

Choosing the correct level is not just a best practice — it directly affects production monitoring, alert noise, and troubleshooting efficiency.

Why Logger.warn() Is the Correct Choice
Logger.warn() should be used when:

The operation completed successfully (no exception, HTTP 2xx response)
The result is unexpected or deviates from normal or anticipated behavior
There is a potential for side effects or future issues (for example, incomplete data, deprecated response format, unusual values that the code can still handle)
The system can continue safely, but someone should investigate later

Examples of real-world WARN scenarios in SFCC include:

Service returns 200 OK but is missing recommended fields
Response structure changed slightly (backward-compatible but unexpected)
Performance is slower than usual but still acceptable
Deprecated API version is being used

Logging at WARN ensures the message appears in production logs (where INFO, WARN, and ERROR are typically enabled) without generating critical alerts.

Why the Other Options Are Incorrect
A. Logger.info('Unexpected service response')
INFO is reserved for expected and normal successful operations. The word “unexpected” directly contradicts the meaning of INFO. Using INFO here would bury important anomalies in routine log noise.

B. Logger.debug('Unexpected service response')
Debug logs are almost always turned off in production environments to reduce log volume and storage costs. Important warnings would be invisible during real troubleshooting.

C. Logger.error('Unexpected service response')
ERROR signals a failure or critical problem that requires immediate attention. Using ERROR when the operation succeeded creates alert fatigue, misleads monitoring teams, and pollutes critical error dashboards.

Explanation:

Why This Answer Is Correct
Custom Objects are the standard way to extend the B2C Commerce data model for specific business logic. By creating a site-specific Custom Object, the developer ensures that the data is partitioned per site. Furthermore, Custom Objects are replicable, meaning data entered in the Staging instance can be pushed to Production via the standard Replication process. This directly matches the requirement that data used in staging also applies in production. Since the requirements include structured fields such as a Pricebook ID and a Flag Image URL for a country selector, a Custom Object provides a clean, type-safe schema to store and retrieve this information efficiently in code.

Why the Other Options Are Incorrect
A. Extend the Locale System Object
While the Locale system object exists, it is not designed to be flexibly extended with custom attributes like image URLs or custom pricebook mappings. System objects have limitations compared to Custom Objects and are not ideal for storing site-specific business configuration data.

C. Create Site-Specific Content Assets
Content assets are intended for managing HTML or text-based content. Although they can technically store JSON or configuration data, this approach is not type-safe and is considered a workaround rather than a best practice. Content assets are also harder to query and maintain when used for structured logic such as mapping countries to pricebook IDs, compared to querying Custom Objects programmatically.

References
Salesforce B2C Commerce – Custom Objects
Replication of Custom Objects

Explanation:

This question tests understanding of B2C Commerce locale-specific form customization using the site hierarchy.

Key Requirements
Modify the address form for the U.S. site.
Set the U.S. site locale (implied to be en_US).
Add or modify the field definition in the XML file.
The correct approach leverages the locale-based file resolution system in B2C Commerce.

How Form File Resolution Works
Forms are stored in forms/<locale>/. The system resolves the form file based on the current site's locale settings. The hierarchy typically is:
forms/<site_locale>/<form_name>.xml → forms/default/<form_name>.xml

Therefore, to customize the address.xml form specifically for the U.S. site (with locale en_US), you must:
Create the locale-specific folder: forms/en_US/.
Copy the base address.xml file from forms/default/ into this new folder.
Edit the copied file (forms/en_US/address.xml) to replace the province list with the U.S. states list.

This ensures that when the U.S. site (locale en_US) renders the address form, it automatically uses the customized version, while the Canadian site continues to use the default or an en_CA version.

Why the Other Options Are Incorrect
A. Create a copy of existing address.xml file in the default folder. Rename that file to adres_US.xml:
This is incorrect for multiple reasons. First, placing it in the default folder is not locale-specific. Second, renaming the file breaks the standard naming convention (address.xml). The system looks for a file named address.xml, not adres_US.xml.

B. Create a new sub-folder in the forms folder. Name it US. Copy existing address.xml file in the new folder:
The folder name must be a valid locale ID (like en_US, fr_CA, de_DE). US is not a valid locale ID. The system will not automatically resolve to this folder based on the site's locale setting.

C. Create a copy of existing address.xml file in the default folder. Rename that file to address_en_US.xml:
Similar to option A, this places the file in the wrong location (default folder) and uses an incorrect filename. The system expects the file to be named address.xml inside a locale-specific folder, not a locale-suffixed filename inside the default folder.

Key Concepts
Form Localization: B2C Commerce documentation describes how forms are resolved based on locale folders (forms/<locale>/) to support multi-region and multi-language sites.
Locale ID Standards: Locale IDs follow the pattern language_COUNTRY (for example, en_US, en_GB, fr_CA). This is what the site's locale is set to in Business Manager.
Site-Specific Customization: The correct method is non-destructive and upgrade-safe. You override only the specific form for the specific locale by placing a copy in the appropriate folder, leaving the base (default) form intact for other locales.

Summary
To customize a form for a specific locale (en_US), create a folder named after that locale inside forms/, copy the base XML file there, and modify the copy. This is the standard, documented best practice.

Explanation:

This question tests understanding of B2C Commerce's locale fallback logic for resource property files.

File Structure & Locale Analysis
account.properties – The default/base file (no locale suffix). Contains weight.unit=kilos.
account_en.properties – The file for the language English (en). Contains weight.unit=stones.
account_en_US.properties – The file for the specific locale English - United States (en_US). Contains weight.unit=pounds.

Current Site Locale: The user is visiting with locale en_CA (English - Canada).

Locale Resolution Hierarchy
B2C Commerce resolves resource messages using a specific-to-general fallback:
Exact locale match: account_en_CA.properties → NOT FOUND.
Language match: account_en.properties → FOUND! (en matches the language part of en_CA).
Default file: account.properties → This is only used if no language-specific file is found.

Since account_en.properties exists, the system will use the value from that file (weight.unit=stones). It does not fall back to the base account.properties because a valid language match (en) was found.

Template Execution
The line ${Resource.msg('weight.unit','account')} looks up the key weight.unit from the account bundle.
Following the resolution logic for en_CA, it retrieves the value stones from account_en.properties.

Therefore, the rendered text is: "Your parcel weighs 10 stones."

Why the Other Options Are Incorrect
B. Your parcel weighs 10 pounds ❌
This would be correct only if the locale was en_US, as it uses account_en_US.properties.

C. Your parcel weighs 10 undefined ❌
This would only happen if the key weight.unit was missing from all resolved property files (including the base default). It is found in account_en.properties.

D. Your parcel weighs 10 kilos ❌
This would be correct only if there were no account_en.properties file, forcing a fallback to the base account.properties. Since account_en.properties exists, it takes precedence for any en_* locale.

References:
Resource Bundle Localization Fallback: The system searches in this order for a given locale {language}_{country}:
bundle_{language}_{country}.properties
bundle_{language}.properties
bundle.properties

Locale-Specific Customization: This mechanism allows developers to provide translations/regional variations for different markets while maintaining a common base.
Resource.msg() Method: The method parameters are (key, bundleName, locale?). If no locale is specified, it uses the current request's locale.

Summary
For locale en_CA, the system resolves to the language-level file account_en.properties, returning "stones".

Explanation:

This question tests the understanding of Search Dictionaries and their correct application for search term precision.

The requirement is: Show only car accessories when shoppers use the search term "car accessories", and exclude technology accessories and household accessories.

Purpose of Each Dictionary Type
Common Phrase Dictionary: This is used to treat a specific multi-word phrase as a single, precise search term. When "Exact Match" mode is used, it ensures that results are returned only when the shopper enters that exact phrase. It does not add synonyms or variations.

Synonym Dictionary: This is used to expand a search term to include synonyms or related terms. For example, mapping "car" to "automobile, vehicle". This is the opposite of the requirement, as it would broaden, not narrow, the results.

Why Option D is Correct
Common Phrase Dictionary entry: "car accessories" tells the search engine to treat "car accessories" as one specific unit.
Search mode: Exact Match ensures that this dictionary entry only applies when the shopper types the phrase exactly as defined ("car accessories"). It will not trigger on "accessories for car" or "car and accessories".
Result: When a user searches for the exact phrase "car accessories", the search engine looks for products explicitly matching that phrase. Since "technology accessories" and "household accessories" are different phrases, they are naturally excluded. The dictionary does not need to contain "NOT" statements; its precise matching inherently provides the required filtering.

Why the Other Options Are Incorrect
A & C: Create a Synonym Dictionary entry... ❌
A synonym dictionary would add "household" and "technology" as alternative search terms when someone searches for "car accessories". This would cause the search to return household and technology accessories, which is the exact opposite of the requirement.

B: Create a Common Phrase Dictionary entry: car accessories, NOT household, NOT technology ❌
This syntax is invalid. Common Phrase entries do not support Boolean operators (NOT, AND, OR) within the phrase definition. Boolean logic is handled at the query level, not in the search dictionary. The dictionary's job is to define the phrase, not to apply query logic.

Key References & Concepts
Search Dictionaries Documentation:
- Common Phrase: Used for precise phrase matching (e.g., brand names, specific product lines). "Exact Match" mode is for precision.
- Synonym: Used for broadening searches by linking related terms.

Exact Match vs. First Word Mode: "Exact Match" requires the entire phrase. "First Word" mode would apply the rule if the phrase starts with the defined words, which could cause unintended matches.

Achieving Precision: To restrict results to a very specific category, you use a Common Phrase Dictionary with Exact Match. This ensures the search is interpreted literally, not expanded.

Summary
To guarantee that the search term "car accessories" returns results for only that category and excludes others, define it as a Common Phrase with Exact Match. This uses the search dictionary for its intended purpose: precise phrase recognition, not Boolean filtering.

Explanation:

The requirement calls for distinguishing between single-brand and multi-brand stores in the store locator for styling purposes. The most efficient and architecturally sound approach is to extend the existing Store system object with a custom attribute. B2C Commerce allows developers to add custom attributes to system objects like Store through Business Manager. By creating a Boolean custom attribute (e.g., isSingleBrand), merchants can flag each store accordingly. This attribute then becomes available in the store data model, enabling the front-end developer to access it via the Store API and apply conditional CSS classes or inline styles in the store locator ISML template. For instance, in the template, one could write:

This method leverages the platform's built-in extensibility without creating redundant data structures. The custom attribute is manageable through Business Manager's "Merchant Tools > Custom Objects" section under Store system object type, allowing business users to toggle the flag per store without developer intervention after initial setup.

Why Other Options Are Incorrect
B. Configure the existing Store custom object type definition – This is misleading because "Store" is a system object, not a custom object type. Custom object type definitions apply to entirely custom data structures, not to extending core platform entities. Modifying system object definitions through custom objects isn't supported for this purpose.

C. Create a new SingleBrandStore custom object configuration – Creating a separate custom object for stores would fragment store data management, requiring duplicate data entry and complex synchronization with the actual Store system objects. It violates data normalization principles and would necessitate complex middleware to link custom object records with actual store entities, increasing maintenance overhead.

D. Adjust the relevant Site Preference in the Stores group – Site Preferences are for global configuration settings, not per-store characteristics. While a preference could control overall behavior, it cannot store individual store distinctions. Using preferences would require hardcoding store IDs or maintaining external lists, which is inefficient and not scalable.

References
Salesforce B2C Commerce Developer Documentation: "Extending System Objects with Custom Attributes"
Business Manager User Guide: "Managing Store Data"
B2C Commerce API Reference: dw.catalog.Store and StoreMgr classes
Best Practices: "Data Modeling in B2C Commerce" – using custom attributes vs. custom objects

Explanation:

Why B is correct
Page Designer layout components in SFCC allow fine-grained control over which component types (assets) can be dropped inside them. This is configured directly in the layout component's JSON configuration file (e.g., my-layout.json). The key component_type_exclusions is an array of component type IDs that are explicitly forbidden from being added to this layout. This is the official, recommended way to restrict content types inside specific layouts (introduced and documented since SFRA 3+ / Page Designer 2.x).

Why the other options are incorrect
A. Add component_type_inclusion in the layout json configuration
There is no key called component_type_inclusion in layout configuration. Inclusion is the default behavior — you exclude what you don’t want.

C. Add layout_type_inclusion in the target components json configurations
Components do not control which layouts they can go into. The control direction is layout → allowed/excluded components, not the other way around.

D. Add layout_type_exclusion in the other asset components json configuration
Same conceptual error as C. Asset components should not define layout restrictions — that responsibility belongs to the layout.

References
Salesforce Commerce Cloud Documentation → Page Designer → Component Configuration Schema
Developer Guide: "Restricting Component Usage in Layouts" section

Explanation:

Creating and persisting a custom object in Salesforce B2C Commerce requires using the dw.object.CustomObjectMgr API. The method createCustomObject(type, key) is the standard way to instantiate a new custom object. Let’s break this down carefully:

Custom Object Type: This is the identifier of the custom object definition created in Business Manager. In this case, the type is "NewsletterSubscription".

Key Value: Every custom object requires a unique key. For the NewsletterSubscription object, the key attribute is email (of type String). When creating the object, you pass the actual value of the email field from the form, e.g., newsLetterForm.email.value.

Thus, the correct syntax is:
var customobject = dw.object.CustomObjectMgr.createCustomObject('NewsletterSubscription', newsLetterForm.email.value);

This ensures the object is created and persisted in the database with the email as its unique key.

Why Option C is Correct
- It uses the correct method: createCustomObject(type, key).
- It passes the type first ('NewsletterSubscription') and then the key value (newsLetterForm.email.value).
- This matches the documented API signature and ensures proper persistence.

Why the Other Options Are Incorrect
A. createNewsletterSubscription('email', newsLetterForm.email.value')
There is no such method as createNewsletterSubscription. The API only provides createCustomObject.

B. createCustomObject(newsletterForm.email.value, 'NewsletterSubscription')
The arguments are reversed. The first argument must be the type (NewsletterSubscription), not the key.

D. createCustomObject('NewsletterSubscription','email', newsLetterForm.email.value')
The method only accepts two arguments (type and key). Adding a third argument is invalid and will throw an error.

Reference
Salesforce B2C Commerce Developer Documentation – Custom Objects:
“Use dw.object.CustomObjectMgr.createCustomObject(type, key) to create and persist a custom object. The first parameter is the custom object type ID, and the second is the unique key value.”
Salesforce Developer Guide on Custom Objects