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:

Salesforce Shield is a powerful suite of security tools that includes Shield Platform Encryption, Event Monitoring, and Field Audit Trail. When implementing Shield Platform Encryption, it's critical to understand how encryption interacts with Salesforce features — especially automation like Flows.

🔐 Why Option C Is Correct:
Paused Flows temporarily store data in the system while waiting for a user action or external event.
If the flow references encrypted fields, the data may be stored in an unencrypted state during the pause.
This poses a security risk, especially for sensitive data like PII, financial records, or health information.
Salesforce explicitly warns about this in Shield documentation — paused flows are not guaranteed to maintain encryption.

❌ Why the Other Options Are Incorrect:

A. Encrypted fields are able to be referenced in flows.
This statement is false.
Encrypted fields have limited support in Flows.
You cannot use encrypted fields in certain flow elements like decision logic, assignments, or formula fields.
They can be referenced in some cases, but with restrictions.

B. Einstein Lead Scoring is available on encrypted fields.
Einstein features do not support encrypted fields.
Encrypted data cannot be used in machine learning models, scoring, or analytics.
This is a known limitation of Shield Platform Encryption.

D. Shield Platform Encryption can be used with custom metadata types.
Custom metadata types are not supported by Shield Platform Encryption.
Encryption is available for standard and custom objects, but not for metadata.
This includes Custom Settings and Custom Metadata Types, which remain unencrypted.

📘References:
Shield Platform Encryption Considerations
Paused Flows and Encryption
Salesforce Shield Overview
These resources outline the limitations and risks associated with encryption in automation and metadata.

🎓 Exam Tip:
When a question involves encryption, always consider:
Feature compatibility (Flows, Reports, Einstein, Metadata)
Data lifecycle risks (Paused Flows, temporary storage)
Limitations on field types and usage
Shield is powerful, but not all features support encrypted data — and that’s a common exam trap.

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.