Explanation:

Here’s the practical, “no-surprises” version:

Where to change it:
In the desktop UI, open the Opportunity and click Change Price Book (in Classic it’s a link; in Lightning it’s usually an action under the highlights panel or in the “Related/Details” action menu).
Precondition:
If the Opportunity already has Opportunity Products (line items), Salesforce locks the price book. You must remove all line items first, then you can switch the price book, and re-add items from the new price book.
Availability/permissions:
The new price book must be Active and Available to the user’s profile/permission set.
Users need the standard permissions to edit Opportunities and add products.
Data integrity tip:
Changing price book mid-deal can affect totals/discounts. After switching, re-add products with matching SKUs (if available) and verify Amount and Schedules/Discounts.
UX reality:
The Forecasts tab has nothing to do with price books; it won’t let you change them. Salesforce mobile doesn’t provide a change-price-book action—use desktop for this task.

Why the other options are wrong

A. “Once selected, the price book can be updated via the Forecasts tab.” — Incorrect
The Forecasts tab is for pipeline/forecast visibility and adjustments (e.g., committing amounts). It does not edit price books, products, or most Opportunity metadata. You must change the price book on the Opportunity itself, not from Forecasts.
B. “Once selected, the price book is locked on the opportunity.” — Misleading/Incomplete
It’s not permanently locked. It’s locked only while the Opportunity has line items. Remove all Opportunity Products and the Change Price Book action becomes available again. After switching, re-add products from the new book. (This protects data integrity—line items must come from the same price book as the Opportunity.)
D. “The change can be made through the mobile app.” — Not supported
The Salesforce mobile app doesn’t expose a native Change Price Book action. Reps can edit Opportunities and add products if set up, but switching the price book after one has been chosen is a desktop task. (If this comes up often, you could explore custom mobile actions/flows, but out of the box, use desktop.)

Pro tips to avoid surprises

Totals & discounts:
After switching price books, verify Amount, discounts, and any schedules—the new book may have different list prices.
Quotes/CPQ:
If you use Quotes or CPQ, ensure the Opportunity and related Quote/Quote Line Items stay aligned after the switch.
Access:
Confirm users have Read access to the new price book (via profile/perm set) and that the price book is Active—otherwise it won’t appear when re-adding products.

Explanation:

What it does
Setup Audit Trail records administrative/configuration changes made in Setup. This includes changes to User records such as:
Profile assignments (e.g., “User Profile changed from Standard User to Sales User”),
Permission set assignments and other setup-level actions,
Metadata updates like Validation Rules, Flows, Fields, etc.
Why it satisfies the requirement
“When”: Each entry shows the date/time of the setup change.
“Who”: Each entry shows the user who performed the change.
“What changed”: It indicates the action (e.g., “Update User”) and typically includes details like the user affected and new/old values where relevant.
How to access & use it (helpful in practice)
Setup → Security → View Setup Audit Trail (or search “Audit Trail” in Quick Find).
Filter or export the log (CSV download) to review a time range and identify all profile changes to users.
Keep in mind retention: the UI shows the most recent 20 entries and up to 6 months of history; you can download the full CSV (recommended for audits).
For ongoing audits, schedule a periodic export (e.g., via Data Export or automated governance process) so you retain longer history outside Salesforce if required by your compliance policy.
Exam tip:
When the question is about who changed configuration (profiles, security settings, metadata), think Setup Audit Trail.

❌ Why the other options are incorrect

A. Field History Tracking
What it tracks: Data changes on record fields for objects that support field history (e.g., Account Name, Opportunity Stage).
Why it fails here:
The User object does not support field history tracking, and even for objects that do, Profile is not a standard field you can track via field history.
Field History Tracking is for data changes, not setup/admin actions performed in Setup.
Bottom line: It won’t tell you who changed a user’s profile assignment.

C. Historical Trending
What it’s for: Trending certain numeric, currency, or percentage fields over time in reports (e.g., pipeline trending).
Why it fails here:
It does not capture setup changes or user profile assignments.
It’s designed for business metric trending, not security/compliance auditing.
Bottom line: Irrelevant for admin-level change tracking.

D. Analytic Snapshot (now called Reporting Snapshot)
What it’s for: Periodically save report results into a custom object to analyze changes over time (e.g., weekly case backlog).
Why it fails here:
It doesn’t log who changed setup or when; it just stores scheduled report data.
You’d still need a source report that contains setup change info—which standard reports don’t provide for admin actions.
Bottom line: Not a mechanism for auditing setup changes like profile swaps.

Extra credit / best-practice notes (useful for real orgs and exams)
Retention planning: If your compliance policy requires >6 months of history, establish a process to export the Setup Audit Trail regularly and retain it securely.
Shield Event Monitoring (if licensed) can provide Login and API event logs but still doesn’t replace Setup Audit Trail for configuration change lineage.
Change Management: Pair Audit Trail with a formal deployment process (change sets/DevOps Center/CI-CD) so you have both an audit of setup changes and a source-controlled history of metadata changes.

Bottom line
To answer “track when a user’s profile has been changed and who changed it,” the only option in the list that records setup/administrative changes with who+when is B. Setup Audit Trail. The others either track data changes (Field History), metric trends (Historical Trending), or report snapshots—none of which capture admin-level profile reassignment events.

Explanation:

Why it’s correct:
The Fields component in Lightning App Builder lets you place specific individual fields from a record anywhere on the Lightning page. This satisfies “only see certain fields” without exposing the rest of the page-layout fields.

Why the others are incorrect:
A. Record Detail Component – Renders the entire page layout (or a large section of it). You can’t easily restrict it to just a few fields unless you create and assign a separate page layout, which affects other contexts.
C. Highlights Panel Component – Shows fields from the Compact Layout and standard record actions. It’s limited to that top summary area and not intended for arbitrary subsets of fields throughout the page.
D. Path Component – Visualizes progress through a picklist path (e.g., Stage) and optional Guidance for Success. It doesn’t control field visibility for arbitrary fields.

References:
“Lightning App Builder – Standard Components (Fields, Record Detail, Highlights Panel, Path)” in Salesforce Help & Training / Trailhead documentation.
“Compact Layouts and the Highlights Panel” in Salesforce Help (for what appears in Highlights Panel).

Explanation:

Warning message: Deselecting the "disable session timeout warning popup" setting ensures users receive a warning message before their session expires due to inactivity.
Preventing unexpected logout: This allows users to extend their session or save their work, preventing them from being logged out unexpectedly.

Why other options are incorrect

B. Select force logout on session timeout: Enabling this setting would cause users to be logged out immediately upon session timeout without any warning, which is the opposite of the desired outcome.
C. Remove the session timeout settings: Removing session timeout entirely is a security risk and is not a recommended practice.
D. Enable Remember me until logout: This option is related to retaining login credentials and not directly to preventing unexpected session timeouts during an active session.

Explanation:

A. Setup Audit Trail:
This is the correct answer. The Setup Audit Trail logs administrative changes to an org's setup, including:
Who made the change.
What the change was (e.g., creating a new field, changing a profile's permissions, or modifying a workflow).
When the change occurred.
The audit trail is the primary tool for a Salesforce administrator to track and monitor configuration changes within the production environment.

B. Field History Tracking:
This tracks changes to specific field values on individual records, not changes to the org's metadata or configuration. For example, it would show that a user changed the "Amount" on an Opportunity, but not that a new custom field was created on the Account object.

C. Login History:
This tracks user login attempts, including successful and failed logins, timestamps, and IP addresses. It does not provide information about changes made to the org's configuration.

D. Organization-Wide Defaults:
This setting defines the baseline record access for users, but it is not a log of changes. While changes to OWDs are logged in the Setup Audit Trail, the OWD section itself is for configuring access, not auditing past changes.