Explanation:

A. Select a permission set for a given site:
In the Experience Cloud Site Administration Workspace (under Members), you control which users can access the site by listing the Profiles and/or Permission Sets that are members of that site. To restrict a user to only one site, you must:
Add the common Profile to NO site's membership list.
Add the specific Permission Set (e.g., "Site A Access") to the membership list of only one site (e.g., "Site A").
Assign the correct Permission Set to the individual customer user records.
C. Create a permission set:
You should create a separate Permission Set for each customer-facing site (e.g., "Site A Access," "Site B Access," etc.). Permission Sets are designed to grant additional permissions to users beyond what their Profile provides, which makes them ideal for granting site-specific access without changing the single common Profile.

By following this method, the user's Profile (the single common one) grants them base permissions, and the Permission Set acts as the key to unlock access to their specific site, preventing them from accessing any other site.

❌ Incorrect Answers and Explanations

B. Edit the applicable user profile:
Editing the single, common profile to grant site access would automatically grant all users with that profile access to all sites, which violates the requirement that "No customer has access to more than one site."
D. Select the profile for a given site:
This refers to adding the Profile to the Site's Membership list. Since UC has only one profile for all customers, selecting this profile for a given site's membership would grant all users that single profile access to that site. If selected for multiple sites, all customers could log in to all sites. The Profile must be kept off the membership list, and a more granular method (Permission Sets) must be used to restrict access.

Explanation:

This question tests knowledge of Experience Cloud's native integration capabilities with external Content Management Systems (CMS).
The requirement is clear:
Ursa Major Solar wants to render a header and footer from an external CMS into their Experience Cloud site.
CMS Connect is a pre-built, out-of-the-box feature of Experience Cloud designed specifically for this purpose. It allows you to seamlessly integrate content from supported external CMS platforms (like Adobe Experience Manager, Contentful, WordPress, etc.) and surface that content directly within your digital experience using a standard component.
By using CMS Connect, UMS can manage its global header and footer in its preferred external CMS (where they might already be managing their main corporate website) and have those elements dynamically appear in their Salesforce Customer Portal, ensuring brand consistency across all digital touchpoints.

Why the Other Options Are Incorrect
A. Developer Console:
The Developer Console is an integrated development environment (IDE) used for writing and debugging Apex and Lightning code (Aura/LWC). While a developer could theoretically build a custom integration to an external API to fetch header/footer content, this would be a complex, custom-coded solution. CMS Connect is the declarative, supported, and much simpler standard feature designed to accomplish this exact task.
B. Compact Header Properties:
This is a feature related to the Mobile App for Experience Cloud. It controls the appearance of the header (like its color and visibility) within the Salesforce mobile app, not the integration of content from an external CMS into a web portal.
C. Rich Content Editor:
The Rich Content Editor (RCE) is a tool for formatting text within rich text fields, Knowledge articles, and other areas inside Salesforce. It is for creating and editing content within Salesforce, not for pulling in and rendering structured content like a full site header and footer from an external system.

Key Concepts:
Exam Objective: This question falls under "Experience Builder and Branding”, specifically testing knowledge of content integration and site composition features.
Core Concept: CMS Connect. This is the key feature for integrating external content management systems.
Salesforce Help Reference: The primary resource is the "CMS Connect" section of the Salesforce Help. It states:
"With CMS Connect, you can surface content from an external content management system in your Experience Cloud site. Use the CMS Connect component to display content such as headers, footers, and promotional banners from an external CMS."

Explanation:

Why it’s correct
Create an owner-based sharing rule that shares records owned by DR’s partner roles with NMH’s partner roles/public group (read or read/write as required). Sharing rules are the standard way to open visibility between groups of external users (e.g., different partner accounts) beyond the OWDs and role hierarchy.

Why the others are wrong
A. Role Hierarchy — The hierarchy grants access upward within a role tree, not across different partner accounts. It doesn’t solve “NMH needs access to DR-owned records” by itself.
B. Sharing Set — Sharing Sets grant access when a record’s Account/Contact matches the logged-in user’s Account/Contact; this fits self-service/customer scenarios, not cross-account partner-to-partner sharing.
D. Super User — Partner Super User access is limited to records owned by other partner users in the same partner account (and certain objects). It won’t grant NMH users access to DR’s records.

Implementation tip
Create a public group for NMH social workers and an owner-based sharing rule that shares DR realtors’ records (by DR partner role/role & subordinates) with that group. Trailhead shows this exact pattern for letting one partner account see another’s records.

Explanation:

✅ A. Components in the template header and footer sections cannot be assigned to an audience.
This is a critical limitation in Experience Cloud. While Criteria-Based Audiences allow you to personalize content by assigning components to specific user segments, components placed in the template’s header and footer regions cannot be audience-targeted. These areas are considered global and are shared across all pages using the template. As a result, Salesforce restricts audience-based personalization in these regions to maintain consistency and avoid rendering issues across the site. This limitation is especially important when designing branded experiences or tailoring navigation for different user groups.

✅ C. Up to 2,000 audiences can be created.
Salesforce imposes a limit of 2,000 audiences per org. This is a generous limit, but it’s essential to plan and manage audience definitions carefully to avoid hitting this ceiling. Each audience can be defined using multiple criteria types, such as user profile, location, domain, record fields, or custom user object fields. However, creating too many granular audiences can lead to complexity in managing visibility rules and performance degradation. Therefore, Salesforce recommends consolidating audiences where possible and using broader criteria when appropriate.

✅ D. Domain criteria are not available in sandbox or Developer Edition orgs.
This is a well-documented limitation. Domain-based audience criteria, which allow you to personalize content based on the domain a user uses to access the site (e.g., partners.example.com vs. customers.example.com), are not supported in sandbox or Developer Edition environments. This means you cannot test domain-based personalization in lower environments. Salesforce does not currently offer a workaround for this limitation, and contacting Salesforce support (as suggested in option B) is not a valid solution. This makes option B incorrect, as it implies a workaround that doesn’t exist.

❌ Why the Other Options Are Incorrect

B. Salesforce must be contacted if you need to use the domain criteria in sandbox or Developer Edition orgs.
This is incorrect. While domain criteria are indeed unavailable in sandbox and Developer Edition orgs, Salesforce does not offer a support-based workaround to enable them. The limitation is hardcoded, and contacting Salesforce will not change this behavior. Therefore, this option is misleading.
E. Record Type criteria cannot be assigned to a component.
This is incorrect. Salesforce does support using Record Type as a criterion when defining audiences. For example, you can show different components on a record page based on the record type of the viewed record. This is particularly useful for tailoring page layouts and messaging based on business processes or customer segments.

📘 References
Salesforce Help: Criteria Types and Conditions for Audience Creation
Salesforce Help: Domain Criteria Considerations

Explanation:

Why it’s correct:
In Experience Cloud with partner account roles (Partner Manager above Partner User), record access rolls up the role hierarchy, not sideways. So the creator (the child-account Partner User) and the Partner Manager in the same child account (their manager) can access the case.
With an External Account Hierarchy, access also rolls up to the highest user role at the parent account, which (with two roles) is Partner Manager. Parent-account Partner Users don’t get access by default, and peers at the child account don’t either.

Why the others are wrong

B — adds access for peers at the same role and Partner Users at the parent account.
In Salesforce, role-hierarchy sharing only grants access upward (to roles above the record owner). It does not grant lateral access to peers at the same role. Peers only see each other’s records if you add something extra (e.g., Super User permission, sharing rules, Sharing Sets), which the scenario doesn’t state. Likewise, at the parent account, only users in roles above the child’s role get access via the hierarchy—parent-level Partner Users are not above the child owner, so they aren’t included.
C — still includes peers in the Partner User role.
Same reasoning: the standard role hierarchy doesn’t share sideways to peers; it shares upward (owner → Partner Manager in the same child account, and then up the external account hierarchy). To give peers visibility, you’d need a separate mechanism (e.g., Partner Super User or a sharing rule), which isn’t part of the prompt.
D — grants access to Partner Users at the parent account.
With External Account Hierarchy, access “works like Salesforce role hierarchies”: users in higher roles get access to records owned by users in lower roles beneath them in the hierarchy. At the parent node, the role that’s above a Partner User (with two roles enabled) is Partner Manager—not Partner User. So parent-level Partner Users aren’t included by default.

Side note:
If CK had enabled Partner Super User permission for the creator’s account, peers could potentially see each other’s Cases—but that’s explicitly an optional feature and not implied in the question.

References
Salesforce Help: Partner User Roles (Overview) — how partner account role hierarchies work (sharing is upward, not lateral).
Salesforce Help: Configure an External Account Hierarchy — “work like Salesforce role hierarchies”.
Trailhead Project: Set Up Account Roles and the Role Hierarchy — example with two roles: Partner User and Partner Manager.
Salesforce Help: Portal/Partner Super User Access — peers can see others’ records only if Super User is enabled (not assumed here).