Explanation:

The Lead Inbox component is the standard, pre-built Lightning component specifically designed for Lead Distribution within the Partner Central Experience Cloud template.

Functionality: When leads are routed to a partner (typically via Lead Assignment Rules), the Lead Inbox displays these new, unaccepted leads to the partner user in their portal. The partner can then review and accept the lead with a single click, which officially changes the lead owner to the partner user. This component is crucial for enabling the core Partner Relationship Management (PRM) workflow of distributing leads to the channel.

Incorrect Answers
A. Lead Distribution:
This is a feature or process name in Partner Relationship Management (PRM) (e.g., "Configure Lead Distribution"), not the name of a standard component in Experience Builder.
C. Lead Selector:
This is not a standard component name used for lead distribution to partners in Experience Cloud.
D. Lead Flow:
While Salesforce Flow can be used to automate the lead distribution process (i.e., the routing logic that determines which partner gets the lead), it is not the standard component that the partner interacts with in the portal to view and accept the assigned leads. The component in the portal is the Lead Inbox.

Reference
The functionality of the Partner Central template and its components is documented in Salesforce's Experience Cloud help articles.
Salesforce Documentation Reference (Conceptual): The documentation for customizing the Partner Central template explicitly mentions using the Lead Inbox component to configure lead distribution, allowing partners to see leads assigned to them and accept those leads within the portal.

Explanation:

External Account Hierarchy:
This is a specific Salesforce feature designed for external users (like those with Customer Community Plus licenses). It enables sharing records between accounts in a parent-child relationship within an Experience Cloud site.
Customer Community Plus License:
The problem explicitly states that NTO has Customer Community Plus licenses, which are compatible with this feature. External Account Hierarchy is not available for the basic Customer Community license.
B2B Use Case:
The scenario describes a classic B2B use case where a parent company (large customer account) needs visibility into its child accounts (departments) and their related records (opportunities). The External Account Hierarchy feature was built specifically for this purpose.
Record Visibility:
When the External Account Hierarchy is enabled, data owned by users in child accounts automatically becomes visible to users in the parent account. This avoids the need for complex and numerous sharing rules or other manual sharing mechanisms.
Person Accounts are Separate:
The fact that NTO uses person accounts for its B2C business is a distraction. The External Account Hierarchy feature is only for business accounts, and NTO already uses business accounts for its B2B operations.

Why other options are incorrect

A. Extend the Standard Role Hierarchy:
The standard role hierarchy applies to internal users. External users exist outside this hierarchy (or in a separate, limited account role hierarchy) and do not directly participate in the internal hierarchy for standard data sharing.
C. Use the Business Accounts and Contacts with Sharing Sets:
While Sharing Sets are used for sharing with high-volume external users, they do not provide visibility across an account hierarchy. They are designed to share records based on a direct lookup relationship (e.g., sharing a case with the customer who created it), not for a roll-up view based on an account hierarchy.
D. Since NTO has person accounts, it cannot use the External Account Hierarchy and will need to use groups and sharing rules to grant the required record access:
This is incorrect for two reasons. First, the External Account Hierarchy is only for business accounts, and NTO is using business accounts for this B2B use case, so the person accounts are not relevant here. Second, using manual sharing rules for a complex, large-scale hierarchy is inefficient and difficult to maintain, which is exactly the problem the External Account Hierarchy feature was designed to solve.

Explanation:

Why this is the right consideration for Customer Community licenses
Customers on the Customer Community (a high-volume external) license don’t get roles or role hierarchy. Because of that, they can’t leverage role-based sharing or owner-based sharing rules the way Partner or Customer Community Plus users can. Instead, their record access is granted primarily via Sharing Sets, which give access to records that are related to the user’s Account or Contact (for example: “let the user see all Case records where Case.Contact = this user’s Contact”).
Key takeaway:
If a Customer Community user must see specific records, you configure a Sharing Set for each object to express the contact/account relationship that should grant access.

Why the other options are not correct (or are misleading)

B. “Any site users that require access to specific records have the proper Sharing Rule.”
Not appropriate for Customer Community. Owner-based sharing rules target roles/territories. Customer Community users don’t have roles, so you can’t target them with role-based sharing rules. (Criteria-based rules also can’t directly target high-volume customers without roles.) For Customer Community, use Sharing Sets, not sharing rules.
C. “All site users that require access to all records across all objects have the proper Sharing Set.”
This is both impractical and not how Sharing Sets are intended to work. Sharing Sets grant access based on a relationship (e.g., Account/Contact to a related record). They’re not a blanket “see everything” mechanism “across all objects.” You create object-specific Sharing Sets to define which related records are visible, object by object.
D. “All site users have the appropriate role assigned.”
Customer Community users do not have roles (roles are available for Customer Community Plus and Partner Community, which support role-based sharing). Expecting roles for Customer Community users is a common misconception.

Practical design tips for Customer Community sharing
Start with OWD = Private (External) on sensitive objects and then open access with Sharing Sets that map from User.Contact/User.Account to the target object’s lookup fields.
For Plus/Partner populations (if you ever add them), you can use roles + sharing rules—but keep Customer Community users on Sharing Sets.
If a user needs broader access than account/contact ties allow, reconsider whether they truly belong on Customer Community (vs Customer Community Plus), or redesign your data model/relationships to make Sharing Sets viable.

References:
Create a Sharing Set for Experience Cloud Site Users — how Sharing Sets work and when to use them.
Trailhead: Account Roles & Role Hierarchy (Experience Cloud external users) — notes that roles apply to Partner/CC+, not Customer Community.
Sharing Rule Considerations (Help Doc) — limitations around including high-volume/guest users in owner-based sharing rules.
Community Q&A / Guidance clarifying that Sharing Sets are for Customer Community (not Plus) and are the recommended visibility tool for that license.

Explanation:

Cloud Kicks is launching a public Experience Cloud site packed with both static assets like images, PDFs, videos, and CSS files and dynamic content pulled live from Salesforce such as record lists, user profiles, and real-time case updates. To make the site fast and reliable for visitors worldwide, they plan to use a Content Delivery Network (CDN), and the key benefit lies in performance through caching public resources. When CDN is enabled (which Salesforce does automatically for public sites), all static files get copied to a global network of edge servers located near major internet hubs. The first time a user visits the site, their browser downloads these files from the nearest edge server instead of traveling all the way to Salesforce data centers. On repeat visits, the browser often pulls the file directly from the user’s local cache or the edge server again, skipping Salesforce entirely. This reduces latency, speeds up page load times, and eases server load during traffic spikes. Dynamic content still flows securely from Salesforce, but since static assets usually make up 70–90% of page weight, the overall experience feels snappy and professional. The admin doesn’t need to configure anything extra—Salesforce handles the CDN integration behind the scenes, and it works seamlessly with Experience Builder templates.

Why Option A Is Incorrect
The statement says CDN helps consistency by attaching content timestamps as key-value pairs to both static and dynamic content. This is completely false. CDN does not modify files or add metadata like timestamps or key-value pairs. That kind of behavior belongs to version control systems or custom caching headers, not a CDN. Moreover, dynamic content is never cached long-term by a CDN because it changes per user or session. CDN only caches static, publicly accessible files with proper cache headers. Adding timestamps would break caching and slow things down.

Why Option B Is Incorrect
The claim that CDN helps availability by allowing remote cloning for dynamic resources is made up. CDN does not clone or replicate dynamic content. Dynamic pages like a user’s dashboard or live search results are generated on-the-fly by Salesforce servers. They contain sensitive or personalized data, so they bypass CDN entirely. Cloning dynamic resources would also violate security and privacy rules. CDN is strictly for static, public assets—nothing more.

Why Option D Is Incorrect
The idea that CDN improves reliability by allowing local cloning for static resources is also incorrect. CDN does not create “local clones” on a user’s device beyond the browser cache. It uses a distributed network of edge servers to serve cached copies from the closest geographic location. There is no concept of “local cloning” in CDN architecture. The reliability comes from redundancy across global servers, not local device storage.

References:
Salesforce Help – Content Delivery Network (CDN) for Experience Cloud
Trailhead – Optimize Performance with CDN

Explanation:

To share records owned by Customer Community users with internal users, the most efficient and declarative solution is to use a Sharing Set combined with a Share Group.

Here’s how it works:
A Sharing Set defines which records Customer Community users can access based on their account or contact relationship.
A Share Group extends access to those same records to internal users, such as support agents or managers.

By associating a Customer Community profile with the Sharing Set and linking it to a Share Group, Salesforce ensures that any record shared with the external user is also shared with the internal users defined in the Share Group. This setup is ideal for collaboration between customers and internal teams, especially in support or service scenarios.
This approach is declarative, scalable, and avoids the need for Apex sharing or complex rules. It’s configured in Setup → Digital Experiences → Sharing Sets, and Share Groups are defined within the Sharing Set configuration.

❌ Incorrect Option: B.
Owner-based sharing rules do not apply to Customer Community users, because these users do not have roles. Sharing rules based on roles only work for internal users or Partner Community users who are assigned roles. Since Customer Community users lack role hierarchy, this method is invalid for sharing their records.

❌ Incorrect Option: C.
A Share Group must be tied to a Sharing Set to function. Creating a Share Group without an associated Sharing Set will not share any records, because the Share Group has no context or source of shared records. This option is incomplete and technically incorrect.

❌ Incorrect Option: D.
While the “IsOwnedByExternalUser” field exists, it is not supported in criteria-based sharing rules. Salesforce does not allow this field to be used as a filter in declarative sharing rules. Therefore, this option is not viable for sharing records owned by Customer Community users.

📘 References
Salesforce Help: Share Groups and Sharing Sets
Salesforce Help: Sharing Sets Overview
Salesforce Help: Experience Cloud Record Access