Explanation:
Your answer is correct. Let's break down why Schema Builder is the ideal tool for this task and why the others are not.

D. Schema Builder (Correct):
This is the premier visual tool for exploring an org's data model. Its primary purpose is to display objects (both standard and custom) and the relationships between them (lookup, master-detail) as a dynamic, interconnected diagram. An app builder can easily drag objects onto the canvas and see all the relationships at a glance, making it perfect for getting a holistic understanding of how the entire system connects.

A. Fields & Relationships (Incorrect):
While you can view relationships here, you can only do it one object at a time. You would have to go to Object Manager -> select a specific object -> click "Fields & Relationships" to see a list of that single object's relationships. It is a detailed, textual view, not a holistic, visual one. It's inefficient for understanding the "big picture" of how all objects relate.

B. Object Manager (Incorrect):
The Object Manager is the central hub for managing all objects. You can see a list of every object, create new ones, and access their settings. However, it does not provide a visual diagram of the relationships between them. It's a list, not a map.

C. Lightning App Builder (Incorrect):
This tool is for building the user interface (UI) of Lightning pages (App Pages, Home Pages, Record Pages). It is used to add and configure components like related lists, but it is not used for viewing or understanding the underlying database relationships between objects.

References:
Salesforce Help: "View Objects and Fields with Schema Builder"
Trailhead: The "Data Modeling" module on Trailhead has a specific unit dedicated to using Schema Builder.

Explanation:

Your answer is correct. Here is a detailed breakdown of why.
When you create a master-detail relationship in Salesforce, the platform automatically treats the child object as a "detail" of the parent object in the context of reports. This has a direct and automatic impact on the available report types.

A. A Galaxy__c with Star__c report type will be automatically created. (Correct):
This is the standard platform behavior. For any master-detail relationship, Salesforce automatically generates a "Primary Object with Related Object" report type. In this case, since Galaxy__c is the master (parent) and Star__c is the detail (child), the system creates a report type called "Galaxies with Stars". This allows users to create reports that show Galaxy records, with a related list of their associated Star records.

B. A Star__c report type with Galaxy__c as a field will be automatically created. (Incorrect):
While a standard Star__c report type will exist and will include the Galaxy__c master-detail field, this is not the special, automatically created report type that the question is highlighting. The key automatic behavior is the creation of the parent-with-child report type, not just adding a field to the child's report.

C. A new custom report type will need to be created for Star__c with lookup fields from Galaxy__c. (Incorrect):
This is not necessary. The relationship is a master-detail, not a lookup, and the necessary report type is created automatically. No manual creation is required for basic reporting.

D. A new custom report type will need to be created for Galaxy__c with Star__c. (Incorrect):
This is the opposite of what happens. The platform automatically creates this for you. Manually creating a custom report type would be redundant.

Key Concept:
The defining characteristic of a master-detail relationship in reporting is the automatic creation of a "Primary Object with Related Object" report type. This is a major consideration when choosing between a master-detail and a lookup relationship.

References:

Salesforce Help: "How Report Types Are Determined"
This article explains that report types are automatically created for master-detail relationships.

Salesforce Help: "Master-Detail Relationship Considerations"
This documentation outlines all implications of creating a master-detail relationship, including its effect on reporting.

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.