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

Explanation:

In Salesforce B2C Commerce, when using Data OCAPI to manage store (location) data, the HTTP verb you choose depends on whether you are creating or modifying a resource.

- POST is used to create a new resource.
- PUT is used to create or fully replace a resource when the resource ID is already known.
- PATCH is used to partially update an existing resource.

In this scenario:
- The developer wants an external application to create a new store.
- The store should appear in Staging as soon as it is saved, which is exactly what Data OCAPI supports.
- Since the store does not yet exist, the correct approach is to POST to the Stores Data OCAPI endpoint.

Typical endpoint:
POST /s/-/dw/data/v23_2/stores
This creates a new store resource and immediately persists it in the B2C Commerce instance.

Why the other options are incorrect
B. A PUT request to the Stores Data OCAPI ❌
PUT requires the resource identifier (store ID) to already exist or be explicitly defined. It is not the standard method for creating new stores when the ID is system-generated.
C. A PATCH request to the Stores Data OCAPI ❌
PATCH is only valid for partial updates of an existing store, not for creation.
D. An UPDATE request to the Stores Data OCAPI ❌
UPDATE is not a valid HTTP verb in OCAPI or REST APIs.

“Siempre que sea un objeto standard será put en vez de post” ❌
This statement is incorrect for SFCC. Even for standard objects, POST is used for creation, while PUT is for replacement with a known ID.

References:
Salesforce B2C Commerce – Data OCAPI Overview
Stores Resource (Data OCAPI)

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 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:

In Salesforce B2C Commerce (SFCC), when you have a site export file (usually a .zip containing XML files for products, categories, content, customers, etc.) already on your local computer and you want to import it into a sandbox, the recommended and most straightforward method is:

- Log in to Business Manager of the target sandbox.
- Go to Merchant Tools → Site Development → Site Import & Export.
- In the Import & Export Files section, select the Local tab (this allows you to upload files directly from your computer).
- Click Upload → choose your .zip export file from your local machine.
- Once uploaded, select the file in the list and click Import.
- Choose the import type (e.g., “Replace”, “Merge”, etc.) and proceed.

This is the standard, supported, and most commonly used approach for developers working with sandboxes.

Why the other options are incorrect:
A. Connect and import the file using the remote option within the Site Import & Export Business Manager module:
The Remote option is used when the file is already present on the instance’s WebDAV server (e.g., in /Impex). You cannot use Remote to upload a file from your local computer — it only imports from files already on the server.

C. Upload the file to the Impex WebDAV directory and import using the Site Import tool within UX Studio:
Incorrect on multiple levels:
- UX Studio does not have a “Site Import tool” for importing data (UX Studio is for code development and debugging).
- While you can upload to WebDAV /Impex manually (via WebDAV client or SFCC plugin), then import via Business Manager → Site Import & Export → Remote, this is unnecessary extra steps when the file is local.

D. Upload the file to the Static WebDAV directory and import using the Import & Export Business Manager module:
The Static WebDAV directory (/Static) is for static assets (images, CSS, JS, etc.), not for import/export archives. Placing a site export .zip there will not make it available for the Site Import & Export tool.

Salesforce recommendation:
For local files → always use the Local upload option in Business Manager → Site Import & Export.
This is a very frequent exam question — the key is knowing the difference between Local vs Remote tabs and where files should be located.

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:

In Salesforce B2C Commerce (SFRA) controllers, each route handler must call next() to continue the middleware chain and properly complete request processing.

Looking at the snippet (simplified):
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 here
},
pageMetadata.computedPageMetadata
);

After calling res.render(), the controller must invoke next() so that:
- The request lifecycle completes correctly
- The following middleware (pageMetadata.computedPageMetadata) executes
- The controller does not hang or fail silently

The correct fix is:
next();

Why the other options are incorrect:
B. return res; ❌ Returning the response object does not advance the middleware chain. SFRA explicitly requires next().
C. res.next(); ❌ res.next() does not exist in SFRA or Express-style middleware.
D. req.next(); ❌ next() is provided as a separate callback argument, not a method on req.

Reference:
SFRA Controllers & Middleware Pattern

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:

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.