Explanation:
Service Agents must confirm a user’s identity before giving support information. This requirement is about guiding the agent through a structured process during a live interaction. The best Salesforce feature for this is Guided Action Flows embedded on the record page.
Guided Action Flows allow app builders to embed a Flow directly into the Case record page.
These flows can present step‑by‑step screens to the agent, prompting them to ask identity verification questions, capture responses, and enforce business rules before proceeding.
This ensures consistency, compliance, and auditability across all agents handling support calls.
This declarative solution is exam‑relevant because it leverages Flow, Salesforce’s most powerful automation tool, and aligns with the requirement to enforce a structured identity check process.

Why Other Options Are Incorrect

B. Add Path to the top of the Case layout
Path is
used to guide users through stages of a process (like Opportunity stages). It provides visual cues but does not enforce step‑by‑step identity verification or capture responses.

C. Include Surveys as a Case related list
Surveys are used to collect feedback from customers, not to guide agents during live support calls.
They cannot enforce identity verification before providing information.

D. Case Validation Rules
Validation rules enforce data integrity when saving records.
They cannot guide agents through identity verification steps during a phone call.

Exam-Oriented Reasoning
The phrase “confirm a user’s identity before providing support information” signals a need for guided, interactive enforcement.
Path → visual guidance only.
Surveys → customer feedback, not agent workflow.
Validation Rules → enforce data entry, not live process steps.
Guided Action Flows → interactive, step‑by‑step enforcement of identity checks.
Thus, the only correct choice is Guided Action Flows on the record page.

References
Salesforce Help: Surveys Overview
Salesforce Help: Validation Rules

Explanation:
DreamHouse Realty executives want to enforce an internal policy for travel requests. This requirement is not just about automation but about formal review and enforcement. In Salesforce, the feature designed for this exact scenario is the Approval Process.

An Approval Process allows you to:
Define criteria for when a record (like a travel request) enters the approval cycle.
Route the request to one or more approvers (e.g., executives or managers).
Enforce business rules by requiring explicit approval before the record can proceed (e.g., before booking flights).
Automate actions at each step (field updates, email notifications, locking records).
This ensures compliance with internal policies and provides a structured, auditable workflow for approvals.

Why Other Options Are Incorrect

A. Process Builder
Process Builder automates actions (field updates, notifications, record creation) based on conditions.
It cannot enforce approval or rejection decisions. It’s useful for automation but not for policy enforcement requiring human approval.

B. Workflow Rule
Workflow rules are older automation tools for simple “if/then” actions (field updates, email alerts).
They cannot handle multi-step approvals or enforce executive sign-off.
Salesforce is also retiring Workflow Rules in favor of Flow.

D. Apex
Apex is custom code used for complex logic beyond declarative tools.
While Apex could theoretically enforce approvals, it would be over-engineering. Salesforce provides Approval Processes natively for this exact use case.
Exams emphasize declarative-first solutions unless requirements cannot be met without code.

Exam-Oriented Reasoning
When the question mentions “enforce internal policy” and “submission of request forms”, the key is recognizing this as a business approval requirement. Declarative automation tools like Workflow or Process Builder automate actions but do not enforce human approvals. Apex is powerful but not exam-best practice unless declarative tools fail.

Thus, the Approval Process is the only correct choice because it:
Routes requests to approvers.
Enforces compliance.
Provides auditability.
Is the standard Salesforce declarative solution for approval workflows.

References:
Salesforce Help: Approval Processes Overview
Salesforce Help: Process Builder Overview

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"