Free Practice Questions for Salesforce Comm-Dev-101 Exam

The certification varies byproduct and site, so the data belongs directly on the Product system object as asite-specific custom attribute. A product can then have one default certification value and independent site-specific overrides for the U.S. and European storefronts.

Salesforce documents that products are organization-level entities shared across sites, but selected system and custom product attributes can be configured as site-specific. A site-specific attribute can hold a default value and per-site overrides, making it appropriate for information such as market-specific product presentation or compliance metadata.

The attribute should not be localizable if it is site-specific; Salesforce explicitly states that onlynon-localizablecustom product attributes can be site-specific.

Option B proposes a Certificate system object type that does not represent the product/site relationship described. Option C would create a site-wide value and therefore could not distinguish between different certificates for smartphones, hairdryers, and other products.

Study Guide reference:Data Management Using Business Manager Usage — Product custom attributes, site-specific attributes, multi-site product data, and PDP presentation.

===============

CSRF validation must occurwhen the state-changing request is submitted, before protected business logic executes. In SFRA this is implemented as middleware in the controller ' s POST route, using the appropriate CSRF middleware—validateRequestfor standard submissions orvalidateAjaxRequestfor AJAX-based requests.

Salesforce ' s SFRA Forms documentation specifically states that CSRF protection is supplied as middleware and demonstrates CSRF checks as middleware steps. The underlyingdw.web.CSRFProtection.validateRequest()API verifies that the request contains the system-generated token and that the token has not expired.

Generating the token in the template only establishes the client-side value; it does not provide security unless the receiving POST endpoint validates it. Placing validation only in the form-display route would validate the wrong request. Performing validation in a persistence model is also too late because request security should be enforced before mutation logic is invoked.

Study Guide reference:Application Development — CSRF protection, SFRA middleware, POST routes,validateRequest,validateAjaxRequest, and secure form processing.

===============

The appropriate responsibility of < isif > isconditional presentation. Evaluating a Boolean already present inpdictand choosing between different pieces of markup is exactly the intended ISML use case.

Salesforce ' s official < isif > documentation is explicit that < isif > , < iselseif > , and < iselse > containno business logic; they provide conditional visualization of data. The condition can use Pipeline Dictionary variables and other expressions that resolve to Boolean behavior.

Option B therefore violates the separation of concerns used by SFRA. Complex business rules should be computed before template rendering—typically in controllers, helpers, models, or other server-side modules—and only their resulting data should be passed to ISML. Option C is also incorrect because redirecting a request is controller responsibility. A template should not control HTTP routing or authentication flow.

The supplied question ' s correct use is consequently showing a different < div > based on an already computed Boolean.

Study Guide reference:Application Development — ISML, < isif > ,pdict, conditional visualization, controller responsibilities, and separation of presentation from business logic.

===============

For an independent external web application, the appropriate legacy B2C Commerce integration surface is theShop API Product Search resource. The application can retrieve structured product-search results for the desired category and use that data to construct a completely different presentation layer.

Salesforce ' s OCAPI documentation defines the Shop APIGET /product_searchresource and corresponding product-search extension points. The resource returns structured Product Search Result data rather than storefront-rendered HTML. This separation is important because the new application can independently control CSS, layout, rendering technology, and interaction behavior instead of attempting to reuse or scrape the existing storefront.

Search-Showis an SFRA controller designed to render the storefront search experience. Crawling its HTML creates unnecessary coupling to existing presentation markup and is not an integration architecture. A generic category endpoint can return category metadata, but the Product Search resource is designed to obtain product listing/search results.

Current platform note: Salesforce now marks OCAPI as deprecated for new implementations and recommends SCAPI for modern headless development, but the supplied certification question is explicitly testing the Shop OCAPI architecture.

Study Guide reference:Application Development — OCAPI Shop API, Product Search, headless/external storefront integrations, structured search results, and API-based storefront development.

===============

Page-Includeis explicitly protected withserver.middleware.include, meaning it is designed to execute as aremote include, not as a shopper ' s top-level browser request. Salesforce ' s SFRA Page controller documentation describesPage-Includeas an endpoint triggered when content assets are embedded within a rendered page and identifiesserver.middleware.includeas its middleware.

The appropriate ISML mechanism is therefore:

< isinclude url= " ${URLUtils.url( ' Page-Include ' , ' cid ' , ' about-us ' )} " >

Using theurlattribute makes < isinclude > perform a remote include. Salesforce documents that this causes the web adapter to execute another request and insert the endpoint ' s returned content into the surrounding template.

Option A creates a shopper-clickable top-level URL, which fails the include middleware condition and explains the error described in the scenario. Option C is not the remote-include tag.

Study Guide reference:Application Development —Page-Include,server.middleware.include, remote includes, < isinclude url > , and SFRA content rendering.

===============

Page Designer regions can define restrictions governing which component types merchants are permitted to place inside them. Therefore, the correct concept represented by option A is to configure acomponent-type exclusionin the layout component ' s JSON metadata rather than modifying every disallowed component.

Salesforce ' s Page Designer documentation shows this mechanism directly: a region definition can usecomponent_type_exclusionto specify that particular component types aren ' t allowed within that region. This centralizes containment rules within the layout or page type that owns the region.

There is an important terminology detail in the supplied question: the official Page Designer metadata property documented by Salesforce iscomponent_type_exclusion(singular), whereas option A printscomponent_type_exclusions. The question content has been preserved exactly as supplied, but A clearly represents the intended official mechanism.

Option B suggests an unsupported/inaccurately named inclusion property in this context. Option C incorrectly pushes the restriction into individual asset-component metadata, which would tightly couple child components to a particular layout and make reuse difficult.

Study Guide reference:Application Development — Page Designer meta definitions, layout components, region definitions, component restrictions, andcomponent_type_exclusion.

===============

< isif > is appropriate forconditional presentation logicinside an ISML template. Showing or hiding a page fragment according to information already provided to the view—such as whether the current shopper is authenticated—is exactly the kind of lightweight rendering decision for which < isif > is intended.

Salesforce explicitly states that < isif > , < iselseif > , and < iselse > provide conditional template constructs but should containno business logic, only conditional visualization of data. SFRA customization guidance reinforces this architectural separation by stating that business logic generally does not belong inapp_storefront_basetemplates; templates should concentrate on rendering.

Option B therefore violates SFRA separation-of-concerns practices because involved business logic belongs in controllers, models, helpers, or services. Option C is also unsuitable because routing and redirects are HTTP response-control operations that should be performed by the controller rather than an ISML presentation template.

Study Guide reference:Application Development — ISML conditional rendering, < isif > , template responsibilities, controllers, and separation of business logic from presentation.

===============

The correct behavior is suspension of additional custom logging for the remainder of the logging day. Salesforce documents that custom log files are governed by daily size restrictions per application server. Once the permitted volume has been reached,logging is suspended until 00:00 GMT on the next day.

This limit is distinct from ordinary archival. Log files can later be compressed and moved to thelog_archivedirectory according to standard retention processing, but B2C Commerce does not bypass its daily governance limit by opening another unrestricted file.

Option C is similarly incorrect because the platform does not delete diagnostic evidence merely to obtain more writing capacity.

This behavior is particularly relevant to heavily trafficked custom controllers, jobs, import processes, and third-party integrations. Developers should avoid logging entire payloads or repetitive informational messages at high volume and should use categories and severity thresholds deliberately.

Verification correction:the source marks B for Q146, but Salesforce ' s current official Log Files documentation explicitly states that logging is suspended after the daily limit is reached.

Study Guide reference:Application Development — logging governance, custom-log limits, log suspension, archival, retention, and performance protection.

===============

B2C Commerce custom attributes are defined through the platform ' smetadata system, not dynamically declared by application JavaScript. Therefore, the first step is to create the required attribute definition in Business Manager on the appropriate extensible system object or custom-object type.

Salesforce documents the process under Administration > Site Development > System Object Types or Custom Object Types. The developer selects the target object, opens Attribute Definitions, clicks New, and defines the attribute ID, display name, and data type.

Once the attribute exists, it can be assigned to an attribute group where required for Business Manager visibility, populated through Business Manager or integrations, and accessed through the object ' scustomproperty in application code.

Option B is incorrect because source code cannot create an undeclared persistent custom attribute merely by referencing a property name. Option C also comes later because application logic needs the metadata definition to exist before reliably reading or writing the value.

The type and characteristics of the attribute should be designed carefully because changing an existing attribute ' s type can cause stored values to be lost.

Study Guide reference:Data Management Using Business Manager Usage — System Object Types, Custom Object Types, Attribute Definitions, attribute groups, and custom metadata.

===============