Explanation:
Ursa Major Solar needs to auto-populate a field on the Asset record with the last maintenance date whenever a maintenance work order is closed. This requirement involves updating a parent record (Asset) based on changes in a related child record (Work Order).

The best declarative tool for this is Flow, specifically a Record-Triggered Flow:
It can be triggered when a Work Order record is updated (e.g., status changes to “Closed”).
It can check if the Work Order type is “Maintenance.”
It can then update the related Asset record with the Work Order’s closed date.
This ensures automation without custom code, aligning with Salesforce’s declarative-first approach emphasized in the exam.

Why Other Options Are Incorrect

A. Einstein Next Best Action
Provides recommendations to users based on business rules or predictive models.
It does not update fields or enforce automation when records change.

B. Roll-up Summary
Roll-up summary fields aggregate values (COUNT, SUM, MIN, MAX) from child records into a parent record.
They cannot selectively update a field with the “last maintenance date” because that requires conditional logic (only maintenance work orders, only when closed).

C. Apex Trigger
Apex could achieve this, but it requires custom code.
Since this requirement can be met declaratively with Flow, Apex is not the recommended solution. Salesforce exams emphasize using declarative tools first unless code is unavoidable.

Exam-Oriented Reasoning
The key phrase is “auto-populated on the Asset record when a maintenance work order gets closed.”
Roll-up summaries cannot handle conditional logic like “only maintenance work orders.”
Einstein Next Best Action is about recommendations, not automation.
Apex is powerful but not exam-best practice unless declarative tools fail.
Flow is the correct declarative automation tool for updating parent records based on child record changes with conditional logic.

References
Salesforce Help: Record-Triggered Flows
Salesforce Help: Roll-Up Summary Fields

Explanation:
Universal Containers needs a picklist field called Status on three separate custom objects, and the values must be shared across all three objects. The only Salesforce feature that supports this requirement is a Global Picklist Value Set.

A Global Picklist Value Set allows administrators to define a single set of picklist values that can be reused across multiple objects and fields.
This ensures consistency of values (e.g., “New,” “In Progress,” “Closed”) across all objects.
It also simplifies maintenance: if UC wants to add or remove a value, they only update the global value set once, and all fields using it are updated automatically.
This is the declarative, best-practice solution for sharing picklist values across multiple objects.

Why Other Options Are Incorrect

A. Related Picklist
Salesforce does not have a feature called “Related Picklist.” This is a distractor option.

B. Shared Custom Field
Fields cannot be “shared” across objects. Each object has its own fields. You can replicate fields, but values cannot be centrally managed unless you use a global picklist value set.

D. Dependent Picklist
Dependent picklists are used when one picklist’s values depend on another field’s value (e.g., Country → State).
They do not allow sharing values across multiple objects.

Exam-Oriented Reasoning
The keyword in the scenario is “share the list of values across each object.”
Distractors like “Shared Custom Field” or “Related Picklist” test whether you know Salesforce’s actual features.
“Dependent Picklist” is a common misdirection, but it applies only to conditional logic, not shared values.
The only valid Salesforce feature for this requirement is Global Picklist Value Set.
Thus, the correct answer is C.


References
Salesforce Help: Global Picklist Value Sets

Explanation:

Ursa Major Solar wants to model a scenario where:
A Job Candidate can apply for multiple Open Positions.
Each Open Position can have multiple Applications. Both the Job Candidate record and the Open Position record should display the related Applications.
This is a classic junction object use case in Salesforce. The Application__c object acts as the junction object between Job_Candidate__c and Open_Position__c.

To achieve this:

Application__c → Job_Candidate__c (Master-Detail): This relationship ensures that each application is tied to a specific candidate. On the Job Candidate record, you can see all related Applications.

Application__c → Open_Position__c (Master-Detail): This relationship ensures that each application is tied to a specific open position. On the Open Position record, you can see all related Applications.

By creating two master-detail relationships on Application__c, Salesforce automatically provides related lists on both parent objects (Job Candidate and Open Position). This satisfies the requirement to view applications from both perspectives.

Why Other Options Are Incorrect

A. Create a master-detail relationship on Open_Position__c to Application__c
Incorrect because the master-detail must be defined on the child (Application__c), not on the parent (Open_Position__c). Parent objects cannot directly hold master-detail fields pointing to children.

B. Create a master-detail relationship field on Job_Candidate__c to Application__c
Incorrect for the same reason. The child (Application__c) must hold the master-detail field pointing to the parent (Job Candidate). You cannot define a master-detail on the parent object to the child.

Exam-Oriented Reasoning
This question tests your ability to recognize junction object design. When two objects need to have a many-to-many relationship (Job Candidates ↔ Open Positions), you create a third object (Applications) with two master-detail relationships pointing to each parent.

References
Salesforce Help: Understanding Master-Detail Relationships
Trailhead: Data Modeling – Many-to-Many Relationships

Explanation:
Service Agents must confirm a user’s identity before giving support information. This requirement is about guiding the agent through a structured process during a live interaction. The best Salesforce feature for this is Guided Action Flows embedded on the record page.
Guided Action Flows allow app builders to embed a Flow directly into the Case record page.
These flows can present step‑by‑step screens to the agent, prompting them to ask identity verification questions, capture responses, and enforce business rules before proceeding.
This ensures consistency, compliance, and auditability across all agents handling support calls.
This declarative solution is exam‑relevant because it leverages Flow, Salesforce’s most powerful automation tool, and aligns with the requirement to enforce a structured identity check process.

Why Other Options Are Incorrect

B. Add Path to the top of the Case layout
Path is
used to guide users through stages of a process (like Opportunity stages). It provides visual cues but does not enforce step‑by‑step identity verification or capture responses.

C. Include Surveys as a Case related list
Surveys are used to collect feedback from customers, not to guide agents during live support calls.
They cannot enforce identity verification before providing information.

D. Case Validation Rules
Validation rules enforce data integrity when saving records.
They cannot guide agents through identity verification steps during a phone call.

Exam-Oriented Reasoning
The phrase “confirm a user’s identity before providing support information” signals a need for guided, interactive enforcement.
Path → visual guidance only.
Surveys → customer feedback, not agent workflow.
Validation Rules → enforce data entry, not live process steps.
Guided Action Flows → interactive, step‑by‑step enforcement of identity checks.
Thus, the only correct choice is Guided Action Flows on the record page.

References
Salesforce Help: Surveys Overview
Salesforce Help: Validation Rules

Explanation:
DreamHouse Realty executives want to enforce an internal policy for travel requests. This requirement is not just about automation but about formal review and enforcement. In Salesforce, the feature designed for this exact scenario is the Approval Process.

An Approval Process allows you to:
Define criteria for when a record (like a travel request) enters the approval cycle.
Route the request to one or more approvers (e.g., executives or managers).
Enforce business rules by requiring explicit approval before the record can proceed (e.g., before booking flights).
Automate actions at each step (field updates, email notifications, locking records).
This ensures compliance with internal policies and provides a structured, auditable workflow for approvals.

Why Other Options Are Incorrect

A. Process Builder
Process Builder automates actions (field updates, notifications, record creation) based on conditions.
It cannot enforce approval or rejection decisions. It’s useful for automation but not for policy enforcement requiring human approval.

B. Workflow Rule
Workflow rules are older automation tools for simple “if/then” actions (field updates, email alerts).
They cannot handle multi-step approvals or enforce executive sign-off.
Salesforce is also retiring Workflow Rules in favor of Flow.

D. Apex
Apex is custom code used for complex logic beyond declarative tools.
While Apex could theoretically enforce approvals, it would be over-engineering. Salesforce provides Approval Processes natively for this exact use case.
Exams emphasize declarative-first solutions unless requirements cannot be met without code.

Exam-Oriented Reasoning
When the question mentions “enforce internal policy” and “submission of request forms”, the key is recognizing this as a business approval requirement. Declarative automation tools like Workflow or Process Builder automate actions but do not enforce human approvals. Apex is powerful but not exam-best practice unless declarative tools fail.

Thus, the Approval Process is the only correct choice because it:
Routes requests to approvers.
Enforces compliance.
Provides auditability.
Is the standard Salesforce declarative solution for approval workflows.

References:
Salesforce Help: Approval Processes Overview
Salesforce Help: Process Builder Overview