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

Explanation:

To create a new store (or any new resource) using OCAPI (Open Commerce API), the correct HTTP method is POST.

Here's why:
POST is used to create a new resource on the server.
PUT is used to update/replace an existing resource at a known URL.
PATCH is used to partially update an existing resource.
There is no UPDATE HTTP verb — that is not valid.

In this case, the developer wants to create a new store, so a POST request to the Stores Data API is the appropriate choice.

For example:
POST /s/-/dw/data/v22_11/sites/{site_id}/stores

With a JSON payload that defines the store:
{
"store_id": "new-store-id",
"name": "New Store",
"description": "Sample store",
"store_hours": "9am-5pm",
...
}

Once this request is made, the new store data will be added to the Staging instance (assuming it's the current environment), and can be replicated to other instances if needed.

Explanation:

Salesforce B2C Commerce enforces quotas to maintain platform stability and performance. When an enforced quota is exceeded, the system throws an error and halts the operation — often resulting in storefront pages displaying error messages. These quotas typically relate to memory usage, object creation, or inefficient custom code.

To resolve this, the developer must optimize or refactor the code that’s causing the overage. This could involve:

Reducing the number of objects created in memory.
Avoiding large collections or deeply nested loops.
Using pagination or lazy loading where appropriate.
Reviewing quota logs to pinpoint the offending pipeline or script.

Why the other options are incorrect:

B. Change the Business Manager configuration for the quota settings: Quotas cannot be changed directly in Business Manager. Only Salesforce Support can soften quotas, and even then, only in specific cases.
C. Take no action: Ignoring the issue risks continued errors and degraded performance. Quotas are enforced to prevent instability.
D. Ask support to remove the quota limit: Quotas are a core part of platform governance. Support may soften them (change from error to warn), but removal is not an option.

Explanation:

In Salesforce B2C Commerce (SFCC), to render an ISML template, the correct method is:
ISML.renderTemplate('path/to/template');
Where the path is relative to the templates folder and without the .isml extension.

In your case, the file structure is:
templates
└── default
└── content
└── custom
└── customLandingPage.isml

The correct way to render it is:
ISML.renderTemplate('content/custom/customLandingPage');

❌ Why the Other Options Are Incorrect:
A. ISML.renderTamplate(...) – Typo in the method name (renderTamplate should be renderTemplate)
B. ISML(...) – There is no such method; ISML is an object, not a callable function.
C. ISML.render(...) – This method is deprecated; use renderTemplate() instead.

Explanation:

Site Import & Export in Business Manager
The Site Import & Export module in Business Manager is the standard tool for importing/exporting site data (e.g., catalogs, content, promotions).
For a local file import, the developer should:

Navigate to Administration > Site Development > Site Import & Export.
Select "Local" (to upload from their computer).
Choose the export file and start the import.

Why Other Options Are Incorrect

A (Remote): Used for files hosted on a remote server (e.g., via HTTP/FTP), not local files.

C (Impex WebDAV + UX Studio): The Impex WebDAV directory is for data migration files (e.g., XML/CSV), not site exports. UX Studio does not handle site imports.

D (Static WebDAV): The Static WebDAV directory is for static assets (e.g., images, JS, CSS), not site data imports.

Explanation:

Session Scope (session) is the most appropriate choice because:

It persists throughout the entire shopping session, surviving across multiple pages and requests.
It does not require storage in a database (unlike system/custom objects).
It is user-specific, ensuring each shopper’s occasion selection is maintained.

Why Other Options Are Incorrect

A (Request scope): Only lasts for a single HTTP request (lost on page navigation).

B (Page scope): Tied to a single ISML template (lost when leaving the page).

D (Content slot variable): Used for rendering dynamic content in slots, not for storing user input.

Explanation:

In Salesforce B2C Commerce (SFCC) controllers using the middleware pattern, each middleware function must call the next() function to indicate that:

The current middleware is complete, and

Control should be passed to the next middleware function, or the response should be finalized.

In your code snippet:
server.get(
'Show',
consentTracking.consent,
cache.applyDefaultCache,
function (req, res, next) {
var Site = require('dw/system/Site');
var pageMetaHelper = require('*/cartridge/scripts/helpers/pageMetaHelper');

pageMetaHelper.setPageMetaTags(req.pageMetaData, Site.current);
res.render('home/homePage');

// ✅ Missing line
},
pageMetaData.computedPageMetaData
);

After res.render(), you must call:
next();
This ensures the controller continues processing properly. Even after rendering, calling next() is standard practice to finalize the response.

❌ Why Other Options Are Incorrect:

B. return res; – res is not a function and returning it has no effect on the middleware chain.

C. res.next(); – res does not have a next() method.

D. req.next(); – Similarly, req does not have a next() method. next is passed explicitly as an argument.

Explanation:

In Salesforce B2C Commerce, logging best practices recommend using the appropriate log level based on the severity and nature of the event:

When an operation succeeds but produces an unexpected outcome that might lead to side effects (e.g., unexpected data format, missing optional fields, or degraded performance), it’s not a failure — but it warrants attention.

The warn level is designed exactly for this: to flag potentially harmful situations that aren’t outright errors but could cause issues if ignored.

Why the other options don’t fit:

info is for general operational messages — not suitable for anomalies.

debug is for detailed internal diagnostics — useful during development, but not ideal for production alerts.

error is reserved for failures that prevent normal execution — which isn’t the case here.

Explanation:

To improve client-side performance in Salesforce B2C Commerce (and web development in general), you want to minimize HTTP requests, reduce file size, and optimize caching. Let’s break down each choice:

✅ B. Place CSS outside of templates
Why: External stylesheets can be cached by the browser, reducing load times on subsequent pages.
Best Practice: Avoid inline or per-template CSS. Load a single, minified stylesheet.

✅ C. Compress CSS
Why: Minification removes unnecessary spaces, comments, and line breaks from stylesheets.
Result: Smaller files → Faster load times

✅ E. Combine several images into a single image (aka CSS Sprites)
Why: Fewer image files = fewer HTTP requests.
How: Use background positioning in CSS to show only the part of the sprite needed for a specific UI element.

❌ A. Use one style sheet for each ISML decorator template
Why it's wrong: Multiple stylesheets increase the number of HTTP requests.
Best Practice: Combine all styles into one compressed stylesheet used across templates.

❌ D. Use inline JavaScript
Why it's wrong: Inline JS increases page size and cannot be cached.
Best Practice: Use external JavaScript files that can be cached and minified.

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.