Explanation:

Why it’s correct:
Data Classification lets admins tag fields (standard and custom) with metadata like Data Sensitivity and Compliance Categorization so you can flag where sensitive information lives across the org and report/export on it. That’s exactly what the compliance team asked for.

Why the other options are not correct

B. Schema Builder – Great for visualizing objects/relationships and creating fields, but it doesn’t classify/flag sensitive data.
C. Classic Encryption – Encrypts certain fields but doesn’t provide field classification/flagging; separate concept from identifying where sensitive data is stored.
D. Field-Level Security – Controls who can see/edit fields, not a catalog of which fields are sensitive. FLS doesn’t add sensitivity labels or compliance tags.

Exam tip
If the requirement says “flag/identify sensitive fields” for compliance and reporting, choose Data Classification. If it says “protect or hide data”, think FLS, encryption, or Shield—different objectives.

References
Salesforce Help – Data Classification overview (record sensitivity & compliance at the field level).
Salesforce Help – Data Classification metadata fields (what you can store/tag on each field).
Salesforce Help – Classic vs. Shield encryption (encryption ≠ classification).
Salesforce Help – Field permissions/FLS (access control, not classification).

Explanation:

Salesforce provides a security feature that allows administrators to restrict user logins to a specific range of trusted IP addresses. If a user logs in from an IP address outside of the allowed range configured on their profile, they will be denied access. This is a common issue when employees begin working from a new, remote location with a different public IP address than the one used at the company office.

Here's a breakdown of why the other options are less likely to be the primary cause:

A. The login session has expired for this user.
This would only affect a user who was already logged in and would typically not prevent them from logging in again. A full login failure on the first attempt after starting work remotely is more likely due to a persistent access restriction.

B. They are signing in from a mobile device.
Salesforce is fully accessible from mobile devices using the Salesforce mobile app. The platform does not, by default, restrict logins based on the type of device.

C. The time zone for the profile is outside of login hours.
Login hours are configured based on the organization's time zone and apply to all users on a specific profile, regardless of their location. While possible, it's a less common cause for a single user's login failure when moving to a new location. If login hours were the issue, the user would likely encounter a time-based restriction, not a general inability to log in from their new location.

How to confirm and resolve the issue:
Navigate to the user's profile in Salesforce Setup.
Go to the "Login IP Ranges" setting.
Check the user's login history to see if there is an IP address restriction error.
Add the user's new remote IP address to the allowed IP ranges on their profile.
If this is a company-wide change, consider adjusting broader Network Access settings instead of updating individual profiles.

Explanation:

This scenario has two distinct timing requirements for sending email notifications, and a single record-triggered flow with scheduled paths is the most declarative and efficient solution.

Here's a breakdown of why this is the correct approach:

Record-Triggered Flow:
The automation should be triggered by a change to an Opportunity record, specifically when it is created or updated. This is handled by a record-triggered flow.
After Record is Saved:
Sending an email is an action that requires a record ID and needs to happen after the record has been committed to the database. Therefore, the flow must run after the record is saved.
Scheduled Path for the Proposal Stage:
The requirement to send an email "a week before the close date" is a time-based action. A scheduled path within an after-save flow is the perfect tool for this. The path can be configured to run based on the CloseDate field.
Immediate Action for Budget Approved:
The requirement to send an email "immediately" when the Budget Approved custom field is checked can be handled as an immediate action within the same flow. The flow can use a Decision element to check if Budget Approved is true and then send the email.

Here is a breakdown of why the other options are incorrect:

A. Create a schedule-triggered flow. Configure the trigger to flow weekly:
A schedule-triggered flow runs on a set schedule (e.g., weekly) and processes a batch of records. This would not be able to meet the "immediately" notification requirement when Budget Approved is checked, as it would only process the record on the next scheduled run.

C. Create a record-triggered flow with scheduled paths. Configure the trigger to flow before the record is saved:
A "before save" flow is designed for fast field updates on the same record and cannot perform actions like sending emails. Actions and scheduled paths are only available for after-save flows.

D. Create a schedule-triggered flow for the Opportunity object. Configure the trigger to flow daily:
A schedule-triggered flow running daily would still not meet the "immediately" requirement. Furthermore, it would be less efficient than a record-triggered flow because it would process a large batch of records daily, many of which may not meet the criteria for a reminder. A record-triggered flow is more targeted and only runs when a specific record is changed.

Explanation:

A year-over-year (YoY) change calculation requires comparing a value from the current period (e.g., this year) with the value from the same period one year ago (e.g., last year). This is a sequential comparison across grouped data.

Let's analyze the options:

A. A row-level formula to compare amounts grouped by year. (Incorrect)
A row-level formula calculates a value for each individual row (record) in the report. It cannot access summary data from other groups or years. Since the YoY calculation requires the total for one year compared to the total for the previous year, a row-level formula is useless for this task.

B. A joined report with two report blocks for each year (Incorrect)
While a joined report could technically display the totals for two different years side-by-side, it is a manual and non-dynamic process. You would have to create and maintain two separate report blocks with different date filters. More importantly, a joined report cannot perform a calculation between the two blocks. You could see last year's total and this year's total, but you could not have a third column that automatically calculates the difference or percentage change.

C. A custom summary formula with PARENTGROUPVAL function (Incorrect)
The PARENTGROUPVAL function is used to reference a value from a parent grouping level in a hierarchy (e.g., getting the total for a Quarter to calculate the percentage of the Year total). It is not designed to access the value from a previous sibling group, like the previous year.

D. A custom summary formula with the PREVGROUPVAL function. (Correct)
The PREVGROUPVAL function is specifically designed for this type of sequential analysis. It allows a custom summary formula to retrieve the value of a summary field from the previous group in a series.
How it works: You would create a summary report grouped by "Fiscal Year" (or Closed Date grouped by Year). You would then create a custom summary formula that uses PREVGROUPVAL to get the total amount from the previous year's group and subtract it from the current year's total to find the change.
Sample Formula: (SUM(Amount) - PREVGROUPVAL(SUM(Amount), FY)) / PREVGROUPVAL(SUM(Amount), FY)
This would calculate the percentage change from the previous fiscal year.

Reference:
PREVGROUPVAL Function: A summary formula function that returns the value of a summary field from the previous group in the report. It is the essential tool for creating period-over-period comparisons, such as month-over-month or year-over-year changes.
Custom Summary Formulas: These are used to perform calculations on summarized data (like sums and counts) in a report, rather than on individual record data.

Explanation:

C. Create a custom object.
This is necessary because the form needs to be filled out more than once during a single sales cycle (Opportunity).
If the administrator were to add the 30+ fields directly to the Opportunity object, they could only store one set of responses.
By creating a Custom Object (e.g., "Client Form Submission") and relating it to the Opportunity with a Lookup or Master-Detail relationship, the sales team can create a new record for every submission, fulfilling the requirement for multiple submissions.

D. Turn on Field Tracking.
This is necessary because the sales team needs to "be able to see what changed from one submission to the next."
Field History Tracking can be enabled on the newly created Custom Object.
The administrator can select the 30+ fields for tracking. When a sales rep or automation updates any of these fields on a specific submission record, Salesforce automatically captures the old value, new value, user, and date/time of the change. This provides the audit trail needed to compare changes between versions of the form.

Why the Other Options are Incorrect

A. Add forms as attachments:
Storing the form as an attachment (File or Note) would address the submission, but it is not reportable. The data would be unstructured and cannot be used to track changes or build reports for the sales manager.

B. Make custom fields:
Custom fields are certainly needed for the 30+ questions. However, simply making custom fields on the Opportunity object (the assumed parent object) fails to address the requirement for multiple submissions over the sales cycle, which necessitates a custom object.