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

Explanation:

OCAPI Shop API requests for product information must use the GET method. The developer is requesting product details, which is a read-only operation. Using POST or PUT would imply creating or updating resources, which is not the case here. By changing the method to GET, the request will correctly retrieve product data from /dw/shop/v18_3/products/{product_id}.

Why the others are wrong
A. Change URI to /dw/shop/v18_3/products/creative-zen-v → The URI may already be correct; the issue is the HTTP method.
B. Change method to PUT → PUT is for updates, not retrieval.
D. Include authentication token → OCAPI Shop API requires only a client_id for read requests, not an auth token.

Reference
Salesforce OCAPI Shop API Guide – Product Resource:

Explanation:

Why B is correct
To display a refinement (facet) on the storefront for a custom attribute like weightCapacity, the developer must:

Define a search refinement in Business Manager → Merchant Tools → Search → Searchable Attributes & Refinements → add weightCapacity as a refinement attribute (with buckets if needed).
Rebuild the product search index so the attribute values are indexed and available for faceting.

This makes the refinement appear automatically on category and search pages in SFRA as a filter sidebar.

Why the other options are incorrect

A. Define a sorting rule → Sorting affects result order, not filtering or refinement display.
C. Define search-suggestion buckets → Suggestions are used for type-ahead search, not for PLP refinements.
D. Clear page cache instead of rebuilding index → Page cache affects rendered output, not the availability of refinement data from the search index.

References
Salesforce Documentation → Search Refinements → Configuring Custom Attribute Refinements
Trailhead: Customizing Search Refinements

Explanation:

Salesforce B2C Commerce follows a strict naming convention for log files written to disk via the dw.system.Logger API.
When a developer uses a specific category in code, such as Logger.getLogger("xyz"), the platform treats this as a custom log.

The convention for custom logs is:
custom---.log

Since the code uses the category "xyz", the resulting file on the WebDAV server will always begin with the prefix custom-xyz.
Even if the Business Manager root log level is set to "info", this only controls which messages are recorded and does not change the naming convention of the log file for that category.

Why the Incorrect Answers Are Wrong

A. xyz → The system automatically prefixes custom categories with custom- to distinguish them from system-generated logs such as error-* or warn-*.

B. custominfo-blade → This is a distractor. Although the log level is set to "info", the log level is not included in the filename for custom loggers.
The term "blade" refers to the specific application server instance and appears later in the filename, not at the beginning.

C. custom-export → This filename would only be used if the developer had called Logger.getLogger("export").
The category name passed in the script is the primary identifier for the log filename.

Reference
Salesforce Developers: Logging and Log Files
dw.system.Logger API Reference

Explanation:

When configuring Open Commerce API (OCAPI) permissions on a sandbox instance with no existing permissions, two properties are absolutely required to enable access to any resource:

A. Resource_id
This specifies which API resource the permission applies to, such as /baskets/*, /products/*, or /customers/*.
The resource_id uses wildcard patterns to define scope.
Without a resource_id, the system cannot determine which API endpoints the permission should cover.

Examples include:
/baskets/** – All basket resources and sub-resources
/products/* – Specific product resources
/customers/*/addresses – Customer address sub-resources

C. Client_id
This identifies the application or integration making the API request.
Client_id is the primary authentication mechanism for OCAPI and is typically issued when registering an application in Business Manager.
Each client_id can have different permissions, enabling granular access control.
The client_id must be included in all API requests as a query parameter or request header.

These two properties form the minimal permission configuration: who (client_id) can access what (resource_id).
All other properties such as read_attributes, write_attributes, methods, and version_range are optional and provide finer-grained control but are not strictly required for basic access.

Why Other Options Are Incorrect

B. Read_attributes → This property controls which attributes can be returned in API responses.
While important for data exposure control, it is not required for basic permission configuration.
If omitted, the default behavior typically allows all attributes to be readable.

D. Version_range → This defines which API versions the permission applies to.
It is optional, and if omitted, the permission applies to all API versions.
Although recommended for forward compatibility, it is not required for initial permission setup.

References
OCAPI Security Guide: Minimum Permission Configuration
Business Manager OCAPI Setup: Required Fields for Permission Scopes
API Authentication Documentation: Client_id Requirements
Permission Scope Schema: Mandatory vs Optional Properties

Explanation:

Why Option A is Correct
This is the most efficient and platform-native approach.

System Object Extension:
Adding a custom attribute to the Order system object allows the data to be stored directly within the order record in the B2C Commerce database.

Controller Update:
Modifying the controller (such as CheckoutServices.js in SFRA or COPlaceOrder.js in SiteGenesis) ensures the user's input from the UI is captured and assigned to the new attribute before the order is finalized.

Standard Export:
The platform’s standard Order Export (commercedoc XML) automatically includes custom attributes of the Order object. Therefore, no manual modification of the export process logic is required.

Why Other Options are Incorrect

B. Modify to update a CSV:
This is a manual, non-scalable workaround. B2C Commerce provides an object-oriented database; using external CSVs for standard order data creates synchronization risks and bypasses the built-in Order Management capabilities.

C. Add to Customer object:
Order comments are specific to a single transaction (Order), not the persistent identity of the Customer. If a customer places multiple orders, their Customer attribute would be overwritten each time, resulting in loss of historical data.

D. Create a new custom object:
While possible, this approach is architecturally heavy. It requires managing a separate object and manually linking it to the order. Since the Order object is already extensible, creating a custom object introduces unnecessary overhead.

References
Salesforce Help: Extending System Objects
Salesforce Developers: Order Export

Explanation:

In Salesforce B2C Commerce Cloud (formerly Commerce Cloud), page caching (including cache partitions) is managed per site in Business Manager. To create or configure a cache partition (such as one specifically for the home page), the developer navigates to the cache settings of the relevant site.

The standard path is:

Administration > Sites > Manage Sites → select the specific site (for example, RefArch or the merchant’s site) → Cache tab

From there, you can:

View existing cache partitions
Invalidate (clear) specific partitions manually
Manage cache-related settings for that site

This allows targeted invalidation — exactly what the merchant wants. When the home page content is edited (such as through Page Designer, slots, or promotions affecting the homepage), only the home page’s cache partition is cleared, without flushing the entire site cache.

Why not the other options?

B. Operations > Site > Manage Sites > Cache
Incorrect path. There is no top-level “Operations > Site > Manage Sites” navigation in Business Manager for cache configuration.

C. Operations > Cache > Site
Incorrect. The Operations section contains tools such as Jobs, Import & Export, and Order Management, but not site-specific cache partition management.

D. Site > Site Preferences > Cache
Incorrect. Site Preferences handle settings such as locale, currency, units of measure, and some storefront behavior, but not page cache partitions or cache invalidation controls.

Reference

Official Salesforce Documentation (B2C Commerce Developer Guide):

Content Cache Overview:
“Cache invalidation (Entire Site and / or Partition) via Business Manager: Click App Launcher and then select Administration > Sites > Manage Sites > Cache.”

Managing Sites for Development (disabling / managing cache per site):
Same path: Administration > Sites > Manage Sites > [site] > Cache

Explanation:

In Salesforce B2C Commerce, custom logging is a common practice for developers to track application behavior, debug issues, and monitor performance. Each log file has a maximum file size limit defined by the platform. When this limit is reached, the system must decide how to handle additional log entries without losing important information or halting logging altogether.

The correct behavior is that the current log file is archived (renamed and stored for later reference), and then a new log file is created to continue logging seamlessly. This process ensures that:

No data is lost – The archived file preserves all log entries up to the size limit.
Logging continues without interruption – A new file is immediately created, so developers can still capture ongoing activity.
Log management remains organized – Archived files can be reviewed later for debugging or auditing purposes.

This rollover mechanism is standard in logging frameworks and ensures scalability and reliability in production environments. Developers can configure log categories and levels (e.g., info, debug, error) to control the verbosity of logs, but the rollover behavior is automatic once the file size threshold is reached.

✅ Why Option C is Correct
Matches the documented behavior of SFCC logging.
Ensures logs are preserved and new entries continue to be captured.
Provides a balance between storage management and operational continuity.

❌ Why the Other Options Are Incorrect

A. Deleted and new file created → Incorrect, because logs are not discarded; they are archived for later use.
B. Logging suspended for the day → Logging never stops; it continues in a new file.
D. Rolls over and overwrites oldest messages → SFCC does not overwrite logs; it archives them to prevent data loss.

📘 Reference
Salesforce B2C Commerce Documentation – Logging:
“When a custom log file reaches its maximum size, the current file is archived and a new log file is created automatically.”
Salesforce Developer Guide – Custom Logging

Explanation:

Why This Answer is Correct
Creating a content slot for homepage display requires specific attributes that define its placement and behavior. Option B contains all necessary attributes:

id="my_banner" – Unique identifier for the slot
description="for home page" – Human-readable description for Business Manager
type="global" – Makes the slot available across the site, not page-specific
context="homepage" – Associates the slot with the homepage template/context

The context="homepage" attribute is crucial—it tells the system this slot should be available when rendering the homepage template. In Business Manager, content assigners can then target content specifically to this slot when editing the homepage.

The slot can be included in homepage.isml using:
<isslot context="homepage" id="my_banner">
This approach follows B2C Commerce best practices for reusable, context-aware content slots.

Why Other Options Are Incorrect

A. <isslot id="my_banner" ... context="content" context-object="${pdict.ContentSearchResult.content}" /> – context="content" is for content asset pages, not the homepage. The context-object binding is unnecessary for a simple homepage banner slot.

C. <isslot id="my_banner" description="for home page" context="global"> – Missing closing / and type attribute. While context="global" might work, it's less specific than context="homepage" for targeting.

D. <isslot id="my_banner" ... context="global" contextobject="${pdict.CurrentHomePage}" /> – contextobject isn't a valid attribute for isslot. Context binding uses different mechanisms in B2C Commerce.

References
Content Slot ISML Reference: <isslot> Tag Attributes
Page Designer Guide: "Context-Specific Slot Configuration"
Template Development: "Slot Placement and Targeting"

Explanation:

If a developer adds new cartridges to their workspace but they don't seem to be executing, it means the code hasn't reached the sandbox. To fix this in UX Studio, the following must be verified:

A. Auto-Upload:
This is the most common reason. If "Auto-Upload" (or "Build Automatically") is disabled, the IDE will save the file locally but will not trigger the WebDAV transfer to the sandbox.
B. Active Server:
A workspace can have multiple server connections. If the specific sandbox connection is not marked as "Active," the IDE won't attempt to upload anything to it.
C. Credentials (Username/Password):
If the password has expired or is incorrect, the IDE cannot authenticate with the server to start the upload.

Why the Incorrect Answers are Wrong

D. Cartridge for the current version:
B2C Commerce is highly backward compatible. A cartridge written for an older version will still upload and attempt to execute. Versioning doesn't prevent the upload process.

E. Server configured to accept incoming connections:
B2C Commerce sandboxes are SaaS instances that are always configured to accept WebDAV connections from authorized developers. There is no "switch" in Business Manager to turn off incoming developer connections.

Reference
B2C Commerce: Establishing a Server Connection

Explanation:

Efficiency and scalability in B2C Commerce product data retrieval require using appropriate APIs designed for large catalogs:

B. ProductSearchHit.getRepresentedProducts() – This method efficiently retrieves product variants from search results. When search returns master products, getRepresentedProducts() fetches their variants in an optimized batch operation, minimizing database queries. This is scalable because:

Works within search result sets (already filtered/limited)
Uses efficient batch retrieval patterns
Respects search indexing and performance optimizations

C. ProductSearchModel.getProductSearchHits() – The ProductSearchModel API is designed for scalable product retrieval through the search engine, which is optimized for large catalogs. Benefits include:

Leverages search index performance (not direct database queries)
Supports pagination through result sets
Allows filtering/refinement before retrieval
Integrates with caching mechanisms
Handles large catalogs efficiently through indexed access

These methods use the search infrastructure, which is specifically engineered for performance with thousands or millions of products.

Why Other Options Are Incorrect

A. ProductMgr.queryAllSiteProducts() – This method retrieves all products for a site, which is highly inefficient and non-scalable for large catalogs. It loads entire product sets into memory, causing:

Excessive memory consumption
Long execution times
Database performance degradation
Timeout risks with large catalogs

D. Category.getProducts() – While useful for small categories, this method doesn't scale well for large product sets or complex catalog structures. It:

Loads all category products at once (no pagination)
Doesn't leverage search engine optimizations
Can be slow for categories with thousands of products
Lacks built-in performance safeguards

References
Performance Best Practices: "Efficient Product Data Retrieval"
Search API Documentation: "ProductSearchModel vs ProductMgr"
Scalability Guide: "Handling Large Product Catalogs"
API Reference: "ProductSearchHit Optimization Methods"