Explanation:

A. An app builder is unable to change a lookup to a master-detail relationship.
In the scenario described, a standard object is the parent. Salesforce does not allow a master-detail relationship to be created from a custom child object to a standard parent object if the standard object is the "master" of the master-detail relationship. While there are some standard relationships (like Account and Opportunity) that behave similarly to master-detail, for most standard objects, roll-up summaries can't be created from custom children. The lookup cannot simply be changed to a master-detail relationship when the child object is custom and the parent is standard.
D. A value is required in all records of the lookup field prior to converting to a master-detail relationship.
If the objects were convertible (which they aren't in this case, see explanation for A), you would have to ensure that every record on the child object had a value in its lookup field. This is because a master-detail relationship does not allow for "orphaned" records on the detail side.

Why other options are incorrect
B. An object can have up to two master-detail relationships.
This is a true statement about master-detail relationships, but it's not a relevant consideration for solving the specific problem presented. The main limitation here is the relationship with the standard object, not the number of relationships on the custom child object.
C. A trigger on save or update can kick off calculations.
This is a valid way to calculate summaries from child objects, but it is not a declarative solution. The requirement explicitly asks for a declarative solution, which a trigger (a form of Apex code) is not.

Explanation:

Why: In Lightning, Chatter Streams let users build a custom feed from specific records (e.g., key Accounts and Opportunities), people, or groups. The rep can add those key records to a stream and view only posts from them—perfect for filtering a noisy feed.

Why not the others:
A. Chatter group: Groups organize people/topics, not posts from specific records.
B. Chatter bookmarks: Save individual posts; they don’t create a filtered feed.
D. Chatter notification: Alerts you, but doesn’t provide a dedicated filtered feed view.

Explanation:

The requirement is to automate travel requests based on specific criteria, which typically involves routing requests for approval based on conditions (e.g., cost, destination, or employee role). In Salesforce, an Approval Process is the most appropriate declarative tool for automating such a process, as it is designed to manage approval workflows with defined criteria, steps, and actions. Since the question does not specify the exact criteria but emphasizes automation and the context of "travel requests," an Approval Process aligns best with standard Salesforce practices for such scenarios.

C. Approval process (Correct):
An Approval Process allows an app builder to automate the approval of travel requests by defining criteria (e.g., request amount > $1,000 or destination = international), assigning approvers (e.g., managers), and specifying actions (e.g., lock record, send email notifications, or update fields). It is a declarative tool, ideal for an app builder to configure without coding, and supports complex approval logic tailored to the criteria.
Steps:
Go to Setup > Approval Processes and create a new process for the object storing travel requests (e.g., a custom object like Travel_Request__c).
Define entry criteria based on the specific conditions (e.g., Amount__c > 1000).
Set up approval steps, assign approvers, and configure actions (e.g., approval, rejection, or field updates).
Reference: Salesforce Help - Approval Processes

Why not the other options?
A. Process Builder (Incorrect):
Process Builder (now part of Salesforce Flow) is used for automating business processes like field updates or notifications but is not specifically designed for managing approval workflows. While it can trigger an approval process, it’s not the primary tool for handling approvals with multiple steps or criteria-based routing.
Reference: Salesforce Help - Process Builder

B. Workflow rule (Incorrect):
Workflow Rules are limited to simple automation tasks (e.g., field updates, email alerts) and cannot handle complex approval processes with multiple approvers or dynamic routing based on criteria. They are also being phased out in favor of Flow.
Reference: Salesforce Help - Workflow Rules

D. Apex (Incorrect):
Apex is a programmatic solution requiring coding, which is not ideal for an app builder focused on declarative tools. While Apex can handle complex approval logic, it’s unnecessary when a declarative Approval Process can meet the requirement.
Reference: Salesforce Help - Apex

Recommended Approach:
Create a custom object (e.g., Travel_Request__c) if not already present to store travel request data.
In Setup > Approval Processes, create an approval process with entry criteria based on the specific conditions for travel requests.
Configure approval steps, assign approvers (e.g., via role, hierarchy, or specific users), and define actions (e.g., lock record, send notifications).
Test the process to ensure it routes requests correctly and meets the criteria.

Additional Notes:
Without specific criteria provided, the Approval Process is assumed to handle conditions like cost thresholds or destination types, common in travel request scenarios.
Ensure the object has fields to capture relevant data (e.g., Amount__c, Destination__c) for use in approval criteria.
Use Salesforce Flow as an alternative if more complex automation beyond approvals is needed, but Approval Process is sufficient for this use case.

References:
Salesforce Trailhead: Approval Processes
Salesforce Help: Create Approval Processes

Explanation:

The goal is to prevent all outbound emails from being sent from the sandbox during testing. This ensures test emails don't accidentally reach real customers or clutter their inboxes.

Why D is Correct:
The Email Deliverability setting controls the ability of the entire Salesforce org to send emails to external addresses. Setting it to "No Access" is the most restrictive option. It prevents all outbound emails from being delivered to external email addresses, regardless of their source (workflow alerts, Apex code, processes, etc.). They will be stored in the Email Log files but not sent. This is the standard and most effective practice for test environments like sandboxes.

Why A is Incorrect:
Setting deliverability to "System Email Only" allows emails generated by system processes (like password resets, workflow alerts, and approval requests) to be sent. This would not meet the requirement, as it would still permit many automated emails to be sent out from the sandbox during testing of new features.

Why B is Incorrect:
Configuring SMTP authentication is about setting up the method for sending emails (e.g., connecting to an external mail server like Gmail or Office 365). It does not inherently prevent emails from being sent; it just defines how they are sent if they are allowed. This does not solve the requirement to block emails.

Why C is Incorrect:
Enabling Email Relay is similar to SMTP configuration. It routes outbound Salesforce emails through a specific mail server (the "configured host"). Again, this enables a method for sending email but does not block the sending of emails. If enabled, emails would still be relayed through the host and sent to end users.

Reference:
Salesforce Help - "Set Email Deliverability in Salesforce". The documentation states:

No Access:
Users can’t send email through Salesforce. Salesforce doesn’t deliver any email.

System Email Only:
Salesforce delivers only system-generated emails. Examples include forgot-my-password emails and automated case escalation emails.
For a testing environment, "No Access" is the recommended setting to prevent any unintended external communication.

Summary:
To prevent all outbound email during testing, an App Builder must navigate to Setup -> Email Administration -> Deliverability and set Access to Send Email to No Access.

Explanation:

The requirement is to:
Add a custom Sync button to the Account record page
Trigger a Lightning Web Component (LWC) that connects to an external system
Ensure the button is conditionally visible only when the Status field = "Ready to Sync"

✅ Why Dynamic Action is the right choice:
Dynamic Actions allow you to conditionally show or hide buttons on Lightning record pages based on field values, user profiles, or record data.
You can configure the Sync button to appear only when Status = "Ready to Sync".
The button can be tied to a custom Lightning Web Component via a Lightning Action or Quick Action.
This is a declarative, flexible, and mobile-friendly solution.

❌ Why the other options don’t work:
A. Formula field
Formula fields are read-only and cannot trigger actions or components.
C. AppExchange product
Overkill for this use case — no need to install a third-party app for a simple conditional button.
D. Custom link
Custom links are static and cannot be conditionally displayed based on field values. Also, they don’t integrate cleanly with LWCs.

🔗 References:
Salesforce Help: Dynamic Actions on Record Pages
Trailhead: Lightning App Builder

Explanation:

To show a related list on a parent object (in this case, Asset), you must have a relationship field on the child object (Asset Inventory) that points to the parent.

Create a lookup relationship on Asset Inventory to Asset:
Creating a lookup relationship field on the Asset Inventory object that references the Asset object is the correct way to establish this parent-child connection.
Add the Asset Inventory related list to the Asset page layout:
Once the relationship is established, Salesforce will automatically make the child object (Asset Inventory) available to be added as a related list on the parent's (Asset) page layout.

Why other options are incorrect
A. Create a roll-up on Asset. Add the Asset Inventory related list to the Asset page layout:
A roll-up summary is used to aggregate data from child records onto a parent record; it does not create a related list. The related list is a result of the relationship itself, not a roll-up summary.
B. Create a junction object to relate Asset Inventory and Asset. Add the Asset Inventory related list to the Asset page layout:
A junction object is used to create a many-to-many relationship between two objects. While it would create related lists, it's an unnecessary and overly complex solution for a simple one-to-many relationship, where Asset Inventory is the child of Asset.
D. Create a master-detail relationship on Asset-to-Asset Inventory Add the Asset Inventory related list to the Asset page layout:
This is incorrect. The master-detail relationship field must be created on the child object (Asset Inventory) and reference the parent object (Asset). The option incorrectly states the relationship direction.

Explanation:

Schema Builder is a visual tool in Salesforce that allows app builders to view and manage the data model, including objects, fields, and relationships, in a graphical interface. It is used to design and modify the schema of a Salesforce org declaratively. Below is a concise analysis of each option:

A. Editing custom settings (Correct):
Schema Builder allows app builders to create and edit Custom Settings, which are used to store customizable, application-specific data that can be accessed in formulas, validation rules, or Apex. In Schema Builder, you can view and modify Custom Settings alongside other objects, making it a key capability for managing the data model.
Reference: Salesforce Help - Schema Builder

B. Creating a new record type (Incorrect):
Schema Builder is focused on managing objects, fields, and relationships, not on creating or managing Record Types. Record Types are configured in Setup > Object Manager > [Object] > Record Types, not in Schema Builder, as they control business processes and page layouts, not the schema itself.
Reference: Salesforce Help - Record Types

C. Showing selected objects on a page (Correct):
Schema Builder allows users to select and display specific objects (standard and custom) on its canvas, providing a visual representation of their fields and relationships. This filtering capability helps app builders focus on relevant parts of the data model, making it easier to understand and modify the schema.
Reference: Salesforce Help - Schema Builder

D. Viewing page layouts in a new window (Incorrect):
Schema Builder does not provide functionality to view or edit page layouts. Page layouts are managed in Setup > Object Manager > [Object] > Page Layouts or via the Lightning App Builder. Schema Builder is strictly for schema-related tasks like objects, fields, and relationships.
Reference: Salesforce Help - Page Layouts

Key Capabilities of Schema Builder:
Visualize and manage standard and custom objects, fields, and relationships.
Create and edit Custom Settings, Custom Objects, and Custom Fields.
Filter the canvas to show selected objects for a focused view.
Define relationships (e.g., Lookup, Master-Detail) visually.

References:
Salesforce Trailhead: Data Modeling
Salesforce Help: Schema Builder Overview

Explanation:

Changing a field's data type is a significant modification that can have unintended consequences, especially when dealing with data limits and history tracking.

Why B is Correct:
Converting a field from one data type to another can often result in data truncation or loss. A Text Area (Long) field can hold up to 131,072 characters. A Rich Text field can only hold up to 32,768 characters in most contexts (and is often effectively limited to much less when stored in HTML format). If any existing records have text longer than the new Rich Text field's capacity, that data will be truncated and lost during the conversion process. The team must analyze their existing data to ensure no values exceed the new limit before proceeding.
Why C is Correct:
Field History Tracking has a known limitation: it only captures the first 255 characters of any changed field value for the history trail. This is true regardless of the original field's data type (Text, Text Area, Rich Text) or length. If the business requirement for tracking changes relies on the full content of these potentially long descriptions, this limitation makes Field History Tracking an inadequate solution. The team may need to consider a different auditing strategy, such as using a custom object or an external logging system.

Why A is Incorrect:
This statement is false. In Salesforce reports, Rich Text fields are truncated and do not display their full content. You typically see a preview or a shortened version. To see the full value, a user must click into the individual record. This is an important UI consideration when choosing to use Rich Text fields.
Why D is Incorrect:
While the Field History Tracking data is accessible via the API, the specific term "Audit Trail" in Salesforce typically refers to the Setup Audit Trail, which logs changes to your org's configuration, not changes to individual record data. This option is a distractor and does not address the core considerations of data loss and history tracking character limits related to the field type change.

Reference:
Salesforce Help:
"Convert Field Type Considerations": Explicitly warns that converting fields can lead to data loss.
"Field History Tracking Considerations": States "Field history tracking retains the previous 255 characters for any changed field whose length is greater than 255 characters."

Explanation:

Universal Containers has set the Account object’s Organization-Wide Default (OWD) to Public Read/Write, which means all users—including community users—can view and edit all Account records. That’s a major data exposure issue for external users.
To restrict visibility so that community users only see their own Accounts, Salesforce provides a separate setting:
🔐 External Organization-Wide Defaults (External OWD)
These allow you to set different sharing defaults for external users (e.g., Customer Community, Partner Community).
You can configure the Account External OWD to Private, which ensures:
Community users only see records they own
No access to other users’ Account records
This is the most direct and secure solution to meet the requirement.

❌ Why the other options don’t work:
A. Create an account record type for external accounts
Record types control page layouts and picklist values, not data visibility.
B. Define an owner-based sharing rule for external accounts
Sharing rules grant access, not restrict it. You can’t use them to hide records.
C. Define a permission set for external accounts
Permission sets control object-level access, not record-level visibility.

🔗 References:
Salesforce Help: External Organization-Wide Defaults
Trailhead: Data Security

Explanation:

The scenario describes a master-detail relationship between the custom Service Plan object (the detail or child) and the standard Contact object (the master or parent). The reason a master-detail relationship is likely in use is the requirement that a Service Plan be "associated to one and only one contact," which is a defining characteristic of this type of relationship.
By default, the Allow reparenting option is disabled when a master-detail relationship is created. This means that once a child record (the Service Plan) is created and assigned to a parent record (the Contact), the relationship field becomes read-only and cannot be changed. To allow the parent record to be changed, an App Builder must explicitly enable the Allow reparenting setting by editing the master-detail relationship field definition.

Why other options are incorrect
A. The Read Only radio button, Allows users with at least Read access to the Master record to create, edit, or delete related Detail records, is selected: This option describes a setting for defining access for the child record, not the ability to change the parent record itself. It determines what users with read access to the master can do with the child, not whether the master can be reparented.
C. The Read/Write radio button, Allows users with at least Read/Write access to the Master record to create, edit, or delete related Detail records, is selected: Similar to option A, this setting concerns the access rights on the child record based on the master record's security, and does not directly control the reparenting functionality.
D. The Allow reparenting checkbox...is checked: This is the opposite of the correct answer. If the Allow reparenting checkbox were checked, the reps would be able to change the associated contact.

Explanation:

Why: 60,000+ records exceeds the Data Import Wizard limit (50k per load). Data Loader is built for bulk operations (up to millions of rows), supports CSV templates aligned to your data model, and is the standard tool for inserting a large volume of Account records quickly.

Why not the others:
B. Lightning Object Creator: Creates a new custom object from a spreadsheet; it doesn’t bulk-insert into standard Accounts.
C. Import Wizard: Easy UI, but capped at 50,000 records per job—too small for 60k+.
D. Schema Builder: For designing metadata (objects/fields/relationships), not loading data.

Explanation:

Universal Containers has implemented duplicate management for Leads, but duplicates are still being created despite the Organization-Wide Default (OWD) for Leads being set to Private. This suggests issues with how duplicate rules or sharing settings are configured. The goal is to prevent duplicate Leads from being created. Below is a concise analysis of each option:

A. Change the lead Matching Rule to Block on create (Correct):
Salesforce Duplicate Rules work with Matching Rules to identify and prevent duplicate records. By default, a Duplicate Rule may be set to Alert (notifying users of potential duplicates) or Allow (permitting duplicates with a warning). Changing the Duplicate Rule to Block on create ensures that if a Lead matches the criteria defined in the associated Matching Rule (e.g., same email or name), the system prevents the record from being created. This directly addresses the issue of duplicate Leads being created.
Steps: Go to Setup > Duplicate Rules > [Lead Duplicate Rule], edit the rule, and set the action to Block for record creation.
Reference: Salesforce Help - Duplicate Rules

B. Change OWD for Leads to Public Read (Incorrect):
Changing the OWD for Leads to Public Read affects record visibility, allowing all users to view all Leads, but it does not prevent the creation of duplicate Leads. OWD settings control access, not data quality or duplicate prevention, making this option irrelevant to the requirement.
Reference: Salesforce Help - Organization-Wide Defaults

C. Change the Lead Duplicate Rule details to Bypass Sharing Rules (Correct):
With the OWD for Leads set to Private, users can only see Leads they own or have access to via sharing rules or role hierarchy. This can prevent Duplicate Rules from identifying duplicates if a user cannot access existing Lead records to compare against. Enabling the Bypass Sharing Rules option in the Duplicate Rule allows the system to check all Lead records (regardless of sharing settings) when evaluating duplicates, ensuring more effective duplicate detection and prevention.
Steps: Go to Setup > Duplicate Rules > [Lead Duplicate Rule], edit the rule, and check the Bypass Sharing Rules option.
Reference: Salesforce Help - Duplicate Rules and Sharing

D. Change the Lead Assignment Rule to check for duplicates (Incorrect):
Lead Assignment Rules determine how Leads are assigned to users or queues based on criteria (e.g., geography or lead source). They do not have built-in functionality to check for or prevent duplicates. While custom logic could be added (e.g., via Flow or Apex), this is not a standard feature of Lead Assignment Rules, making this option incorrect.
Reference: Salesforce Help - Lead Assignment Rules

Recommended Approach:
Modify the Duplicate Rule:
In Setup > Duplicate Rules, edit the Lead Duplicate Rule.
Set the action to Block on record creation to prevent duplicates from being saved.
Bypass Sharing Rules:
In the same Duplicate Rule, enable Bypass Sharing Rules to ensure the system checks all Leads, even those the user cannot access due to the Private OWD.
Verify the Matching Rule (e.g., matching on Email, Name, or Company) is correctly configured to identify duplicates accurately.

Additional Notes:
Ensure the Matching Rule used by the Duplicate Rule is robust (e.g., matches on key fields like Email or Phone) to catch potential duplicates.
Test the Duplicate Rule in a sandbox to confirm it blocks duplicates without impacting valid Lead creation.
If duplicates are still created via API or integrations, ensure those processes respect the Duplicate Rule settings.

References:
Salesforce Trailhead: Duplicate Management
Salesforce Help: Set Up Duplicate Management