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:

Why these are correct

A. Profile Assignment:
To make a record type available to users, you must assign it to their profiles (or permission sets). This also lets you set a default record type per profile so users see it in the picklist (or skip the selection screen if only one is available).
D. Page Layout Assignment:
After enabling the record type for profiles, you assign the page layout that should display for that record type + profile combination. This is how you show the right fields/sections when users create/view Customer Warranty cases.

Why the others are not

B. Role Assignment:
Roles control data visibility (who can see which records), not which record types a user can choose or which layouts they see.
C. App Manager Assignment:
App assignments control which Lightning apps users can access. They don’t expose record types or determine page layouts.

Exam tip:
Record type visibility = Profile (or Permission Set). What the page looks like for that record type = Page Layout Assignment (by Profile + Record Type).

Explanation:

The Expected Revenue field on an Opportunity is an auto-calculated field. Its value is determined by the following formula:
Expected Revenue = Opportunity Amount * Probability %
The Probability percentage is not a free-form number; it is directly inherited from the Sales Stage of the Opportunity. Each stage in the Salesforce sales process has a default Probability value assigned to it.
Therefore, if the Expected Revenue is displaying an incorrect value, it is because the Probability percentage tied to the current Sales Stage is incorrect for Cloud Kicks' business process. The administrator must correct the probability at the source—the stage definition itself.

Why the Other Options Are Incorrect:
A. Update the expected revenue associated with the stage. This is incorrect. Expected Revenue is a calculated field on the record, not a value that is stored or defined within the stage configuration. You cannot "associate" a revenue value with a stage.
B. Adjust the forecast category associated with the stage. The Forecast Category determines how an Opportunity appears in Salesforce Forecasts and reports. While important for forecasting, changing it (e.g., from "Pipeline" to "Best Case") has no effect on the calculated Expected Revenue field.
C. Modify the closed won value associated with the stage. This is not a standard configuration. The "Closed" flag on a stage indicates if it is a terminal stage (either won or lost), but it does not control the probability percentage or the revenue calculation. A stage is simply marked as either closed (won) or closed (lost).

Reference:
Salesforce Help: "How is expected revenue calculated?"
This article explicitly states: "Expected revenue is the amount of revenue you expect to receive from a possible deal. It’s calculated by multiplying the opportunity amount by the probability." It further explains that "Probability is a standard field that’s automatically populated based on the sales stage of the opportunity."

Explanation:

✅ Correct Answer: B. Send email notifications
Case Escalation Rules in Salesforce are designed to automatically escalate unresolved cases based on predefined criteria — such as elapsed time, priority, or status. One of the most common actions configured in an escalation rule is to send email notifications to support managers, case owners, or escalation teams when a case meets escalation conditions.
This ensures that:
Critical cases receive timely attention
Stakeholders are alerted without manual intervention
Service-level agreements (SLAs) are upheld

Administrators can define email templates, recipients, and escalation timing in the rule setup.

✅ Correct Answer: D. Re-assign the Case
Another key action in escalation rules is reassigning the case to a different user or queue. This is useful when:

The original case owner hasn’t responded within the expected timeframe
The case needs to be escalated to a higher-tier support team
A specialized agent or manager should take over

Reassignment helps ensure that cases are handled efficiently and by the appropriate personnel, improving resolution time and customer satisfaction.

❌ Incorrect Answers:
A. Re-open the Case
Escalation rules do not reopen closed cases. They are designed to act on open cases that are not progressing as expected. Reopening a case would require a separate automation (e.g., Flow or Apex), and is not a native action within escalation rules.
C. Change the Case Priority
While changing priority might be a logical escalation step, escalation rules do not directly support field updates like changing priority. To achieve this, administrators would need to use Workflow Rules, Process Builder, or Flow in conjunction with escalation logic. Therefore, this is not a valid action within escalation rule configuration itself.

References:
Set Up Case Escalation Rules – Salesforce Help
Trailhead: Automate Case Management

Explanation:

Assignment Rules are the declarative automation tool designed specifically for automatically routing records (like Cases and Leads) to the correct user or queue based on defined criteria.

Let's break down why this is the correct choice and why the others are not:

B. Assignment Rules:
This is the precise function of Assignment Rules. The administrator can create a rule for Cases that evaluates conditions (in this scenario, the Case Priority) and then defines an action to assign the case to a specific queue. Since Assignment Rules can be set to run on every new Case creation (regardless of origin), they fulfill the requirement of working "regardless of how they are created."

A. Email-to-Case & D. Web-to-Case:
These are not routing tools; they are channels for case creation. They are methods through which a case enters Salesforce. While both have settings that can utilize Assignment Rules, they themselves do not perform the routing logic. They simply provide the data that Assignment Rules then act upon.

C. Auto-Response Rules:
This tool is used for communication, not routing. Auto-Response Rules automatically send a templated email response back to a customer when a case is created meeting certain criteria (e.g., "Thank you for your High Priority case, we will contact you shortly."). It does not affect who the case is assigned to.

Reference:
Salesforce Help: "Create Case Assignment Rules"