Salesforce-B2C-Commerce-Cloud-Developer Practice Test Questions

Explanation:

In Salesforce B2C Commerce SFRA (Storefront Reference Architecture), there are two primary ways to pass data from a controller to a template view:

✅ B. res.setViewData() + res.render()

This method attaches data to the res object using setViewData().

The data can then be accessed in the ISML templates using pdict.data.

Example:
res. setViewData ({ data: myDataObject });
res.render('content/myPage');


✅ C. res.render() with direct data injection

You can pass the data inline when calling res.render().
This will also make the data available in the template as part of pdict.

❌ Why not the others?

🔴 A. res.viewData = {} is incorrect
res.viewData is not a valid method or property in SFRA.
setViewData() must be used instead.

🔴 D. Syntax is invalid
append{(...)}; is not a valid JavaScript or SFRA syntax.
Additionally, Data: myDataObject is malformed—it doesn't attach any usable data to the response.

Explanation:

When building the SFRA (Storefront Reference Architecture) code for the first time in a Salesforce B2C Commerce developer sandbox, you must compile all client-side assets to ensure the storefront functions correctly. This includes:

JavaScript (compile:js) – bundles and transpiles client-side scripts
SCSS (compile:scss) – compiles stylesheets into CSS
Fonts (compile:fonts) – copies font assets used in the storefront

These steps are defined in the package.json file and executed using the sgmf-scripts tool.

🔧 Recommended Build Commands
npm run compile:js
npm run compile:scss
npm run compile:fonts

You typically run these from the root of the storefront-reference-architecture directory.

Explanation:

When integrating with a REST API that expects parameters to be form-encoded, the appropriate service type to register in Salesforce B2C Commerce (SFCC) is:

HTML Form – This service type sends parameters using the application/x-www-form-urlencoded format, which is standard for many REST services expecting form data (like web forms).

This type is ideal when the remote system is expecting key-value pairs encoded in the body, like: city=Chicago&time=now

It uses the HTTP POST method under the hood but differs from a raw JSON payload or multipart formats.

❌ Why not the others?

B. SOAP Form – Used for SOAP-based XML APIs, not REST.

C. POST Form – Not a valid service type in SFCC.

D. HTTP Form – Not a supported or defined service type in Business Manager.

Explanation:

When deciding between a content slot and a Page Designer (PD) component to make a section editable in Business Manager, the key factor is:

Page Designer Components Support Localization

Page Designer (PD) Components:

Can be localized for different languages (via locale-specific content assignments).

Example: A banner text can be edited in English, French, etc., directly in Business Manager.

Content Slots:

Typically not natively localizable. Content variations require manual handling (e.g., separate slots or custom logic).

Why Option A is Correct?
If the merchant needs to edit and translate content independently, PD components are the better choice.

Why Not Other Options?

B/D (Content Slots & Campaigns):
Both content slots and PD components can be tied to campaigns.
Localization is the differentiator, not campaign association.

C (PD Components & Campaigns):
Misleading. Campaigns work with both.

Additional Considerations:

Complexity: PD components require structured content types, while slots are simpler for static content.

Flexibility: PD components allow drag-and-drop layouts; slots are fixed to predefined regions.

Explanation:

Salesforce B2C Commerce uses JavaScript server-side scripting (Rhino/Script API) and provides the dw.system.Logger module for logging.
The correct way to insert dynamic values into a log message is by using placeholders like {0}, {1}, etc., and supplying the values as arguments.

So, this format works correctly:
Logger.warn('The current producto is {0} with name {1}', myProduct.getID(), myProduct.getName());
The {0} and {1} are placeholders that are replaced in order by the subsequent arguments.

❌ Why not the others?

B. Logger.warn(…), context(…)
❌ context is not a valid method in B2C Commerce script logging.

C. Uses template literals (${})
❌ This is client-side JavaScript syntax, not supported by the B2C Commerce Server Script API's Logger.

D. Uses %s placeholders with context(...)
❌ This is more of a Java-style or C-style syntax, and again context() is not a valid usage in this environment.

Explanation:

To make a Business Manager extension visible and functional, you must:

✅ A. Add the cartridge to the Business Manager site path
Navigate to: Administration > Sites > Manage Sites > Business Manager Site

Add plugin_bm_extension to the Effective Cartridge Path

This ensures the server loads the bm_extensions.xml file and registers the extension

✅ D. Activate the correct code version
Go to: Administration > Site Development > Code Deployment

Activate the code version that contains the cartridge

Business Manager only loads extensions from the active code version

❌ Why the other options are incorrect

B. Add roles and permissions to the user This is necessary for access control, but it does not make the extension appear. It only controls visibility after the extension is loaded.

C. Add the cartridge to the Storefront cartridge path Business Manager extensions must be added to the Business Manager site, not the storefront site.

Explanation:

When multiple pages share a common layout—like a header and footer—the most effective and structured way to apply this layout without repeating code is to use the ISML tag.

The tag is specifically designed for template inheritance, allowing developers to wrap content within a base layout (e.g., a page with header/footer). It promotes clean, modular code.

✅ Why is correct:

It wraps the current template with a parent template (usually containing layout structure like header and footer).

Used with or inside the base template to insert child-specific content.

Ideal for maintaining DRY (Don't Repeat Yourself) principles across pages that share a standard layout.

❌ Why not the others?

B. < iscontent >
Used inside the decorated template to define content blocks. It does not handle layout inclusion on its own.

C. < isreplace >
Used to override sections within a decorated (parent) template, not to apply the layout itself.

D. < isinclude >
Includes another template inline, but doesn’t wrap the current template. Good for small shared components (e.g., navbars), but not full-page layouts.

Explanation:

In SFRA, the Store Model (typically found in app_storefront_base/cartridge/models/store.js) is responsible for shaping the data passed to the storefront templates. To expose a custom attribute (like isMonobrand) from the Store system object, the best practice is to extend the existing model using module.superModule.

This approach:

Preserves the original model logic
Adds your custom logic cleanly
Ensures compatibility with future updates to app_storefront_base

❌ Why the other options are incorrect

A. Extend the Stores_Find controller with a new middleware function This is not scalable or modular. Logic should be encapsulated in the model, not the controller.

B. Pass the Store system object directly to the template This bypasses the model layer and violates SFRA’s separation of concerns.

C. Add logic to the template and call StoreMgr.searchStoresByCoordinates() Business logic should not be placed in templates. This breaks SFRA architecture.

Explanation:

In Salesforce B2C Commerce (SFCC), when you extend a system object like Product with custom attributes, those attributes are accessed through the .custom namespace of the object.

So, if you create a Boolean custom attribute named sellable on the Product system object, you can access it like this:

prod.custom.sellable

This is the standard and required way to access custom attributes for all system objects like Product, Customer, Order, etc.

Why not the others?

A. prod.extended.sellable
There's no extended namespace in the object model for accessing custom attributes.

B. prod.sellable
This would look for a native or built-in property of the product, but since sellable is custom, it won’t be directly on the object.

C. prod.persistable.sellable
persistable is not a valid property or namespace for accessing attributes in SFCC.

Explanation:

When implementing custom logs during checkout, the following are appropriate and secure to include:

Order Failure Information (Option B)

Why? Critical for debugging failed orders (e.g., inventory issues, payment declines).

Example:
Logger.error('Order failed for customer {0}: {1}', customerEmail, errorMessage);

Payment Gateway Response Code (Option D)
Why? Helps diagnose payment processing issues (e.g., responseCode: 200 for success, 400 for decline).

Example:
Logger.warn('Payment gateway response: {0}', gatewayResponse.getStatusCode());

Why Not Other Options?

A. Customer’s Password
Never log passwords (violates PCI compliance and privacy laws like GDPR).

C. Credit Card Information
Strictly prohibited (PCI-DSS forbids storing/logging full card details).