Explanation:

This scenario involves two separate Salesforce organizations, both with their own Experience Cloud sites. The requirement is for customers in the Universal Containers (UC) org to access the Cloud Kicks (CK) site seamlessly. The best solution for this is to implement Single Sign-On (SSO) between the two Salesforce orgs.
Salesforce as an Identity Provider (IdP) and a Service Provider (SP):
One Salesforce org acts as the Identity Provider (IdP). This org is responsible for authenticating the users. In this case, the UC org, which already manages its own customers, would serve as the IdP. The other Salesforce org acts as the Service Provider (SP). This org trusts the IdP to authenticate users before granting them access to its services. The CK org would be the SP.
This setup, typically using the SAML protocol, allows a customer to log in to the UC site and then be seamlessly redirected to the CK site without needing to enter credentials again.
How the process works:
The UC admin enables the IdP feature in their Salesforce org and downloads the metadata.
The CK admin uses this metadata to configure the UC org as an Authentication Provider within their own org. They enable SAML and a Connected App is created automatically or manually in the IdP org.
The CK admin then adds this new Authentication Provider to the login settings for the CK Experience Cloud site.
When UC customers go to log in to the CK site, they will see an option to log in with UC. After authenticating through UC, they are granted access to the CK site.

Analysis of incorrect options

A. Create separate user accounts for UC customers in CK's Experience Cloud site, since SSO cannot be established between two Experience Cloud sites.
This is incorrect. SSO can and should be established between two Salesforce orgs for this purpose. Creating separate user accounts is a poor solution that leads to user confusion, duplicate data, and increased administrative overhead.

B. Use a third-party identity provider to establish SSO between the two Experience Cloud sites, since Salesforce can only be used as a service provider.
This is incorrect. While a third-party identity provider is a valid option, Salesforce can be configured to act as an Identity Provider. It is not limited to only being a Service Provider.

D. Create custom Apex handlers using the login method from the site class to sign in users from one community to the other.
This is a less scalable and more complex programmatic approach. While custom Apex handlers exist for advanced login processes, the standard declarative SSO configuration is the recommended best practice for this type of inter-org authentication. A consultant should recommend the declarative solution over a custom one when it meets the requirements.

Explanation:

For large organizations, the goal is to create a scalable, manageable, and secure sharing model. The recommended practices achieve this by isolating partner access and using efficient sharing mechanisms.

B. Create partner roles in a separate branch in your Role Hierarchy.
Why it's correct: Creating a separate, dedicated branch (or tree) for all partner roles isolates the partner sharing model from the internal employee sharing model. This prevents accidental data leakage where a partner user might inherit access to internal employee records (and vice-versa) through a poorly placed role in the main hierarchy. It simplifies management and enhances security.

C. Grant partner users access to the partner account using a Sharing Rule.
Why it's correct: In large orgs, manually sharing each partner account to its users is not scalable. A sharing rule is the recommended, automated way to handle this. You can create a criteria-based sharing rule that states: "Share all Account records where Type = 'Partner' with the 'Partner Role'." This automatically grants all users in the Partner Role access to the partner accounts they need, without manual steps.

Why the Other Options Are Incorrect

A. Create partner roles in the same branch in your Role Hierarchy.
Why it's incorrect: This is the opposite of the Salesforce recommendation. Placing partner roles within the same branch as internal roles creates a significant security and management risk. A partner role placed above an internal sales role would grant that partner user access to all the salesperson's records, which is almost never the intention. This practice is discouraged, especially in large orgs.

D. Reduce the number of roles to one to improve system performance.
Why it's incorrect: While having fewer roles can simplify a system, reducing it to a single role for all partners is not a recommended practice for large orgs. This "one-size-fits-all" approach destroys granularity in sharing. You lose the ability to control data access hierarchically between different partner managers and users. The role hierarchy is a core, performant feature of the platform, and designing it properly for business needs is more important than arbitrarily limiting the number of roles for a minor performance gain that is unlikely to be noticeable.

Key Concepts

Exam Objective: This question falls under "User Management and Access", specifically testing knowledge of best practices for designing a secure and scalable partner role hierarchy.
Core Concept: Partner Role Hierarchy Design and Sharing Automation. The key principles are isolation (separate branch) and automation (sharing rules).
Salesforce Help Reference: While not from a single article, these best practices are documented in various Trailhead modules and architectural guides. The Trailhead module "Control Access to Your Data with the Role Hierarchy" emphasizes the importance of a separate partner branch, and the documentation on sharing rules promotes their use for automating access.

Explanation:

When Universal Containers (UC) set up their customer portal for shipping management, they implemented External Account Hierarchy to control data access across related customer accounts. This feature is specifically designed for Experience Cloud sites and allows sharing rules to respect relationships between parent and child accounts — for example, a corporate headquarters (parent) can access data from its regional offices (children). In UC’s case, both Cloud Kicks and Northern Trail Outfitters were part of this hierarchy, likely with one being a parent or sibling of the other. Salesforce treats these hierarchical relationships as structural dependencies for external user visibility. As a result, merging two accounts that participate in an active External Account Hierarchy is explicitly blocked to prevent corruption of the sharing model. If the merge were allowed, child records, sharing rules, and portal role assignments could become orphaned or misaligned, leading to data access issues for customers. The system throws a clear error to protect data integrity, and this restriction is non-negotiable unless the hierarchy link is removed first.

Why Option A is Incorrect:
"Accounts with active Experience Cloud users cannot be merged with another account."
This statement is misleading and overly broad. Salesforce does allow merging accounts that have active Experience Cloud (portal) users, as long as those accounts are not part of an External Account Hierarchy. The presence of portal users alone does not prevent a merge. In fact, during a standard account merge, Salesforce automatically re-parents the portal users from the deleted (source) account to the surviving (master) account. This process is seamless and supported. The real blocker isn’t the users — it’s the structural dependency created by the External Account Hierarchy, which ties data access to account relationships in a way that merging would break. So while it might seem logical to blame active users, that’s not the root cause here.

Why Option B is Incorrect:
"The user trying to merge the accounts does not have the Merge Portal Roles permission."
There is no permission called "Merge Portal Roles" in Salesforce — this option is completely fabricated. The actual permissions required to merge accounts are:
Delete on Account (to delete the source record)
Merge Accounts (a standard user permission)
These apply universally, whether internal or external users are involved. There is no special "portal roles" merge permission because portal roles are managed automatically during account merges (users are reassigned). This option reflects a common misconception but has no basis in Salesforce functionality.

Why Option C is Incorrect:
"The user trying to merge the accounts does not have the System Administrator profile."
Being a System Administrator is not required to merge accounts. Any user with the Merge Accounts permission and Delete access on Account can perform a merge, regardless of profile. Custom profiles, integration users, or delegated administrators can all merge accounts if properly permissioned. Requiring System Administrator would be a major security and delegation anti-pattern. In real-world orgs, merge capability is often granted to sales ops or data stewardship teams via custom profiles — not just admins. So this option is technically false and operationally impractical.

References:
Salesforce Help: Merge Duplicate Accounts in Salesforce Classic → Confirms merge behavior and user reassignment.
Salesforce Help: External Account Hierarchies → States: "You can’t merge accounts that are in an account hierarchy used by Experience Cloud sites."
Experience Cloud User and Data Sharing Considerations → Explains how External Account Hierarchy impacts sharing and merge operations.

Explanation:

A. Partner Community User
The Partner Community User license is ideal for B2B environments that require complex record access. It fully supports advanced sharing features such as role hierarchy, sharing rules, manual sharing, and Apex-managed sharing. Users can have up to three external roles, enabling visibility up the hierarchy. For Cloud Kicks, where subscription data must be shared only with authorized customers, this license provides the flexibility to build precise and secure sharing logic. Partner Community Users can collaborate across teams while maintaining strict access control to customer subscription records.
D. Customer Community Plus Login User
The Customer Community Plus Login User license bridges the gap between basic self-service and full partner collaboration. Unlike standard Customer Community licenses, the Plus version supports sharing rules, role hierarchy, and manual sharing, allowing more advanced access management. This makes it well-suited for organizations like Cloud Kicks that must apply criteria-based sharing rules to custom objects (e.g., subscriptions). It also supports reporting, dashboards, and delegated administration, enabling customers to securely collaborate and view relevant shared records.

❌ Incorrect Answers
B. Customer Community Login User
This license supports only Sharing Sets and Groups, granting access based solely on direct Account or Contact relationships. It doesn’t allow sharing rules or hierarchy-based access, so it cannot meet Cloud Kicks’ advanced sharing requirements.
C. Customer Community User
This is the non-login version of the same basic license and has the same limitation — no support for advanced sharing features. It’s suitable for large-scale, self-service B2C portals, not for environments that require record-level collaboration or custom sharing logic.

References
Salesforce Help: Community User Licenses Comparison
Salesforce Help: External User License Types
Trailhead: Experience Cloud Sharing and Visibility

Explanation:

When a consultant is unable to view or retrieve the ExperienceBundle metadata in Salesforce for deployment purposes, the most common and likely root cause is that the “Enable ExperienceBundle Metadata API” setting has not been enabled in the org. This setting is required to expose Experience Cloud site metadata in a structured, deployable format via the Metadata API or source control tools like Salesforce DX.
ExperienceBundle is a metadata type that represents the structure and configuration of an Experience Cloud site, including branding sets, themes, pages, and navigation. It allows developers and consultants to deploy site configurations as code, making it ideal for CI/CD pipelines and version control. However, this feature is not enabled by default in all orgs.
To enable it:
Go to Setup.
Search for Digital Experiences | Settings.
Check the box labeled “Enable ExperienceBundle Metadata API”.
Save the changes.
Once this setting is enabled, the ExperienceBundle metadata becomes visible and retrievable using tools like Salesforce CLI, Change Sets, or Metadata API. Without this setting, attempts to retrieve or deploy ExperienceBundle will fail or result in missing metadata.

❌ Why the Other Options Are Incorrect
A. The experience has not yet been published.
This is not a requirement for ExperienceBundle visibility. ExperienceBundle metadata can be retrieved and deployed regardless of whether the site is published, as long as the metadata API setting is enabled.
B. A change set containing the Network needs to be deployed.
While deploying the Network (site container) is necessary for full site functionality, it is not a prerequisite for viewing or retrieving ExperienceBundle metadata. This option confuses deployment dependencies with metadata visibility.
D. A custom Experience template needs to be created.
ExperienceBundle works with standard and custom templates alike. The absence of a custom template does not prevent ExperienceBundle from being visible or retrievable. This option is irrelevant to the root cause.

References
Salesforce Help: Enable ExperienceBundle Metadata API
Salesforce Developer Guide: ExperienceBundle Metadata