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

Explanation:

In SiteGenesis JavaScript Controllers (SGJC), the guard.js module is used to secure controller endpoints by applying specific filters before the main function (action) is executed.

guard.ensure(filters, action): This is the standard method for combining multiple security requirements.
'https': This filter ensures the request is made over a secure HTTPS protocol. If a user attempts to access the URL via HTTP, the guard will automatically redirect them to the HTTPS version.
'post': This restricts the endpoint to only accept HTTP POST requests, which is a security best practice for forms and sensitive data submission.
'loggedIn': This ensures that only authenticated customers can access the logic, which is typical for a payment form.
The Array Syntax: Filters must be passed as an array of strings in the first argument of the ensure method.

Why Other Options Are Incorrect

A: This uses the 'http' filter, which allows insecure connections. The requirement specifically asks for the HTTPS protocol.

B: The guard.expose() method simply marks a function as publicly accessible via a URL but does not enforce any security protocols like HTTPS or specific request methods.

C: While guard.httpsPost() technically exists as a helper in some versions of guard.js, it is deprecated in favor of the more flexible ensure method. Additionally, it would only satisfy HTTPS and POST requirements, missing the loggedIn check often required for payment forms.

Explanation:

Why A is Correct:
To enable filtering by intended activity (e.g., tennis, jogging), the developer must first create a custom product attribute (e.g., activityType) to store this data. Then, they must configure a Search Refinement Definition in Business Manager to expose this attribute as a filter in the storefront. This approach aligns with Salesforce B2C Commerce’s search refinement architecture, which allows filtering by product attributes.

Why B and C are Incorrect:
B refers to a "ProductRefinement" attribute, which is not a valid object type in B2C Commerce. Refinements are configured via definitions, not special attribute types.
C suggests adding a new viewtype, which controls how categories are rendered but does not enable filtering.

References:
Salesforce Help: Search Refinement

Explanation:

In B2C Commerce (SFCC) ISML templating, the correct method to render one template from within another is ISML.renderTemplate(). The path provided to this method is relative to the templates folder of a cartridge.

Let's break down the file path:
- The full path shown is: cartridge/templates/default/content/custom/customLandingPage.isml
- The ISML.renderTemplate() method expects the path starting from templates/default/ (or templates/<specific_folder>/).
- Therefore, the correct relative path is: content/custom/customLandingPage (note the .isml extension is omitted).
- This matches option D precisely.

Why the other options are incorrect:
A. ISML.renderTamplate('cartridge/templates/default/content/custom/customLandingPage'); This is incorrect for two reasons:
- Typo: The method name is misspelled (renderTamplate instead of renderTemplate).
- Incorrect Path: It includes the full path starting from cartridge. The renderTemplate method expects a path relative to the templates directory.

B. ISML('content/custom/customLandingPage'); This is incorrect syntax. ISML is not a callable function by itself for rendering templates. The proper method must be used.

C. ISML.render('content/custom/customLandingPage'); This is incorrect. There is no standard ISML.render() method in the ISML API. The correct method name is renderTemplate.

References:
- ISML API Documentation: The official documentation specifies ISML.renderTemplate(templatePath, templateVariables) as the method for rendering an ISML template.
- Template Path Resolution: Paths are resolved relative to the templates directory within a cartridge. The default folder (or other locale-specific folders) is implied in the path structure.
- Cartridge Pathing: Understanding the standard cartridge directory structure (cartridge/script, cartridge/templates, cartridge/static, etc.) is fundamental for correct file referencing.

In short:
The correct, documented method is ISML.renderTemplate() with a path relative to the templates folder.

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:

The Session scope is the most appropriate because it persists throughout the user's entire "shopping experience" (from the moment they land on the site until the session expires or the browser is closed). Data stored in session.custom is available across different pages, pipelines, and controllers without needing to be saved to a database object like a Profile or Order.

Incorrect Answers:
A. Request scope variable: This variable only lasts for a single HTTP request-response cycle. As soon as the user clicks a link to another page or refreshes, the data is lost.

B. Page scope variable: This is even more limited than the Request scope; it exists only during the rendering of a specific ISML page. It cannot carry data between different pages in a shopping journey.

D. Content slot variable: Content slots are used for displaying marketing or product information based on configurations in Business Manager. They are not data storage mechanisms for capturing and persisting user input.

Reference:
Salesforce Help: B2C Commerce Scripting Variables
Infocenter: Session Variable Persistence

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:

In Salesforce B2C Commerce, when you're creating or modifying persistent objects — such as Custom Objects, Orders, or Customer Profiles — you must wrap the operation in a Transaction.wrap() block. This ensures atomicity, rollback on error, and complies with platform requirements.

Your current code attempts to create and modify a CustomObject, but it does not wrap the logic in a transaction, which is required for persistence operations.

✅ Corrected Code Snippet:
var Transaction = require('dw/system/Transaction');

if (newsletterForm.valid) {
try {
Transaction.wrap(function () {
var customObject = CustomObjectMgr.createCustomObject(
'NewsletterSubscription',
newsletterForm.email.value
);
customObject.custom.firstName = newsletterForm.fname.value;
customObject.custom.lastName = newsletterForm.lname.value;
});
} catch (e) {
// Handle error here
}
}

❌ Why Other Options Are Incorrect:

A. Custom Objects can only be created by Job scripts
➤ False. You can create them in storefront code, controllers, or jobs — as long as you use a transaction.

B. Missing server.middleware.httpt
➤ Not required for this route unless you are doing authentication or HTTPS checks. The middleware is optional, not the cause of failure.

C. The CustomObjectMgr variable should be declared outside the route
➤ Scope placement is fine. Declaring inside or outside the route doesn't cause runtime failure.

Explanation:

In Salesforce B2C Commerce (SFCC), the option “Show Orderable Products Only” found in:
Business Manager → Merchant Tools → Search → Search Preferences
...controls whether search results will exclude products that cannot currently be ordered, based on inventory (ATS) and orderability status.

Specifically:

If ATS (Available To Sell) = 0, and
The product is not orderable due to inventory rules,
Then the product will be excluded from search results.

💡 This helps prevent customers from seeing out-of-stock products in search results, improving the buying experience and reducing frustration.

✅ This supports the business goal of:
Filtering out products from search results that cannot be purchased right now.

❌ Why Other Options Are Incorrect:

B. Exclude back-ordered products from showing on the website
➤ Not necessarily. Back-orderable products can still appear if they are orderable by configuration.

C. Block displaying the product detail page if ATS = 0
➤ This setting affects search results, not whether a product detail page (PDP) can be accessed.

D. Exclude pre-order products from search results
➤ Pre-order products may still be shown if configured as orderable. This setting doesn’t explicitly exclude them.