Free B2C Commerce Architect Practice Test Questions

Explanation:

✅ Why A is Correct:

Official place for SFRA source code and community cartridges.
Contains sample integrations and real code examples.
Best starting point for quickly finding existing implementations.

❌ Why Not B (Trailblazer Community):

Great for discussions and questions
Not a code repository

❌ Why Not C (Trailblazer Portal):

Meant for support cases and account management
Not for community code

❌ Why Not D (B2C Commerce Documentation):

Documentation explains features and APIs
Does not include downloadable community cartridges

✅ Recommended Practice:

Check Salesforce Commerce Cloud GitHub for shared code
Saves budget and development time

Explanation:

✅ Option A

{
"nto.net": "www.nto.net",
"nto.eu": "www.nto.eu",
"nto.event.eu": "www.nto.eu"
}

→ This maps various domains individually to their own or to www.nto.eu. However:
This would serve different hostnames depending on domain.
It doesn’t consolidate everything under a single domain for maintenance.
Not correct.

✅ Option B

{
"www.nto.eu": "www.nto.eu"
}

→ Only maps www.nto.eu → www.nto.eu.
No redirection for other domains (nto.at, nto.de, etc.).
Would leave other domains unreachable during maintenance.
Not correct.

✅ Option C

{
"nto.eu": "www.nto.eu",
"nto.at": "www.nto.at",
"nto.de": "www.nto.de"
}

→ This keeps each country on its own domain.
So www.nto.at would still show a local version, not a universal maintenance page.
Not correct.

✅ Option D

{
"nto.eu": "www.nto.eu",
"nto.at": "www.nto.eu",
"nto.de": "www.nto.eu"
}

✅ This correctly:

Redirects all regional domains (nto.at, nto.de) to one single domain www.nto.eu.
Allows the maintenance page to exist once at www.nto.eu.
Ensures all traffic hits the same maintenance page regardless of locale.
→ This is the correct answer.

✅ Why D is Correct

During maintenance, you want:
One canonical domain for all traffic
Simplified display of the same maintenance page
Avoid maintaining separate maintenance pages for each domain

Explanation:

When moving data between different Salesforce B2C Commerce instances (e.g. sandbox → staging → production), certain data types are commonly imported/exported to preserve functionality and content.

✅ B. Catalog → Correct

Catalog data includes:
Products
Categories
Prices
Images and assets

This data is absolutely essential for running your storefront. It’s a typical data import/export scenario across environments.
✅ Definitely imported.

✅ C. Customers → Correct

Customer data includes:
Customer accounts
Addresses
Profile attributes
Preferences

It’s common to migrate customer data, especially for testing or staging deployments.
✅ Definitely imported.

❌ Why Not The Other Options

A. Services

“Services” are defined in code and configurations (Service Framework), usually managed via cartridges and BM configurations.
While you might export/import service definitions (e.g. via meta data or replication), they’re not typically called “data imports” like catalog or customer records.
→ Not the typical answer for data import.

D. Metadata

Metadata is very broad:
Includes things like object definitions, site preferences, etc.
While parts of metadata can be imported/exported (e.g. via site import/export), in B2C Commerce, the term “data import” usually focuses on catalogs, customers, prices, promotions.
→ Too broad. Not the best fit for this question.

E. Site configurations

Many site configurations live in Business Manager.
These are often replicated, not imported/exported via standard data files.
Some settings might come via metadata exports, but it’s not typical to call these “data imports.”
→ Not the right answer here.

Explanation:

Why?

is the B2C Commerce ISML tag for secure output encoding.
encoding="jshtml" ensures:
HTML entities are escaped (e.g., < → <).
JavaScript injection is prevented (e.g., " → \x22).
This directly fixes XSS in the quick search.

Why Not Other Options?

❌ A. Replace ' with "
Problem: Simply changing quotes does nothing to escape malicious input.

❌ C. encoding="jsblock"
Problem: jsblock is not a valid encoding type in B2C Commerce.

❌ D.
Problem: No such tag exists in B2C Commerce ISML.

Best Practice:

Always use with context-aware encoding:
encoding="html": Basic HTML escaping.
encoding="jshtml": For JS-in-HTML contexts (e.g., inline scripts).
encoding="url": For URL parameters.

Example Fix:

!-- Before (Vulnerable) -->
<script>var searchTerm = '${searchPhrase}';</script>

!-- After (Secure) -->
<script>var searchTerm = '';</script>

Explanation:

Why?

Average Time (2,079 ms) is critically high compared to other controllers (e.g., Product-Detail at 607 ms).
Total Time (10,776,564 ms) is the 2nd highest, despite having far fewer hits (5,184) than others.

Consistent Slow Performance:
Minimum (2,056 ms) and Maximum (2,200 ms) times are nearly identical, indicating a systemic bottleneck (not sporadic slowness).

Why Not Other Options?

❌ A. Product-HitTile
High hits but low average time (32 ms): Not the root cause of overall slowness.

❌ B. Search-Show
Moderate average time (464 ms): Less urgent than Home-IncludeHeaderMenu.

❌ C. Product-Detail
High total time but lower average time (607 ms): Likely due to high traffic (38,880 hits), not inefficiency.

Root Cause Investigation:

1. Check IncludeHeaderMenu Logic:
Is it making unoptimized API calls (e.g., CMS, categories)?
Does it over-process static data (e.g., menu items)?

2. Cache Analysis:
Ensure menu content is cached (e.g., via iscache).

3. Database Queries:
Audit any slow queries in this controller.

Best Practice:
Optimize high-average-time controllers first—they impact every user request.
Use B2C Commerce Pipeline Profiler to drill into IncludeHeaderMenu’s sub-pipelines.

Explanation:

The PDP page has a low cache hit ratio because the URL includes a parameter like ?position=5. This creates unique cache entries for every different position value. To fix this without losing analytics data, the parameter should be handled client-side instead of in the URL.

Why A is Correct:
By removing the parameter from the URL and passing it to analytics via JavaScript, the PDP URL stays clean, improving cache hits while still preserving the analytics data.

Example:
// Store position client-side
sessionStorage.setItem('plpPosition', '5');
// Read in analytics script
var pos = sessionStorage.getItem('plpPosition');
analytics.track('PDP View', { position: pos });

Why Not the Other Options:

B: Excluding the parameter from cache would disable caching entirely for those requests, worsening performance.
C: Removing the parameter completely is not acceptable because the client requires it for analytics.
D: Moving the parameter into the URL hash could cause issues with deep linking and still requires significant changes.