Explanation:

The correct solution is Roll-up Summary field because Salesforce provides this native feature specifically for aggregating child record data into a parent record. In the Account–Opportunity relationship, Opportunities are child records of Accounts. A roll-up summary field created on the Account object can count the number of related Opportunities automatically. This is the most efficient, declarative, and exam‑relevant solution.

A roll-up summary field allows administrators to perform four types of calculations on child records:
COUNT: Number of related records (used here).
SUM: Total of a numeric field across child records.
MIN/MAX: Lowest or highest value of a field across child records.

Because Cloud Kicks only needs the number of Opportunities per Account, the COUNT function is the exact fit. It requires no code, no external tools, and is fully supported in Salesforce’s standard Account–Opportunity master-detail relationship. Once configured, the field updates automatically whenever Opportunities are created, deleted, or modified, ensuring accuracy without manual intervention.

Why Other Options Are Incorrect

A. Formula field
Formula fields are powerful for calculations but limited to referencing fields on the same record or parent records via lookup/master-detail relationships. They cannot aggregate data from multiple child records. For example, a formula field on Account could display data from a related Opportunity if you reference a single record, but it cannot count all Opportunities. This limitation makes formula fields unsuitable for record counts.

C. AppExchange offering
AppExchange provides third-party tools for advanced roll-ups, especially when dealing with lookup relationships where native roll-up summary fields are not supported. However, in this case, Opportunities are related to Accounts through a standard master-detail relationship. Salesforce already supports roll-up summaries natively here. Using AppExchange would be unnecessary, add complexity, and contradict exam best practices, which emphasize using standard features first.

D. Lookup field
Lookup fields establish relationships between objects but do not provide aggregation or calculation. A lookup field could connect an Opportunity to an Account, but it cannot count related records. It simply links records together. To display the number of Opportunities, you need a calculation mechanism, which lookup fields do not provide.

Exam-Oriented Reasoning
When approaching scenario-based questions in the Platform App Builder exam, the key is to identify the native declarative feature that solves the problem with minimal complexity. The distractors here test your ability to eliminate:
Formula fields → Great for calculations, but not for child record aggregation.
AppExchange → Useful for advanced cases, but overkill when native roll-up summaries exist.
Lookup fields → Establish relationships, not counts.

Thus, the best practice is to use Roll-up Summary fields whenever you need to aggregate child record data into a parent record in a master-detail relationship.

References:
Salesforce Help: Roll-Up Summary Fields
Salesforce Help: Formula Fields Overview

Explanation:

The critical requirement here is that the value must be "static after the opportunity has been created." This means we need to capture the value of the Account's Billing State at the moment the Opportunity is created and store it in a field on the Opportunity record. If the Account's Billing State changes later, this stored value on the Opportunity should not change.

Let's analyze why a Flow is the correct tool and why the others are not:

C. Flow (Correct): An automatic Record-Triggered Flow can be configured to run when an Opportunity is created. This flow can:
Look up the related Account and get the current value of the Billing State field.
Immediately update the Opportunity record with that value, storing it in a custom field (e.g., Account_Billing_State_At_Creation__c).
This captured value is now a fixed, static piece of data on the Opportunity record and will not change, even if the Account's information is updated later.

B. Formula Field (Incorrect):
A formula field that references the Account's Billing State (e.g., Account.BillingState) is a live, cross-object reference. It will always display the current value of the Account's Billing State. If the Account's state changes a year after the Opportunity is created, the formula field on the Opportunity will automatically and instantly reflect that new value. This violates the "static" requirement.

A. Roll-up Summary Field (Incorrect):
A roll-up summary field is used to aggregate data from child records (like Opportunities, Contacts) onto a parent record (like an Account). It cannot be used to pull a value from a parent record (Account) onto a child record (Opportunity). Its direction and purpose are the opposite of what is needed here.

D. Apex (Incorrect):
While an Apex trigger could certainly accomplish this, the question asks for the solution an App Builder should implement. A Flow is a declarative (code-free) tool that is perfectly suited for this task and is the recommended, maintainable solution for this requirement. Using Apex would be "overkill" and require a developer, making it the less ideal choice when a declarative option exists.

References:
Salesforce Help: "Get Records in a Flow"
Salesforce Help: "Update Records in a Flow"

Explanation:
When you enable "Allow Customer Invitations" and invite a Contact as a Customer User (using the "High Volume Customer" or "Customer" license), you are giving them a very limited set of permissions to collaborate within specific Chatter groups.

Let's analyze each option:

A. The ability to interact with members of their groups. (Correct):
This is the core permission granted. A Customer User invited to a Chatter group can:
View the group and its members.
Post, comment, and like within that group.
This is the fundamental definition of "collaboration" that the question is seeking.

B. The ability to @mention accounts of which they are a contact. (Incorrect):
Customer Users have a very restricted view of data. They can only see and interact with the groups they are a member of and the users within those groups. They cannot @mention an Account record itself. They can @mention other users in their group.

C. The ability to invite members to groups of which they are a member. (Incorrect):
This is an administrative function. Customer Users have a highly restricted license and do not have the permission to manage group membership or invite other users (whether internal or external) to a group.

D. The ability to request access to public groups. (Incorrect):
While a standard internal user might see a "Request to Join" button on a public group, this capability is not typically extended to Customer Users. Their access is strictly controlled by the administrator, who must explicitly add them to groups. They do not have the ability to browse and request access to public groups on their own.

Key Concept:
The "High Volume Customer" and "Customer" licenses are designed for controlled, specific collaboration. They are not full Salesforce users. Their world in Salesforce is limited to the Chatter groups they have been explicitly invited to, and their permissions within those groups are restricted to basic social interactions.

References:
Salesforce Help: "Invite Customers to Chatter"

Explanation:
The key requirement here is to "minimize the need for manual maintenance." This means the app builder wants a solution that can be easily upgraded, is protected from namespace conflicts, and doesn't require manual tweaking after installation.
Let's break down why a managed package is the correct choice and why the others would increase maintenance:

D. A managed package from AppExchange (Correct):
A managed package is a commercially developed, sealed, and upgradeable application.
Minimizes Maintenance: The publisher of the managed package is responsible for providing upgrades. The admin can install these upgrades with a few clicks, and the upgrade process handles database schema changes and code updates automatically.
Protected: Components in a managed package are encapsulated in a unique namespace, preventing conflicts with your existing org's customizations.
Supported: Managed packages from AppExchange are typically supported by the vendor, reducing the internal support burden on the app builder's team.

A. An open-source custom development (Incorrect):
This would likely result in the highest maintenance burden. Open-source code, while flexible, requires the internal team (or the app builder) to understand, customize, test, and maintain every aspect of the solution. Any bug fixes or new features become a manual development task.

B. An unmanaged package from AppExchange (Incorrect):
An unmanaged package is simply a container for moving metadata (components like custom objects, fields, and code) from one org to another. Once installed, the components are "unlocked" and become part of your org's customizations.
High Maintenance: There is no upgrade path. If a new version of the unmanaged package is released, you often cannot cleanly install it and would have to manually compare and update your components, which is error-prone and time-consuming.

C. An open-source unmanaged package (Incorrect):
This combines the worst of both worlds for maintenance. It's an unmanaged package (so no easy upgrades) and is open-source (meaning you are responsible for the code quality and future development). This option provides the least protection and guarantees the highest manual maintenance overhead.

References:

Salesforce Help: "Managed and Unmanaged Packages"
Trailhead: Module on "AppExchange Basics" which explains the difference between managed and unmanaged packages and their use cases.

Explanation:
The requirement contains two critical pieces of information that point directly to a Master-Detail relationship:

"track installation information once a container has been purchased on a custom object." This implies that an Installation record's existence is dependent on a sale (an Opportunity). If the Opportunity is deleted, its associated Installation records should also be deleted. This is a key characteristic of a master-detail relationship.

"Sales reps should have visibility of all the installations associated with their opportunities." This is the most important clue. In Salesforce, sharing and visibility are crucial. A master-detail relationship enforces the same sharing and security settings for the child record (Installation) as the parent record (Opportunity). If a sales rep has read access to an Opportunity, they will automatically have read access to all of its related Installation records. A lookup relationship does not provide this automatic sharing.

Let's evaluate each option:

B. Master-Detail (Correct): This is the ideal relationship type. It creates a tight, dependent bond where the Installation (child, or detail) record cannot exist without the Opportunity (parent, or master).
Automatic Deletion: Deleting the Opportunity automatically deletes all its Installation records.
Inherited Security: The Installation records inherit the sharing and security settings of the parent Opportunity, perfectly fulfilling the requirement that sales reps see the installations for their opportunities.

D. Lookup (Incorrect): A lookup relationship creates a loose connection. The Installation record can exist independently of the Opportunity.
No Automatic Deletion: Deleting the Opportunity would leave the Installation record orphaned unless a custom process is built.
Independent Security: The Installation record has its own independent sharing model. A sales rep with access to an Opportunity would not automatically have access to a related Installation record via a lookup. This would require a complex sharing rule or manual sharing to achieve, making it a poor choice for this requirement.

A. Many to Many (Incorrect):
A many-to-many relationship is implemented using a Junction Object. This is used when one Opportunity can be associated with many Installations, and one Installation can be associated with many Opportunities. The scenario describes a one-to-many relationship (one Opportunity has many Installations). Using a many-to-many setup here would be unnecessarily complex.

C. Hierarchical (Incorrect):
A hierarchical relationship is a special type of lookup that is only available on the User object. It is used to create management chains or organization hierarchies (e.g., setting up a user's manager). It cannot be used to relate a custom object to the Opportunity object.

References:
Salesforce Help: "Master-Detail Relationship"
Salesforce Help: "Lookup Relationship"