Explanation:
Let's evaluate each option based on the official capabilities of Salesforce's Schema Builder.

C. Showing selected objects on a page (Correct):
This is a core function of Schema Builder. Its main purpose is to provide a visual representation of your data model. You can use the toolbar to add specific objects to the canvas, allowing you to focus on a particular subset of your schema and its relationships. This helps in managing complexity and designing your app visually.

B. Creating a new record type (Correct):
This is a standard and well-documented feature. You can right-click on any object within Schema Builder and select "New Record Type" to create one. This integrates the process of data modeling (objects and fields) with application configuration (record types) in a single, visual tool.

A. Editing custom settings (Incorrect):
This is the most common distractor in this question. Schema Builder is designed for objects that store data in a tabular format with relationships (standard and custom objects). Custom settings are a type of custom application configuration data that are not represented as traditional database tables with the same kind of relationships. Therefore, you cannot view or edit custom settings within the Schema Builder interface. They are managed through the main Setup menu.

D. Viewing page layouts in a new window (Incorrect):
Schema Builder is for viewing and editing the data schema (the structure of your data), not the user interface layout. Page Layouts control the organization of fields, related lists, and sections on a record's detail and edit pages. These are managed in the separate Page Layout Editor.

Why Your Answer Was Wrong:
You selected A (Editing custom settings), which is a key functionality that Schema Builder does not have. Memorizing this distinction is crucial for the exam.

References:
Salesforce Help: "View Objects and Fields with Schema Builder"

Explanation:

Salesforce Connect is designed to meet this exact requirement. It allows you to integrate data from external systems in real-time by creating "external objects" that reference data stored outside of Salesforce.
The data is never physically copied or stored within your Salesforce organization, which prevents you from exceeding data storage limits.
When a user interacts with an external object, Salesforce Connect retrieves the data from the external source on demand, ensuring that users always have access to the most up-to-date information.

Why other options are incorrect
A. Data Loader:
The Data Loader is a tool used for importing and exporting large volumes of data. It would require importing all 2 million asset records into Salesforce, which is the opposite of the desired solution and would immediately cause storage issues.
C. Salesforce to Salesforce:
This feature is used for sharing data between two different Salesforce organizations. It is not designed for integrating with external systems like the one described in the scenario.
D. Data Export Wizard:
This tool is used for exporting data out of Salesforce, not for bringing data in from an external system.

Explanation:

A Workflow Rule is the most suitable automation tool for this requirement. A workflow rule is a declarative automation tool that performs actions when a record meets a specific set of criteria.

Here's why a workflow rule is the best choice:

Rule Criteria: You can set the criteria for the workflow rule to be Contact. DoNotCall equals True.
Field Update Action: Once the criteria are met, the workflow rule can perform an immediate Field Update action. This action would update the Phone field on the same Contact record to be blank ("" or NULL).

Why other options are incorrect:
A. Quick action: A quick action allows users to create, update, or log calls for a specific record. It is a manual action initiated by the user, not an automatic process that runs when a field is checked.
B. Approval process: An approval process is designed to approve records that require a series of steps and actions from multiple people. It is not used for simple field updates based on a checkbox.
C. Validation rule: A validation rule is used to prevent a record from being saved if it doesn't meet specific criteria. It cannot automatically update a field. It would only be able to prevent the user from saving the record if the "DoNotCall" checkbox is checked and the phone number is not blank, but this doesn't fulfill the requirement of deleting the phone number.

Explanation:

The question is about extending access beyond the baseline restrictions set by Organization-Wide Defaults (OWD). OWDs set the most restrictive level of access (e.g., Private, Public Read Only). The tools used to liberalize or grant additional access on top of these defaults are Sharing Rules and Manual Sharing.

Why A is Correct (Sharing Rules):
Sharing rules are the primary automatic tool for extending access. They are used to automatically grant broader access to records based on criteria (criteria-based) or ownership (owner-based). For example, if the OWD for an object is Private, a sharing rule can be created to automatically share records owned by users in one role with users in another role.

Why D is Correct (Manual Sharing):
Manual sharing allows users to grant access to individual records on a case-by-case basis. This is a manual exception to the OWD. For example, a user who owns a private record can click the "Share" button to grant read or edit access to another specific user or a public group. This directly extends access beyond what the OWD alone would allow.

Why the Other Options are Incorrect:
B is Incorrect (Public Groups):
A Public Group is a tool used within sharing rules and manual sharing, but it is not itself a mechanism for extending access. You create a public group of users and then use a sharing rule or manual sharing to grant access to that group. The group itself does not change record access.
C is Incorrect (Permission Set Groups):
Permission Set Groups are used to bundle and assign user permissions (object-level, field-level, and system permissions). They control what a user can do (e.g., read, edit, delete) if they have access to a record. They do not control which records a user has access to see. That is governed by the sharing model (OWD, sharing rules, roles, etc.).

Reference:
This question falls under the "Data Security and Access" section of the exam guide. It tests the fundamental understanding of the Salesforce Sharing Model, specifically identifying Sharing Rules (automatic) and Manual Sharing (user-driven) as the two tools used to grant additional record access on top of restrictive Organization-Wide Defaults.

Explanation:

Why these are correct
Approval processes can fire automated actions on initial submission (and other stages). The supported action types include Email Alert, Task, Field Update, and Outbound Message. From the choices given, the three applicable ones are Email Alert (A), Outbound Message (B), and Task (C).

Why not the others
D. Invocable Flow — “Flow” isn’t one of the classic approval action types listed for approval processes (those are email alerts, tasks, field updates, and outbound messages).
E. Invocable Process Builder — Process Builder actions aren’t an approval action type.

References:
Salesforce Help & Trailhead overviews of approval-process actions (email alerts, tasks, field updates, outbound messages).