Experience-Cloud-Consultant Practice Test Questions

Explanation

In Experience Cloud, audience targeting applies at multiple levels: the Page Level and the Component Level. For a user to see a component, they must be a member of the audience targeted at every level where targeting is applied.

Let's break down the scenario:

Page-Level Targeting:
The entire Home page is targeted to the "New York City" audience. This is the first gate.
Consequence: Only users who are in the "New York City" audience will ever see this specific version of the Home page. Users not in this audience will see a different version or a standard page.
Component-Level Targeting:
The Rich Content Editor component on that page is targeted only to the "Legal Department" audience. This is the second gate.
Consequence: Even if a user can see the page, they must also be in the "Legal Department" audience to see this specific component.

Therefore, a user must successfully pass through both gates:
Gate 1: Is the user in the New York City audience? (Yes/No)
Gate 2: Is the user in the Legal Department audience? (Yes/No)
Only users who answer Yes to both questions will see the Rich Content Editor component.

Why the Other Options Are Incorrect:

A. New York City audience members with the Legal Department sharing set:
This is incorrect and uses imprecise language. "Sharing set" is a specific Salesforce feature for sharing record access, which is not the mechanism used here for displaying components. The correct mechanism is audience membership. The logic of the statement is close, but it doesn't accurately reflect the specific, layered targeting system.

C. All Cloud Kicks Experience Cloud site members:
This is incorrect because it ignores both layers of audience targeting. The page itself is restricted, so only a subset of members (the NYC audience) can even see the page the component is on.

D. All New York City audience members:
This is incorrect because it ignores the component-level targeting. While all NYC audience members can see the page, the component has an additional, more restrictive filter that only includes the Legal Department.

Reference:
Salesforce Help: "Show Components to Specific Audiences" and "Assign a Page Variation to an Audience"
Core Concept: Audience targeting in Experience Builder is additive and restrictive. A user must be a member of all audiences assigned to the page variation and the component to see that component. Think of it as a series of filters that all must be passed.

Explanation:

Salesforce Experience Cloud has organization-wide limits on content moderation rules and rate limit rules, not per site.

As of current Salesforce limits:
Content moderation rules: Maximum 50 per org
Rate limit rules: Maximum 50 per org
(These are shared across all Experience Cloud sites within the org.)

Calculation for CK’s requirement
Cloud Kicks plans 5 sites, each needing:
3 content moderation rules → 5 × 3 = 15 rules
4 rate rules → 5 × 4 = 20 rules
At first glance, both numbers (15 and 20) are within the 50-rule org limits. However, the question context indicates that these are unique rules per site and that the consultant needs to “enable moderation and rate limit rules as part of their planning.”

This typically means that both types of rules are global, and each rule must be associated manually per site. While the number alone (15 + 20) doesn’t exceed the hard limit, each rule type counts toward the same global cap, and Salesforce documentation warns that these limits can be quickly reached when multiple sites each have their own sets of rules.

Hence, the best practice (and the exam-correct answer) is to notify stakeholders that both moderation and rate rules are subject to org-level limits and that they risk hitting them as they scale or modify rules across sites.

Why the other options are wrong
A. Implementing notify/freeze actions is part of configuration, not a pre-work consideration.
B. Content moderation rules do have org limits, so ignoring that is incorrect.
C. Rate rules aren’t the only ones with org limits; moderation rules are limited too.

Explanation:

Ursa Major Solar is leveraging Salesforce Experience Cloud’s moderation functionality to manage content and user interactions on its site. Moderation features are designed to maintain a safe, professional, and engaging community by controlling content, monitoring user activity, and enforcing community standards. Below is an explanation of why the selected options are correct and how they align with moderation goals:

B. Track flagging and moderation activity within the Experience site: Moderation functionality in Experience Cloud includes reporting and analytics tools, such as Insights reports, that allow administrators and moderators to track flagging activity (e.g., which posts or comments were flagged as inappropriate) and moderation actions (e.g., content removed or users warned). This helps Ursa Major Solar monitor the effectiveness of moderation efforts, identify problematic trends, and ensure compliance with community guidelines.
C. Allow members to flag posts, comments, files, and messages that are inappropriate or spam: A key feature of Experience Cloud moderation is enabling site members (authenticated users) to flag content—such as posts, comments, files, or private messages—that violates community rules or appears as spam. This empowers users to report inappropriate content, which moderators can then review and act upon, helping Ursa Major Solar maintain a high-quality community environment.
D. Designate specific users as moderators so that they can closely monitor the site: Experience Cloud allows administrators to assign specific users (e.g., internal employees or trusted partners) as moderators by granting them the “Moderate Community Content” permission or similar roles. Moderators can review flagged content, delete inappropriate posts, and manage user behavior, enabling Ursa Major Solar to closely monitor and control the site’s content and interactions.

Why Other Options Are Incorrect:

A. Allow members to remove other members from the Experience site if desired: This is not a feature of Experience Cloud moderation functionality. Only administrators or users with specific permissions (e.g., “Manage Communities”) can deactivate or remove users from the site. Moderation features focus on managing content (e.g., posts, comments) rather than user account management, so this is not a valid goal for moderation.
E. Give members Audience Targeting permissions within the Experience site: Audience targeting is a separate feature in Experience Cloud used to control the visibility of pages and components based on user criteria (e.g., profile, role, or location). It is not related to moderation functionality, which focuses on content oversight and user interaction management. This option does not align with moderation goals.

Additional Notes:
Moderation Tools: Ursa Major Solar can use features like keyword-based moderation rules, rate limits, and Einstein Content Moderation (if enabled) to further enhance content control.
Implementation: To achieve these goals, Ursa Major Solar should configure moderation settings in the Administration Workspace, assign moderator roles, and enable flagging options for members in the site’s Chatter or content settings.
Best Practices: Regularly review moderation reports, train moderators on community guidelines, and communicate clear rules to site members to encourage appropriate participation.

References:
Salesforce Help: Moderate Content in Experience Cloud Sites (Details moderation features, including flagging, tracking, and moderator roles).
Trailhead: Experience Cloud Moderation (Covers how to set up and use moderation tools to manage content and user interactions).
Salesforce Help: Set Up Moderation for Your Experience Cloud Site (Explains how to configure flagging, moderation rules, and assign moderators).

Explanation:

When using Single Sign-On (SSO) with Just-in-Time (JIT) Provisioning in Salesforce Experience Cloud, the Federation ID is the key identifier that links the user in the Identity Provider (IdP) to the user in Salesforce.

✅ D. Federation ID
This is the required unique identifier used by Salesforce to match incoming SSO assertions with user records.
During JIT provisioning, if a user does not already exist, Salesforce uses the Federation ID from the SAML assertion to create a new user.
It must be unique across all users in the org.

❌ Why the Other Options Are Incorrect

A. Standard:
Not a valid value for identifying users in SSO or JIT provisioning.
B. Username:
While usernames are important, JIT provisioning relies on Federation ID, not the username, for matching or creating users.
C. Entity ID:
This identifies the Identity Provider, not the user.

📘 References
Salesforce Help: Just-in-Time Provisioning
Salesforce Help: Configure SAML SSO for Experience Cloud

Explanation:

To allow Experience Cloud site users (members) to create their own tags (topics) and apply them to content, you need to grant two distinct permissions in the member's profile or permission set.

Create Topics (Option A):
This permission grants the user the ability to create new topics in the Salesforce org. Without this, a user can only use topics that already exist. This directly fulfills the requirement for "member-created topics."
Assign Topics (Option B):
This permission allows a user to associate (or "tag") an existing topic with a record or piece of content. In the context of Experience Cloud, this is the permission that lets a site user add a topic to a site page, a knowledge article, a feed post, or other supported objects. This fulfills the requirement to "tag site content."

When combined, these two permissions give site users the full capability to create new tags on the fly and apply them to content.

Why the Other Options are Incorrect
C. Tags Allowed:
This is not a standard permission that exists in Salesforce Setup. It is a distractor. The functionality for user-defined tags is handled entirely by the Salesforce Topics feature and its corresponding permissions.
D. Member Can Access Topics:
This is also an incorrect option. While it sounds plausible, it is not the actual name of a permission in Salesforce. The ability to "access" or see topics is typically granted by the "Read" permission on the Topic object or by the general sharing model of the site. The specific actions needed here are the proactive abilities to Create and Assign.

Reference
Salesforce Help: Enable Topics for Experience Cloud Sites
This documentation explicitly outlines that to allow members to create and assign topics, you must assign the "Create Topics" and "Assign Topics" permissions to their profile or permission set. These permissions are found under the Standard Object Permissions or Custom Object Permissions section when editing a Profile or Permission Set.

Explanation:

In Salesforce Experience Cloud, controlling the visibility of pages (such as those created for Northern Trail Outfitters' product) is managed through visibility settings in the Experience Builder. These settings determine which users can see specific pages based on criteria like user profiles, roles, or audiences. The three visibility options available for controlling page visibility in Experience Cloud are:

A. Audience:
This option allows the site manager to assign a specific audience to a page. Audiences are predefined groups of users based on criteria such as profile, role, location, or other user attributes. By assigning an audience, NTO can ensure that only users meeting the audience criteria (e.g., users in North America, EMEA, or Asia Pacific) can view the page. This is ideal for region-specific content visibility.
B. None:
This option sets the page to be hidden from all users, effectively making it invisible unless further modified. It’s useful for pages that are under construction, archived, or intended for future use but not currently accessible.
C. Default:
This option makes the page visible to all authenticated users of the Experience Cloud site (e.g., all site members with access to the site). It’s the broadest visibility setting and is used when no specific restrictions are needed beyond standard site access.

The other options are not valid:

D. Personal:
There is no "Personal" visibility option in Experience Cloud for page settings. While Salesforce supports personal tags or personalization in other contexts (e.g., personal tags in legacy setups), page visibility in Experience Cloud is controlled via audiences, not individual user personalization.
E. Visible:
There is no visibility option explicitly named "Visible" in Experience Cloud. The closest equivalent is the "Default" setting, which makes a page visible to all site members.

How This Applies to NTO’s Scenario:
NTO wants to control page visibility for a product with region-specific variations (North America, EMEA, Asia Pacific). The site manager can use:
Audience to create region-specific audiences (e.g., based on user location or profile) to ensure only users in the relevant region see the corresponding product page. Default for pages that should be visible to all site users (e.g., a general product overview page). None for pages that should be hidden, such as draft pages or region-specific pages not yet ready for release.

Reference:
Salesforce Help, "Control Page Access with Visibility Settings" (Winter '26): "In Experience Builder, you can set page visibility to Default (visible to all site members), None (hidden from all users), or Audience (visible to a specific audience based on user criteria)."

Explanation:

Zephyrus Relocation Services (ZRS) wants to build a partner portal that includes company information and branding on the Account Management page. The best Experience Cloud templates for this use case are:

1. Partner Central ✅
Purpose-built for Partner Relationship Management (PRM).
Includes components for lead distribution, deal registration, and account management.
Supports sharing CRM data with partners and customizing branding.
Ideal for channel sales and partner collaboration.
2. Build Your Own (LWR or Aura) ✅
Offers maximum flexibility for custom branding and layout.
Allows ZRS to design a fully tailored Account Management page.
Best suited for organizations with specific UI/UX requirements or custom data models.

❌ Incorrect Options
A. Help Center
Designed for customer self-service, FAQs, and case deflection.
Not suitable for partner collaboration or account management.
C. Customer Service
Focused on support interactions and case management.
Lacks built-in PRM features and partner-specific components.

References
Salesforce Help: Which Experience Cloud Template Should I Use?
Salesforce Help: Partner Relationship Management Template Requirements
Salesforce Help: Manage Partner Relationships with Experience Cloud Sites

Explanation:

When you create a public Experience Cloud site, Salesforce automatically performs a number of setup actions to manage guest user access.

A. Creation of a guest role: A role is automatically created for the guest user to facilitate sharing via the role hierarchy. While roles are typically for authenticated users, a guest role is created to ensure data can be shared with the guest user via sharing rules, which is necessary for a public site.
C. Creation of a guest profile: A dedicated guest user profile is automatically created to define the permissions for unauthenticated users accessing the public site. This profile controls which objects, fields, and pages the guest user can see.
E. Creation of a guest user record: A special guest user record is automatically created and assigned to the guest profile. This record acts as the user for anyone who is not logged in, and it's what you use to configure site-wide access and sharing.

Why other options are incorrect
B. Creation of moderation criteria that are applied only to guest users: Moderation criteria are not created automatically. These are custom settings that an administrator must configure manually to manage content on the site.
D. Creation of sharing mechanisms that are available only to guest users: While a guest user's profile and record are created, and sharing rules can be used to grant them access, the specific sharing mechanisms themselves are not automatically created. The admin must set up sharing rules to grant guest users access to specific records.

Explanation:

Why internal Salesforce licenses are the right fit for CK’s employee sites
Because Cloud Kicks’ employees already work in Sales and Service, they are internal users with standard Salesforce user licenses (e.g., Salesforce, Sales Cloud, Service Cloud, Platform). Salesforce explicitly states that internal users primarily access the platform via Lightning/Classic and can also access Experience Cloud sites—you don’t purchase external “community” licenses for them. You simply add their profiles or permission sets as site members so they can authenticate with their normal org credentials and see the social intranet and HR help experiences you build. This approach centralizes identity, preserves existing permission models, and avoids duplicative licensing.

Why option C (Customer Community) is not appropriate
Customer Community (and other Experience Cloud external licenses like Customer Community Plus or Partner Community) are designed for external audiences—customers, partners, or prospects—who do not otherwise have access to your core Salesforce org. They’re licensed and governed differently (login- vs. member-based models, different sharing features), and Salesforce lists them as licenses for external users, not for employees who already have internal access. Assigning such licenses to employees would add cost and complexity without benefit.

Why option A (Salesforce Authenticated Site) is not the right choice
“Authenticated Website/Authenticated Site**” refers to a legacy Sites license family intended for public websites with optional login, not for modern employee access to Experience Cloud. It’s unrelated to granting your internal workforce access to an intranet or HR portal and isn’t how you should license employees on Experience Cloud in 2025.

How to grant employees access in practice (what CK’s admins will do)
In Experience Builder → Administration → Members, add the profiles or permission sets used by Sales and Service staff. After you add a profile or permission set, all users assigned to it become site members automatically. This lets CK target the intranet and HR help experiences (pages, audiences, permissions) to the right employee groups using the same identity and governance model they already use in Salesforce.

Bottom line
Keep CK’s workforce on their existing internal Salesforce user licenses (your org may be on the Unlimited edition, but the key is “internal license,” not an external Experience Cloud license). That gives seamless, compliant access to the social intranet and HR help site—no Customer Community or legacy Authenticated Site licensing needed.

Explanation:

The process for creating an external (partner or community) user is tightly coupled with the Contact record. A user must be associated with a single Contact, and that Contact must be associated with an Account that has been enabled for partner collaboration.

Here is the standard, step-by-step process, with the final step being the one the question asks for:

Prerequisite: Ensure a Contact record exists and is associated with an Account that is enabled as a Partner Account.
Navigate to the Contact: The administrator goes to the specific Contact record for the person who needs partner access.
Final Action: On the Contact detail page, the administrator clicks the "Manage External User" button. From the dropdown that appears, they then select "Enable Partner User". This action opens the new user form, pre-populating the Contact and Account information.
Provide User Details: The administrator then fills in the remaining user details (like username, email, and profile) and saves the record.

The question asks for the step performed right before providing user details and saving. This is precisely the action described in Option D.

Why the Other Options are Incorrect
A. Click "Manage Partner User” on the Contact detail page, then click “Enable Customer User”. This is incorrect for two reasons. First, the button is named "Manage External User," not "Manage Partner User." Second, "Enable Customer User" is used for creating Customer Community users, not Partner users.
B. Click "Manage Partner User” on the Account detail page, then click “Enable Partner User”. This is incorrect because the process is initiated from the Contact record, not the Account record. While the Account must be a partner account, the user creation itself is done per Contact.
C. Click "New" on the User Setup page in Lightning Experience. While it is technically possible to create any user from the User Setup page, this is not the standard or recommended method for creating external users. Doing it this way requires manually linking the correct Contact and selecting the correct external user license, which is error-prone. The prescribed, foolproof method is to start from the Contact record, which ensures all the necessary associations are made automatically.

Reference
Salesforce Help: Create Experience Cloud Users
This documentation outlines the standard process, which is to navigate to the Contact record and use the "Manage External User" button. It emphasizes that this is the primary method for creating users with Customer Community, Partner Community, or External Identity licenses.