Explanation

The requirement is to display all Container__c records on the Purchase__c records. This means a user should be able to look at a Purchase__c record and see a list of related Container__c records, typically in a related list format.

To achieve this, a relationship field needs to be created on the Container__c (child) object that links back to the Purchase__c (parent) object. This allows multiple container records to be associated with a single purchase record. The standard way to link two custom objects is using a lookup field.

D. Lookup field:
Creating a lookup relationship field on the Container__c object that looks up to the Purchase__c object satisfies this requirement. It establishes a parent-child relationship where a related list of containers automatically appears on the purchase record's page layout.

Why other options are incorrect

A. Roll-Up Summary field:
This field type is used to aggregate data (count, sum, min, max) from child records to a parent record. It displays a single value, not a list of related records, and requires a master-detail relationship, which is not necessary to simply display a list of records.

B. Formula field:
A formula field calculates and displays information based on other fields. It cannot be used to display an entire related list of child records.

C. Master-detail field:
A master-detail relationship establishes a tight link where the child record is heavily dependent on the parent (e.g., cascading delete, security inheritance). While it would display a related list, a simple "lookup" relationship is often sufficient if the child records should have independent lifecycles or security settings, and is a more general-purpose field for simply displaying a list of records. The lookup field meets the basic display requirement without the additional constraints of a master-detail relationship.

Explanation:

✅ Why This Is Correct

D. Add the Knowledge Related List to the Record Page
To give Billing department users access to Knowledge articles outside the Service Console, the administrator should:

Use the Lightning App Builder to edit the Case record page
Drag the Knowledge Related List – Single or Knowledge component onto the layout
This allows users to view, search, and attach articles directly from the Case record, even if they’re not using the Console.

This approach provides Knowledge functionality in a standard Lightning record page, making it accessible to users in non-console apps.

❌ Why These Are Incorrect

A. Add the Knowledge Component to the Page Layout
Page Layouts don’t support Lightning components like Knowledge.
Components are added via the Lightning App Builder, not the layout editor.

B. Add the Knowledge Component List to the Page Layout
There is no component called “Knowledge Component List.”
This is a distractor option and not a valid configuration step.

C. Add the Knowledge Related List to the Page Layout
While you can add a related list in Classic, it doesn’t provide the interactive Knowledge experience users expect.
It’s not the same as the Knowledge component used in Lightning.

Reference Links
Salesforce Help: Add Knowledge to Lightning Record Pages
Trailhead: Set Up Knowledge

Explanation:

The requirement has two key parts:

"Use consistent picklist values... on accounts and cases": This means the same set of values must be used across two different standard objects.
"with values respective to record types": This means that for each object, the available values from that global set can be filtered differently for each record type.

The combination of a Global Picklist and a Custom Picklist field is the solution.

Let's break down the correct options:

B. Global Picklist (Global Value Set)
Correct. A Global Value Set is a centralized picklist that can be used by multiple custom picklist fields across different objects. The administrator creates one Global Value Set (e.g., "Property Categories" with values like Residential, Commercial, Land). This ensures consistency because the values are defined in one place.

D. Custom Picklist
Correct. The administrator must create a custom picklist field on both the Account and Case objects (e.g., Category__c). Instead of defining the values locally for each field, they will set the field's data type to use the Global Value Set created from option B. Then, using Record Type settings on each object, they can control which values from the global set are available for each record type.

Let's break down why the other options are incorrect:

A. Dependent Picklist
Incorrect. A dependent picklist controls the available values in one picklist based on the selection made in another picklist (a controlling field). This is used for creating hierarchical value relationships, not for maintaining a single consistent set of values across different objects.

C. Multi-Select Picklist
Incorrect. A multi-select picklist allows users to select multiple values. This is a behavior of the field, not a solution for maintaining consistent values across objects. A multi-select picklist can use a global value set, but the core solution for consistency is the global value set itself.

Summary:
The process is:

Create a Global Value Set (B) with the master list of categories.
Create a Custom Picklist field (D) on both Account and Case that uses this Global Value Set.
Use Record Types on each object to filter the global values to show only the relevant ones for each record type.

Reference:
Salesforce Help: "Global Picklists (Global Value Sets)"
This documentation explains that global value sets let you "create a set of picklist values once and reuse them in any custom picklist field," which is the foundation for maintaining consistency across objects.

Explanation:

In Lightning Experience, the Related List on a record page (like Contact → Cases) can be customized in two key ways:

1. Lightning App Builder (Option C)
In Lightning pages, the related lists are displayed through the Related List component.
Salesforce offers two related list display types:
“Related Lists” (Standard) – shows all lists as tiles (non-editable columns).
“Enhanced List” – allows inline editing, sorting, and column customization.

2. Page Layout Editor (Option D)
The page layout controls which fields (columns) appear in each related list.
To show fields like Case Name, ID, Reason, Status, Creation Date, the admin must edit the Contact page layout, scroll to the Cases related list, and add the desired fields as columns.
This ensures the information brokers need is visible in the related list.

To display multiple columns and allow flexibility, the admin should edit the Lightning Record Page in the App Builder, select the Related List component, and set the “Related List Type” = Enhanced List.
This combination (Enhanced List + Proper Columns) gives users a rich, sortable, multi-column related list on the Lightning record page.

❌ Incorrect Options:

A. Use the page layout editor to change the related list type to Enhanced List
The page layout editor doesn’t control list type; it only controls which fields appear.
The related list type (Standard vs. Enhanced) is managed in the Lightning App Builder, not the layout editor.

B. Edit the Related List component in the Lightning App Builder and choose Related List as the related list type
Choosing “Related List” (instead of “Enhanced List”) limits users to basic, tile-based related lists — it doesn’t support multiple columns or sorting.

Summary:
To display specific Case information under a Contact record:
Add the desired columns (Case Name, ID, Reason, Status, Created Date) in the page layout editor.
Switch the related list type to Enhanced List in the Lightning App Builder for better visibility and functionality.
This ensures brokers can easily view and manage detailed Case data directly from the Contact record page.

Reference:
Salesforce Help: Customize Related Lists in Lightning Experience
Trailhead: Customize Record Pages with the Lightning App Builder

Explanation:

Impact:
Once My Domain is deployed, all login and application URLs change from the generic Salesforce instance URL (e.g., https://na17.lightning.force.com) to the custom My Domain URL (e.g., https://mycompany.my.salesforce.com).

Action:
This requires the administrator to communicate the change to all users (internal and external) and update any existing bookmarks, links, or integrations that relied on the old instance URL. This is the biggest user-facing change resulting from the feature.

❌ Incorrect Answers Detail

A. Single sign-on must be disabled prior to implementing My Domain.
False. My Domain is actually a prerequisite for setting up and configuring Single Sign-On (SSO) and other authentication services, not an obstacle to them.

C. A deployed My Domain is irreversible and renaming is unavailable.
False. You can rename a My Domain after it has been deployed. However, the old name is reserved, and renaming requires careful planning and communication, similar to the initial deployment.

D. The URL instance for a My Domain stays the same for every release.
False. While the My Domain portion of the URL (mycompany.my.salesforce.com) remains constant, the underlying Salesforce instance (e.g., NA17) still changes during major upgrades or migrations. The benefit is that users still use the same branded URL, simplifying their experience.

Reference
Salesforce Help: My Domain: The documentation highlights the user experience and login changes as the primary impact of enabling My Domain, affecting all users' access and authentication endpoints.