Explanation:

Why C is correct:
A change set is the standard declarative tool for migrating configuration from a sandbox to production. When you add a field to a change set, it includes the field's definition and all its associated field-level security (FLS) settings for all profiles. By adding the Amount field and selecting all six custom profiles in the change set, you are packaging the exact FLS configuration (visible/read-only/required for some, hidden for others) that you configured in the sandbox. Deploying this change set will apply the same FLS settings to the profiles in production, ensuring the change is replicated accurately and efficiently.

Why A is incorrect:
You cannot "push" a sandbox template to production. Sandbox templates are used to define the data and configuration of a new sandbox at the time of its creation. They are not a deployment mechanism for moving specific changes from an existing sandbox to production.

Why B is incorrect:
While manually updating the FLS in production via Setup would technically work, it is error-prone, time-consuming, and not a best practice. The question specifies there are six custom profiles, and the change was made to three of them. Manually re-applying these changes introduces a significant risk of human error (e.g., forgetting one profile, misconfiguring the permissions). The entire purpose of a deployment tool like a change set is to automate this process and guarantee consistency between environments.

Why D is incorrect:
This is a misunderstanding of how change sets work. You do not add profiles themselves to a change set to deploy FLS changes. The FLS is a property of the field. You add the field to the change set, and the deployment process reads the FLS settings for that field from the source sandbox and applies them to the target production org. Adding just the profiles would not convey the specific FLS settings for the Amount field.

Reference:
Salesforce Help: Deploy Change Sets - This outlines the process of using change sets.
Salesforce Help: Add Components to a Change Set - Specifically, when you add a field, it includes its "field-level security and field properties."

Explanation:

Why D is correct
The Lightning Service Console is designed for agents who juggle multiple records at once. It gives a workspace with primary tabs and subtabs, keyboard shortcuts, and utilities so support staff can open an Account in a primary tab, then work its related Opportunities, Cases, Contacts as subtabs—all in a single browser window. This eliminates the “too many browser tabs” problem and provides a faster, less confusing agent experience. It’s the standard Salesforce recommendation for high-volume support teams working across many records simultaneously.

Why the others are incorrect

A. Create a screen flow to pull all related opportunities onto one page
A screen flow could aggregate data, but it doesn’t replace multi-record navigation. Agents still need to open and work with different records and related lists. Flows are great for guided processes, not as a full agent workspace.

B. Enable Subtab Record Browsing in the Setup menu
This isn’t a stand-alone solution and is not the core feature that solves the “multiple records, one window” need. The console provides subtabbed navigation by design; toggling an obscure setting won’t deliver the comprehensive console experience (tabbed workspace, utilities, split view, related record subtabs, etc.).

C. Configure Split List Views
Split view lets users see a list and a single record’s details side-by-side, which is handy—but it still doesn’t handle multiple records and related objects as efficiently as a console with tabs/subtabs. It won’t fix the “many browser tabs” pattern for complex, multi-record work.

Bottom line:
For support agents working across Accounts and Opportunities at the same time, the Service Console is the purpose-built solution that consolidates work into tabs and subtabs within one window.

Explanation:

Why D is correct
You want automatic creation of the renewal opportunity so reps can focus on new business. The right tool is a Flow (record-triggered flow on Opportunity) that fires when the initial deal is Closed Won and then:

Creates a Renewal Opportunity (e.g., set Type = Renewal, relate to the same Account, set Close Date to original Close Date + term, copy key fields).
Clones the relevant Opportunity Line Items (the service plan products) onto the renewal.
Optionally sets ownership, forecast category, stage, next steps, and reminders.
Optionally uses Scheduled Paths to create or update the renewal later (e.g., X days before expiration) if your process requires it.

This delivers hands-off automation and consistent data—exactly what management wants.

Why the others are incorrect

A. Time-based workflow email reminder
Only sends an email; it doesn’t create the renewal. Also, Workflow Rules are legacy—Salesforce recommends Flow for automation.
B. Dynamic Lightning page with rich text reminder
A banner is just a hint. It still relies on reps to do manual work and won’t guarantee renewals are created or created consistently.
C. Validation rule blocking close until a renewal is associated
This forces manual creation before closing and can disrupt sales operations. It also doesn’t “automate the renewal process”; it just prevents closing until someone does extra work.

Implementation tips (exam-style):
Use a record-triggered after-save Flow on Opportunity when Stage = Closed Won and when products include service plans (filter by a field or Product Family).
Create Records: Renewal Opportunity (copy Account, set Type = Renewal, Close Date = formula based on service term).
Loop through OpportunityLineItems to Create related OpportunityLineItems on the renewal.
Optionally add a Scheduled Path to update reminders/owner handoffs closer to renewal date.

Salesforce refs:
Salesforce Help / Architect Guides: When to use Flow vs. Workflow (Flow recommended for new automation).
Salesforce Flow documentation: Record-Triggered Flows, Create Records, Loop & Assignment, Scheduled Paths.

Explanation:

B. Roll-up summary fields are created on the master side of a master-detail relationship. ✅
That’s the core rule: roll-up summaries live on the master object (here, Account) and summarize values from the detail object (here, Invoice, assuming Account ⟶ Invoice is master-detail). You can create summaries like totals, counts, minimums, and maximums of child records and display them right on the Account.

C. Roll-up summary fields prevent the conversion of a master-detail relationship to a lookup. ✅
If a master object has any roll-up summary fields that depend on its child relationship, Salesforce won’t let you convert that master-detail relationship to a lookup until those roll-ups are deleted. The roll-up relies on master-detail behavior (ownership, cascade delete, etc.), so conversion is blocked.

Why the others are incorrect

A. Roll-up types include COUNT, SUM, and AVG. ❌
Salesforce supports COUNT, SUM, MIN, and MAX—not AVG. If you need an average, you typically compute it with additional fields/flows (e.g., SUM ÷ COUNT) or Apex.

D. Rollup fields are calculated prior to save. ❌
Roll-up summaries are recalculated after the child records are inserted/updated/deleted/undeleted. Because they’re not computed in the “before save” phase, they’re not available for before triggers/validations as fresh values during the same transaction.

Exam tip:
Roll-up summaries require master-detail (native roll-ups aren’t available on plain lookups).
Supported operations are COUNT, SUM, MIN, MAX on child records that meet optional filter criteria.
Presence of roll-ups on the master can block relationship conversion to lookup and restrict some operations (like reparenting rules).

Explanation:

The requirement is to prevent sensitive data viewing after 10 minutes of inactivity. This is directly controlled by the Session Settings in Salesforce, specifically the Timeout Value and the behavior when that timeout is reached.
Session Timeout Value:
The administrator needs to set the Timeout Value to 10 minutes.
Force Logout:
By selecting the "Force logout on session timeout" option (which is often the default behavior when the timeout is reached), the system will automatically terminate the user's session when 10 minutes of inactivity pass. This forces the user to re-authenticate (log in again), ensuring that an unauthorized person who simply views an unlocked, unattended screen cannot continue to access the Salesforce data.

Why the Other Options are Incorrect

A. Enforce login IP ranges on every request: This setting restricts access to Salesforce only to users logging in from specified IP addresses. It helps secure access to the network, but it does not automatically log a user out based on inactivity once they are already logged in.

B. Lock sessions to the domain in which they were first used: This setting prevents a hacker from hijacking a session and attempting to use it from a different website domain. It is a defense against session hijacking but does not manage inactivity or log a user out after a specific time.

C. Require a high assurance session: A high assurance session is typically required for accessing sensitive data or executing critical actions (e.g., viewing salary details). It is often granted after a multi-factor authentication (MFA) step. This setting does not control the duration of the session based on inactivity.

Explanation:

Why A is correct
If users are missing email alerts because your org hit the daily single-email limit, the quickest way to diagnose and resolve is to pull an Email Log. The Email Log shows what did get sent (timestamps, recipients, sender, and the sending application like Workflow/Process/Apex), which helps you identify which automation is generating the volume and when you crossed the limit. With that visibility you can reduce volume (e.g., consolidate alerts, adjust criteria, batch notifications), or move some traffic to alternatives (in-app notifications, Slack, etc.).

Why the others are incorrect
B. HTML Email Status Report – Tracks opens/bounces for tracked HTML emails, and not reliably for workflow/process Email Alerts. It won’t help you understand why you’re hitting the daily send limit or which automation is causing the spike.
C. Notification Delivery Settings – Controls Salesforce notifications (in-app, mobile, email) for events like approvals and chatter, but it doesn’t diagnose or report email volume against limits for automated Email Alerts.
D. Outbound Messages – These are SOAP messages sent by workflow, unrelated to email volume limits; reviewing them won’t explain or fix email-limit overages.

Tips:
After reviewing the Email Log, tighten alert criteria, de-duplicate rules, consider digests or in-app notifications, and, if needed, stagger sends (e.g., scheduled flows) so you avoid bursting over the daily cap.

Explanation:

To determine how many unique accounts have open opportunities in the pipeline, the administrator should:

Create a report on Opportunities filtered by Stage = Open (or similar criteria).
Group the report by Account Name.
Use the “Show Unique Count” feature on the Account Name column to display the total number of distinct accounts represented in the report.

This method gives a precise count of unique accounts, not just the number of opportunity records.

❌ Why the other options are incorrect:

A. The row count on a summary report grouped by account name
This shows the number of opportunity records, not the number of unique accounts. Multiple opportunities from the same account would inflate the count.
B. A Cross Filter selecting opportunities with accounts
Cross filters help refine related records, but they don’t provide a unique count of accounts directly.
C. A custom report type showing opportunities with accounts
While useful for combining fields, it doesn’t inherently solve the need to count unique accounts unless paired with the “Show Unique Count” feature.

🔗 Reference:
Salesforce Help: Show Unique Count in Reports
Salesforce Trailhead: Reports & Dashboards

Explanation:

The requirement mentions that there are "many different types of documentation" and the documentation has "usage across the globe."

Data Categories in Salesforce Knowledge are the primary tool for categorizing and organizing articles based on topics (e.g., product type, region, audience). This addresses the need to manage "many different types of documentation."
Data Category Visibility controls who can see which articles. The administrator can define rules to show specific articles to:

The internal support team (for technical documentation).
Customers on a public site (for general product documentation).
Users based on their locale/region ("usage across the globe").

Defining data categories is essential for organizing the content and controlling access for both internal users and external customers.

Why the Other Options are Incorrect

A. Enable the Case Feed: The Case Feed streamlines the display of case interactions and details. It helps the support team work on cases but is not the tool used to organize and control the visibility of Knowledge articles.
B. Create article types: Article Types (now often called Knowledge Record Types) define the structure of the article (the fields and layout). While necessary, they don't provide the ability to categorize the content into a hierarchy (like by product and region) or control specific visibility for different groups of users or regions. Data Categories are the visibility mechanism.
D. Setup record types and page layouts: This is essentially the same as "Create article types" (Option B). Record Types control the structure and page layout of the article. They are required for the article's look and feel but do not control the hierarchical organization and region-specific visibility necessary for the use case.

Explanation:

Why A is correct
When one user hits a flow error but peers with “the same access” don’t, it’s often due to subtle permission/sharing differences (record-level access, FLS on a specific field, permission set variance, queue/group membership, etc.).
The Flow Debug tool lets you Run as another user, so you can reproduce the failing user’s exact context (object permissions, FLS, sharing) and pinpoint the failing element (e.g., an Update Records that can’t edit a field, or a Get Records failing due to sharing). This is the safest, targeted, and recommended troubleshooting step.

Why the others are incorrect

B. Move them higher in the role hierarchy
Role hierarchy affects record visibility, not all the other permissions (like FLS, object permissions, or flow-level checks). It’s a blunt change that may not fix the issue and can overexpose data unnecessarily.

C. Run the flow as System Context Without Sharing – Access All Data
This bypasses user-level checks and masks the root cause. It may “make the error go away,” but it overrides security and can lead to data changes users shouldn’t be allowed to make. Not appropriate just to troubleshoot one user’s failure.

D. Grant Modify All
Massively over-permissive; it gives full control over all records of an object (or the whole org if “Modify All Data”). This violates least-privilege principles and is not a diagnostic step.

Bottom line:
First, debug the flow “as the user” to see precisely where and why it fails under that user’s permissions/sharing, then fix the underlying access or logic—don’t paper over it with broad, risky permissions.

Explanation:

When a flow is working for some users but failing for another user, the problem is most likely related to the specific permissions, field-level security, or data access settings for that individual user. The "Debug As Another User" feature is the most efficient and direct method for an administrator to diagnose this type of issue.

Why A is correct:
By running the flow as the user who is experiencing the error, the administrator can bypass the limitations of their own (often elevated) permissions and experience the flow execution from the end-user's perspective. The debug log will then clearly show exactly where the flow failed, revealing the specific permission or access-related issue.

Why B is incorrect:
This is a broad, indirect, and potentially insecure solution. Moving a user higher in the role hierarchy might grant them sufficient access to run the flow successfully, but it doesn't identify or resolve the root cause. This approach also violates the principle of least privilege, as the user could gain access to data they don't actually need.

Why C is incorrect:
Running a flow in "System Context Without Sharing - Access All Data" is an extreme measure that should be used with caution. While it would likely make the flow succeed by ignoring all user permissions, it completely bypasses the organization's security model. This is a significant security risk and is not the correct way to troubleshoot a user-specific permission issue.

Why D is incorrect:
This is the most dangerous option from a security standpoint. Granting the "Modify All" permission gives a user the ability to view, edit, and delete all records for that object, regardless of standard sharing settings. It's a heavy-handed, insecure, and unnecessary solution for troubleshooting a single flow error.

Reference
Salesforce Help: Debug a Flow as Another User: "Test and debug a flow as another user without logging in as that user. You can troubleshoot a flow by seeing the flow's debug log as a user sees it." This page provides the step-by-step instructions for enabling and using this feature.
Trailhead: Debug Flows as Another User: A hands-on module that walks through the process of debugging a flow specifically in another user's context.

Study Tips
Practice in a Sandbox: The best way to understand this concept is to practice it. Use a developer org or a sandbox to intentionally create a permission-based flow error for a user and then use "Debug As Another User" to troubleshoot it.
Understand Context: Be familiar with the different Flow run contexts: User Context, System Context, and System Context Without Sharing. Know when each is appropriate and the security implications of each setting.
Permissions First: When troubleshooting a user-specific issue, always assume it's a permissions problem first. "Debug As Another User" is your first tool for validating this assumption.

Bottom Line
For a user-specific flow error, administrators should use the built-in "Debug As Another User" feature. It provides a non-intrusive and secure way to diagnose the problem by replicating the user's exact permissions and data access.

Explanation:

The Create and Upload Change Sets permission is required on the user's profile to create new change sets and upload them to a destination org (e.g., from sandbox to production). Without it, the new administrator would see the Change Sets setup but be unable to perform outbound actions, directly causing the reported issue. This permission is profile-specific and should be reviewed first for troubleshooting.

Why B is incorrect: Modify Metadata Through Metadata API Functions enables programmatic changes via the Metadata API (e.g., for tools like VS Code or SFDX), but it's not required for the standard UI-based change set creation and upload process.

Why C is incorrect: Deploy Change Sets is needed to validate and deploy inbound change sets in the receiving org, not for outbound creation or upload from the source.

Why D is incorrect: API Enabled grants general access to Salesforce APIs for integrations (e.g., REST/SOAP calls), but change sets are a declarative UI feature that doesn't rely on this permission.

References
Salesforce Help: Change Sets Permissions (lists "Create and Upload Change Sets" as essential for outbound functionality).
Trailhead: Change Sets Basics module, which covers profile permissions for creating and uploading sets.

Explanation:

A. Assignment Rules ✅
Use Lead Assignment Rules to automatically route each Lead to the correct planetary team (user or queue) based on the Planet field (e.g., Planet = Jupiter → Jupiter Team queue). This satisfies the requirement to automate which team is allocated the lead.

B. Validation Rules ✅
Use Validation Rules to enforce team-specific required fields. For example, if Planet = Jupiter, require “Moon” (and any other Jupiter-specific fields) before the record can be saved or advanced. Validation rules are the right way to make fields conditionally required based on values like Planet or owning team.

Why the others are incorrect

C. Matching Rules ❌
Matching (with Duplicate Rules) is for duplicate detection, not for routing records or enforcing conditional required fields.

D. Workflow Rules ❌
Legacy automation. While Workflow can update fields or send alerts, it’s not ideal for routing (Lead Assignment Rules are purpose-built) and cannot enforce required fields—that’s a job for Validation Rules. (Also, Salesforce recommends Flow over new Workflow usage.)

Exam tip:
Routing → Lead Assignment Rules.
Conditionally required fields → Validation Rules (e.g., AND(TEXT(Planet__c)="Jupiter", ISBLANK(Moon__c))).