Explanation:

The Highlights Panel is a standard Lightning component designed specifically for this purpose. It is located at the top of a record page and displays up to 10 key fields from the record's compact layout. This component is ideal for providing users with an at-a-glance summary of the most important information, without having to scroll down the page.

A. Path:
The Path component displays the stages of a business process (like the sales stages on an opportunity) and allows users to track a record's progress. It's not designed to show a large number of key fields.

C. Custom Lightning Web Component:
While a custom LWC could be built to do this, it's not the most appropriate solution. The Highlights Panel is a declarative, out-of-the-box component that requires no coding, making it the most efficient and standard way to achieve the desired functionality.

D. Accordion:
The Accordion component is used to organize content into collapsible sections. It's useful for saving space and preventing a page from getting too long, but it doesn't meet the requirement of displaying the key fields "at once" at the top of the page.

Explanation:

This question tests the knowledge of where to enable mobile and social features for approval processes within Salesforce setup.

Why C is Correct (Chatter Settings):
The central location to enable social and mobile approvals is within Chatter Settings. There is a specific checkbox labeled "Allow users to approve records on the go with Chatter." Enabling this setting adds an "Approve" and "Reject" button to approval-related posts in the Chatter feed. This allows approvers, like the management team, to take action directly from the Chatter mobile app or the Chatter feed on a record without needing to navigate to the record itself.

Why A is Incorrect (Chatter Feed Tracking):
Feed Tracking is a setting used to enable Chatter notifications for specific field changes on an object. It controls what gets posted to the feed, not how users interact with those posts (like approving from them).

Why B is Incorrect (Object Settings):
Object Settings (found within the Object Manager for each specific object) control core properties of the object itself, like whether feeds are enabled, if it's deployable, etc. It does not contain the global setting for enabling approvals via Chatter.

Why D is Incorrect (Approval Process Settings):
While you configure the steps, approvers, and criteria within an Approval Process, the ability to approve via Chatter is not a setting on the individual process itself. It is a global organization-wide setting that must be turned on first to make that functionality available for all approval processes.

Reference:
This question falls under the "Logic and Process Automation" section of the exam guide, specifically concerning the configuration and user experience of Approval Processes. The key detail is knowing that the "approve via Chatter" feature is a master switch located in Setup -> Chatter Settings.

Explanation:

Cloud Kicks (CK) needs a solution that allows their developers and admins to work in at least 20 different sandboxes simultaneously, all starting with the same base configuration and data to avoid conflicts and support parallel development efforts. Let’s evaluate each option to determine the best fit:

Option A: Incorrect.
Sandbox refreshes refer to the process of refreshing an existing sandbox to copy the current configuration and data (if applicable) from the production org or another source. While refreshing sandboxes is part of sandbox management, it is not a specific sandbox type or solution that inherently supports creating 20 sandboxes with the same base configuration and data. It’s a maintenance action, not a solution for parallel development.

Option B: Incorrect.
Full Copy Sandboxes are exact replicas of the production org, including all metadata (configuration) and data. While they could provide the same base configuration and data, Full Copy Sandboxes are resource-intensive, expensive, and typically limited in number (e.g., one or a few per Salesforce edition). Creating and maintaining 20 Full Copy Sandboxes simultaneously is impractical and likely exceeds the sandbox limits for most Salesforce editions, making this an infeasible solution.

Option C: Correct.
Partial Copy Sandboxes are the best solution for this scenario. Partial Copy Sandboxes include all metadata (configuration) from the production org and a subset of data defined by a Sandbox Template, which allows the app builder to specify which objects and records to copy. This ensures all Partial Copy Sandboxes start with the same base configuration and data. Salesforce allows multiple Partial Copy Sandboxes (e.g., up to 25 in Enterprise Edition, more in Unlimited or Performance Editions), making it feasible to create at least 20 sandboxes for parallel development. Developers and admins can work in these sandboxes without conflicts, as each is isolated but starts with the same baseline.

Option D: Incorrect.
Sandbox during is not a valid Salesforce term or feature. It appears to be a typo or misphrasing (possibly meant to be "Sandbox Cloning" or another term). Even if it refers to Sandbox Cloning (a feature to create a new sandbox from an existing one), cloning is not the primary solution for creating multiple sandboxes with the same base configuration and data, as it depends on an existing sandbox and doesn’t address the need for a standardized starting point across 20 sandboxes.

Key Considerations:
Partial Copy Sandboxes use a Sandbox Template to define which data (e.g., specific objects and records) is copied from production, ensuring consistency across all 20 sandboxes.
Partial Copy Sandboxes are less resource-intensive than Full Copy Sandboxes and are designed for development and testing, making them suitable for parallel efforts.
Salesforce editions (e.g., Enterprise, Unlimited) typically include enough Partial Copy Sandboxes to support 20 or more, depending on the license.
The app builder should create a Sandbox Template that includes the necessary objects and data for CK’s development needs (e.g., Accounts, Contacts, Opportunities, or custom objects) to ensure all sandboxes have the same starting point.
Sandboxes can be refreshed periodically to realign with production, but the initial setup of 20 Partial Copy Sandboxes meets the requirement for parallel development.

References:
Salesforce Documentation: Sandbox Types and Templates – Explains Partial Copy Sandboxes and the use of Sandbox Templates to control data.
Salesforce Help: Sandbox Licenses by Edition – Details the number of Partial Copy Sandboxes available per Salesforce edition.
Trailhead: Sandbox Management – Covers sandbox types and their use in development environments.

Explanation:

Why D is correct
A record-triggered Flow on Opportunity (after update) can watch for StageName = "Closed Won" and then:
Create the renewal Opportunity (e.g., copy fields, set Close Date +1 year).
Notify the contracts team—e.g., via an Email Alert or Send Email action to their external addresses. This satisfies both requirements in one automation and aligns with Salesforce’s guidance to build new automation in Flow.

Why the others are wrong
A. Approval Process – Manages approvals; it doesn’t create a renewal record and isn’t needed here.
B. Outbound Message – Can notify an external endpoint, but it can’t by itself create the renewal Opportunity; you’d still need additional automation. Also, outbound messages are tied to older Workflow/Approval tech, which Salesforce recommends migrating off of.
C. Validation Rule – Only blocks saves based on conditions; it doesn’t create records or send notifications.

Explanation:

Schema Builder is a powerful visual tool for creating and modifying objects and their relationships. However, when you create a new field using Schema Builder, it is not automatically added to the existing page layouts. This is a key limitation, and you must manually add the new field to the appropriate page layout(s) using the traditional Page Layout editor.

Why other options are incorrect
A. Cannot create formula fields: This is incorrect. You can create formula fields using the Schema Builder. When you drag the "Formula" field type onto an object, a pop-up window guides you through the process of defining the formula.
B. Cannot see existing relationships between objects: This is incorrect. The primary purpose and strength of Schema Builder is to provide a clear, visual representation of all objects, fields, and their relationships within the Salesforce data model.
D. Cannot create lookup relationships: This is incorrect. Schema Builder allows you to create both lookup and master-detail relationships by dragging the respective field types between objects.