Explanation:

Salesforce AppExchange is the official marketplace where Salesforce and its partners publish Lightning Bolt Solutions—prepackaged Experience Cloud templates (plus themes, pages, flows, and optional apps) that you can install and adapt quickly. Bolts are designed specifically to jump-start implementations by providing ready-made site structures for use cases like employee service hubs, partner portals, or customer self-service. For Bloomington Caregivers, AppExchange is the right place to discover, compare, and install vetted Bolt solutions, complete with listings, documentation, screenshots, and version information. From there, admins can install a Bolt into a sandbox, tailor branding and data connections, and move toward production faster than building from scratch. In short, when you hear “Lightning Bolt,” think “find it on AppExchange,” because that’s the canonical distribution channel Salesforce provides for reusable Experience Cloud solution templates.

❌ Explanation for Incorrect Answers

B. Salesforce Accelerator Directory
“Accelerators” are guided advisory engagements provided by Salesforce experts to help you achieve specific outcomes (e.g., design reviews, best-practice sessions). They are services, not packaged templates. While accelerators can help you implement a community faster, they are not the source for Lightning Bolt artifacts you can install.

C. Salesforce Accelerator Catalog
Similar to the directory, the Accelerator Catalog lists engagement offerings, not installable Bolt templates. You might find recommendations and guidance there, but you won’t be able to download or install Lightning Bolt solutions from this catalog.

D. Salesforce Connect
Salesforce Connect is a data virtualization/integration feature that lets you access external data via OData and other adapters as external objects. It has nothing to do with discovering or distributing Lightning Bolt solutions. It’s great for surfacing external data in your org, but it’s not a marketplace or template repository.

References
AppExchange: Lightning Bolt Solutions — Browse and install Bolt templates for Experience Cloud.
Salesforce Help: Package and Distribute a Lightning Bolt Solution — How Bolts are built and distributed (via managed package/AppExchange).
Salesforce Help: Lightning Bolt Solutions Overview — What’s included in a Bolt and typical use cases.
Trailhead: Build and Distribute with Lightning Bolt — Hands-on module explaining creation and reuse of Bolt solutions.

Explanation:

When an admin enables the Reputation feature for an Experience Cloud site, the system automatically initializes with a set of default, out-of-the-box settings to get the program started immediately.

D. Default point system and set of reputation levels become available:
This is the primary automatic action. The system immediately provides a pre-configured point system (e.g., points for getting a best answer, liking a post) and a set of reputation levels (e.g., New User, Active User, Expert) based on those points. This gives the site manager a fully functional starting point that can later be customized.

B. Inactive and active members are assigned default reputation points:
Upon activation, the system performs a one-time assignment of reputation points to all existing members. All members, regardless of their previous activity, are set to a baseline starting point (typically 0 or 1 point). This ensures every member is placed within the new reputation level framework from the moment it's enabled.

Why the Other Options Are Incorrect
A. Customer portal members gain the ability to provide badges to other members:
This is incorrect. Badges and Reputation are two separate features. Badges are visual icons awarded for specific achievements. The ability to award badges is typically an administrative or managerial privilege. Enabling Reputation does not automatically grant all community members the right to give badges to each other.

C. Chatter influence is removed from the Contribution section on the Profile page:
This is incorrect and describes the opposite of what happens. Chatter Influence is the internal Salesforce scoring system. When you enable the Experience Cloud Reputation system, it replaces the Chatter Influence score on the user's profile within the community. The Contribution section now displays the new community-specific Reputation points and levels, not that Chatter Influence is "removed" entirely from Salesforce.

References:
Exam Objective:
This question falls under "Community Management”, specifically testing the configuration and behavior of the Reputation system.
Core Concept:
Enabling Reputation. The key takeaway is that enabling the feature activates a default, ready-to-use system and initializes all existing members.
Salesforce Help Reference:
The key article is "Set Up Member Reputation for Your Experience”. It explains:
"When you enable reputation, a default point system and set of reputation levels become available... When you activate reputation, all inactive and active members are assigned the number of points set for the first level."

Explanation:

Dreamscape Flowers (DF) is expanding its digital footprint by launching multiple Experience Cloud communities—for flower growers, franchisees, and B2C customers. To scale this initiative efficiently across subsidiaries, DF can leverage Lightning Bolt solutions, which are designed to package and deploy reusable community templates.

✅ A. Lightning Bolts can be distributed and reused
Lightning Bolt solutions are modular templates that bundle together:
Page layouts
Themes and branding
Components
Data models
Apps and flows
Once created, a Lightning Bolt can be shared across orgs, installed from AppExchange, or reused internally to spin up new communities quickly. This makes it ideal for DF’s subsidiaries, who can adopt DF’s proven community structure without rebuilding from scratch.

✅ B. Lightning Bolts can help reduce implementation time
By using Lightning Bolt templates, DF avoids the need to manually configure each new community. Instead, they can deploy a pre-built solution that includes all necessary components and branding. This dramatically reduces setup time, accelerates go-to-market efforts, and ensures consistency across sites.
Lightning Bolts are especially useful for organizations undergoing digital transformation, where speed and scalability are critical. They allow consultants and admins to focus on customization rather than foundational setup.

❌ Why the Other Options Are Incorrect

C. Lightning Bolts can help minimize licensing and provisioning cost
This is incorrect. Lightning Bolts are deployment tools, not licensing mechanisms. They do not affect the cost of Experience Cloud licenses or provisioning. Licensing is based on user type and volume, not on how the site is built.

D. Lightning Bolts can help organize, manage, and reuse digital content
This is misleading. Lightning Bolts package site structure and metadata, but they do not manage digital content like CMS items, images, or documents. Content management is handled separately via Salesforce CMS or external integrations.

References
Salesforce Help: Lightning Bolt Solutions Overview
Trailhead: Build and Distribute Lightning Bolt Solutions

Explanation:

To let unauthenticated visitors execute a flow from a public Experience Cloud page, Salesforce requires that guest access to flows be explicitly enabled and the flow exposed to the site’s Guest User. Historically, the quickest enablement step was turning on the “Enable Lightning Flows for Guest Users” setting (and then granting access to the specific flow for the site’s guest profile and placing the Flow component on a public page). This allows the Experience Builder page to render the Lightning runtime for flows and lets the guest session invoke the flow engine. From there, you still control which flows the guest can run using Enabled Flow Access on the Site Guest User Profile, and you secure object/field access (often keeping the screen flow in user context and moving sensitive DML into a subflow that runs in system context with careful, least-privilege design). In short, the setting in Setup is the gate that allows guest execution of Lightning flows on public sites; without it, the guest session won’t be able to start the flow even if you add the component to the page. (Note: Salesforce later moved toward granular, per-flow access for guests; the core idea remains that you must explicitly enable guest access to flows and grant the guest profile access to the specific flow(s).)

❌ Explanation for Incorrect Answers

A. Assign a single screen to multi-step flow and give the guest user access via page layout.
Page layouts don’t control flow execution for guest users, and changing a multi-step flow to “a single screen” doesn’t affect whether a guest can start it. Public access is governed by guest access settings and flow access, not page layouts. The guest profile must be explicitly granted access to the flow, and the site must be configured to allow guest flows.
B. Save the flow with the “System Context Without Sharing—Access All Data” option.
This setting controls the security context the flow runs in (bypassing user perms), but it doesn’t enable a guest to run the flow in the first place. You can still be blocked at launch time if guest-flow access isn’t enabled and the guest profile isn’t granted access to the flow. Also, running entire screen flows “without sharing” can be risky; Salesforce recommends using granular access and, if needed, isolating sensitive DML in subflows rather than flipping the whole screen flow to system context.
D. Convert multi-step flow into individual flows and give the guest user access to each flow separately.
Breaking one guided, multi-step screen flow into multiple flows doesn’t solve the core problem of guest execution rights. You would still need to enable guest access to flows and grant the guest profile access to each flow. Splitting the flow only adds friction and navigation complexity without providing the required permission model.

References
Allow Guest Users to Access Flows (Experience Cloud Help): steps to enable guest flow access and configure the guest profile.
Require Granular Flow Permissions for Experience Cloud Guests (Salesforce Help): grant individual flow access to guest users.
Run Flows in System Context Without Sharing (Release Notes): what the “system context without sharing” option does (and its implications).

Explanation:

When No More Homelessness (NMH) launched their public Experience Cloud site, they enabled unauthenticated (guest) user access so anyone on the internet could view knowledge articles without logging in. However, the Support team discovered that some articles are missing from search results for guest users — even though they appear for authenticated users. This is a common issue in public Knowledge bases, and the root cause is article-level visibility settings, not profiles, permission sets, or organization-wide defaults (OWDs). Salesforce Knowledge uses a dual-layer access model:
Org-level enablement (Knowledge must be turned on and public access enabled in the site).
Article-level sharing via the "Visible in Public Knowledge Base" checkbox.
For an article to appear in guest user search, topic pages, or recommendations, this checkbox must be selected on the individual article record (or via Data Categories with public visibility). Without it, the article is treated as internal-only, regardless of OWDs or profiles. This setting is the only direct, Salesforce-supported method to expose specific articles to unauthenticated users. NMH should audit all articles, bulk-edit via Data Loader or List Views, and ensure this field is checked for any article intended for public consumption. This approach gives granular control — perfect for organizations that publish both public and internal/support-only content.

Why Option B is Incorrect: "Create a custom permission set for Public access."
Permission sets control user capabilities (e.g., "Edit Articles," "Manage Topics"), but they do not govern record-level visibility for guest users. Even if a permission set grants "Knowledge User" access, guest users do not use permission sets — they operate under the site’s guest user profile, which has extremely limited, hardcoded permissions. Moreover, record sharing for guest users cannot be extended via permission sets. This option misunderstands how Salesforce isolates guest access for security. Permission sets are powerful for authenticated external users (e.g., partners, customers), but irrelevant and ineffective for public Knowledge visibility.

Why Option C is Incorrect: "Select 'Public' organization-wide default for the article type at the org level."
This option is technically impossible — Knowledge article types do not have organization-wide defaults (OWDs). OWDs apply to standard and custom objects like Account, Case, or custom objects — but not Knowledge articles. Article sharing is controlled exclusively through:

"Visible in Public Knowledge Base" checkbox
Data Category visibility
Channel settings (e.g., Public, Partner, Customer)

Setting OWD to "Public" has no effect on Knowledge. Attempting this would result in confusion, as admins would search in vain for an OWD setting that doesn’t exist. This is a frequent exam trap based on misunderstanding Knowledge’s unique sharing model.

Why Option D is Incorrect: "Create a custom profile for Public access."
While the guest user profile is indeed critical (and auto-generated when public access is enabled on the site), you cannot create or modify a custom profile for guest users. The guest profile is system-managed, read-only, and restricted to minimal permissions (e.g., Read on Knowledge object, CRED on public custom settings). You cannot assign custom profiles to guest users or use them to control article visibility. Profiles define object and field access, but record-level sharing for guest users is governed solely by the "Visible in Public Knowledge Base" setting. Creating a custom profile would be a futile exercise with zero impact on the reported issue.

Step-by-Step Fix for NMH
Enable Public Access in Experience Cloud Site → Site Settings > Public Access > Allow guest users to view Knowledge articles
Go to Knowledge Articles → Open articles not showing in search
Edit Article → Check "Visible in Public Knowledge Base" → Save
Bulk Update (Optional) → Use List View + Inline Editing or Data Loader to update multiple articles
Verify Data Categories (if used) → Ensure categories are marked Visible in Public Knowledge Base Republish Articles (if draft)
Test as Guest User → Use Preview as Guest or incognito browser

References:
Salesforce Help: Make Articles Visible to Guest Users
→ States: "To make an article visible to guest users, select Visible in Public Knowledge Base on the article."
Knowledge Base Setup for Public Sites → Confirms no OWD, no profiles/permission sets for guest article sharing.
Trailhead: Set Up Knowledge for Experience Cloud → Walks through enabling public access and article-level checkbox.
Experience Cloud Guest User Security → Explains guest profile is system-managed and cannot be customized for sharing.