Explanation:

The key requirements are:
1. A site for customers (not partners).
2. Access to knowledge articles (manuals, FAQs).
3. Secure, logged-in access to customer-specific data (Contracts object).
4. The ability for customers to update their information (billing info).

Let's evaluate the options:

A. Customer Service: This template is optimized for customer service and support cases. While it includes Knowledge and Case management, its primary focus is not on account-specific data like contracts and billing.

B. Customer Account Portal: This template is specifically designed for this use case. It provides logged-in customers with a personalized experience to view their account data, contracts, and assets, and to update their personal and billing information. It also includes access to Knowledge for self-service.

C. Partner Central: This template is designed for partner relationship management (PRM), including deal registration, lead management, and MDF requests. It is not intended for a company's end-customers.

D. Help Center: This is a public-facing template primarily for unauthenticated Knowledge access. It does not support the requirement for logged-in users to access their specific contract and billing data.

Reference: The "Templates" module in the Experience Cloud Consultant exam guide differentiates the use cases for each standard template. The Customer Account Portal is explicitly noted for scenarios involving customer account management and personalized data access.

Explanation:

A. The Salesforce Administrator is not assigned a role in Salesforce.
A Salesforce administrator must have a defined role in the role hierarchy to be able to create external users, including partner users. If the admin user's record does not have a role assigned, the option to create a partner user from a contact will be unavailable.

C. The account record associated with the contact record is not enabled as a partner.
Before you can enable a contact as a partner user, the contact's parent account must be enabled as a partner account. The "Enable Partner User" action will not appear on a contact record if its associated account does not have partner status.

Why other options are incorrect

B. The Salesforce Administrator is not a member of the Partner Community:
An administrator does not need to be a member of the partner community to manage external users. Their ability to create external users is tied to their profile, permissions, and role within the internal Salesforce organization.

D. The Salesforce administrator is not marked as a delegated administrator on the partner account:
A delegated administrator on a partner account has the permissions to manage users within that partner account, but this is not a requirement for an internal Salesforce administrator to create the initial partner user. An internal admin's ability to create the user is governed by their own permissions and role, and the partner account's status.

Explanation:

Data Category Visibility is the most effective way to control which Knowledge articles users can access in Salesforce. It allows administrators to assign visibility rules based on roles, profiles, or permission sets, ensuring that users only see articles relevant to their function or group. For example, support agents working in the “Solar Panels” division can be restricted to articles tagged with that category, while agents in “Battery Storage” see a different set. This keeps content targeted and secure.
The visibility settings are dynamic — if a user’s role or profile changes, their access updates automatically. This is especially useful in Experience Cloud, where external users like partners or customers need tailored access. Data Category Visibility also supports hierarchical structures, so you can nest categories and manage access at multiple levels. For Ursa Major Solar, this means they can confidently segment content for different user groups across portals without needing complex sharing rules or Apex logic. It’s scalable, declarative, and built for multi-audience Knowledge delivery.

❌ Incorrect Option: B. Content Management
Content Management in Salesforce is all about organizing and publishing content — not controlling who sees it. It helps teams create articles, manage versions, translate content, and push updates to Experience Cloud sites. However, it does not restrict visibility based on user roles or permissions. You can use it to structure and deliver content, but not to restrict who sees what.
For example, you might use Content Management to publish an article about solar panel maintenance, but without Data Category Visibility or sharing rules, that article could be visible to all users with access to Knowledge. This makes Content Management a publishing tool, not a security or access control feature. If Ursa Major Solar relied solely on Content Management, they’d be missing the ability to tailor article visibility for different user groups. So while it’s critical for content lifecycle management, it doesn’t solve the problem of restricting article access based on user attributes.

❌ Incorrect Option: C. Automatic Topic Assignment Automatic Topic Assignment is a helpful feature that tags articles with relevant topics based on their content. This improves search relevance and helps users discover articles more easily. For instance, an article about “solar panel installation” might automatically be tagged with “Installation” or “Solar Panels,” making it easier to find through search or topic filters.
However, this feature does not restrict access to articles. It’s purely about enhancing discoverability, not managing visibility. Whether a user can view an article still depends on Data Category Visibility or sharing rules. Automatic Topic Assignment is useful for organizing content and improving the user experience, but it doesn’t offer any security or permission-based filtering. It’s a useful tool, but not the right answer when the goal is to restrict article access.

❌ Incorrect Option: D. Org-Wide Defaults
Org-Wide Defaults (OWDs) are a foundational part of Salesforce’s record-level security model. They define the baseline level of access users have to records they don’t own, such as Accounts, Opportunities, or Cases. For example, setting the OWD for Accounts to “Private” means users can only see records they own unless sharing rules grant additional access.
However, Knowledge articles don’t follow the same ownership model. Their visibility is managed through Data Categories, channel settings, and publication status, not OWDs. You can’t use OWDs to say “Only support agents can see these articles.” That’s not how Knowledge works. So while OWDs are essential for securing standard and custom objects, they’re not relevant for controlling Knowledge article visibility — making this option incorrect.

📘 References
Salesforce Help: Control Access to Knowledge Articles Using Data Categories
Salesforce Help: Data Categories Best Practices
Salesforce Help: Topics for Knowledge Articles
Salesforce Help: Org-Wide Defaults Overview
Salesforce Help: Content Management in Experience Cloud

Explanation

Why this is correct:
In Experience Cloud (Partner-style sites), “Super User Access” lets external users see records owned by other users in the same partner account who are in the same role or any lower role. That covers both peers (same role) and subordinates (lower roles)—exactly the gap you’re seeing.

Why the others are wrong:

B. Put managers in the Executive role
Moving them higher in the partner role hierarchy would allow visibility down the hierarchy (subordinates) but not across to peers in the same role at the same level in another branch. It doesn’t solve peer visibility.
C. Create a Sharing Set
Sharing Sets are for Customer Community/Customer Community Plus style access (account/contact-based) and aren’t intended to grant peer visibility among partner users. They don’t solve “see my peers’ records.”
D. Create a Sharing Rule
You could build owner-based sharing rules role-to-role, but this is heavier to maintain and still may not comprehensively cover all needed objects/peer cases. The platform provides Super User Access precisely for this partner visibility requirement.

References:
Grant Portal Super User Access to Partner and Customer Users (what Super User does and who it applies to).
Partner User Roles overview (Partner Executive/Manager/User and how hierarchy works).
Create a Sharing Set for Experience Cloud Site Users (scope of Sharing Sets—why it doesn’t fit here).

Explanation:

This question deals with a legacy and generally discouraged configuration. The modern best practice is to use featured external roles (like "Customer Community" or "Partner Community" licenses) which automatically create corresponding user profiles. However, it is possible to use standard internal profiles (like "Standard User") for external users in certain limited scenarios.

A. Correct: This is an org-wide setting that must be enabled before any standard profile can be used for an external Experience Cloud user. This setting is found in Setup -> Experience Cloud Settings -> Allow using standard external profiles for self-registration, user creation, and login.

B. Incorrect: There is no such permission or setting on a Permission Set. The control is at the organization level, not the user level.

C. Incorrect: This setting does not exist on an individual standard profile. The enabling mechanism is the global setting mentioned in option A.

D. Incorrect: While a login flow license might be involved in other configurations, the specific requirement to use a standard profile is governed by the global setting, not the type of license used for the user.

Reference: This is a specific, albeit less common, configuration detail. It is covered in the Salesforce Help article "Enable Standard Profiles for External Users". The key takeaway is that it requires a master switch in Setup to be turned on.