Explanation:

Why this answer is correct
Public Groups are purpose-built for scenarios where you need to target a specific, heterogeneous set of users—often spanning different departments, profiles, and roles—for sharing and notifications. In Salesforce, Email Alerts (the action you use in Flow, Process, or Workflow) can be addressed to Public Groups directly, which makes them ideal for sending a single notification to “everyone on this project,” even when that team is a cross-functional mix. Because your project teams include users with different roles and different departments, you can’t rely on role-based or org-structure-based targeting; a group that you define explicitly for each project is the clean, least-surprising way to ensure exactly the intended recipients get the email when the Project status changes to Allocated.

Operationally, you would:

Create a Public Group per project (e.g., “Project Phoenix Team”), add the relevant users (and, if helpful, other groups/roles/subordinates),
Build a Record-Triggered Flow (or Process Builder/Workflow if still in use) on the Project object that fires when Status changes to Allocated,
Use an Email Alert action whose recipients include the corresponding Public Group.

This keeps the logic declarative and easy to maintain. When team composition changes, an admin (or delegated owner) simply adds/removes users in the group—no need to touch the automation or create complicated recipient logic. Importantly, Public Groups are recognized recipients in many places: Email Alerts, Report & Dashboard sharing, folder sharing, and record sharing (when combined with sharing rules), which keeps your “who is on this project” list reusable across the platform.
Finally, using Public Groups avoids security/visibility side effects. You are not reshaping your role hierarchy (which affects reporting rollups and implicit sharing), nor are you using queues (meant for record ownership handoff, not broadcast notifications). Public Groups give you precise targeting for the email without unintended consequences elsewhere. For an exam-style best practice answer, this is the standard, scalable choice: public group per project + email alert to that group.
Good references to review: Salesforce Help on Public Groups (creating and adding members) and Email Alerts (supported recipient types include Public Groups).

Why the other options are incorrect?

A. Configure a queue for the project team and have members view the queue’s list view.
Queues are designed primarily for record ownership and work distribution (e.g., Cases, Leads, custom objects set “Queue-enabled”), not for addressing notifications to a set of people. Adding users to a queue makes the queue the owner of records so members can claim or work those records; it does not inherently function as a mailing list for email alerts. While some automations can notify a record owner (which might be a queue for supported objects), that’s both indirect and brittle here: (1) it depends on using an object that supports queues and assigning the project record to the queue (not typical for a “Project” record), and (2) many project scenarios don’t want the queue to be the owner at all. Moreover, a queue doesn’t solve the requirement to notify all project team members just because status changes—you would still need logic to ensure the queue is the recipient, and even then, a queue is a single entity, not an explicit, flexible roster of varied users you can also reuse for sharing and reporting. In short, queues are the wrong abstraction: they’re for triage and assignment, not a clean cross-functional notification list. Public Groups exist precisely to aggregate users for sharing/notifications; queues don’t replace that function, and they can add ownership side effects you likely don’t want for Projects.

B. Use sharing rules to automatically share with the individual users in the project team.
Sharing rules control data visibility, not who receives an email. You can grant read/write access to project records to a set of users, roles, or groups with sharing rules, but that alone doesn’t send notifications to those users when status changes. You’d still need a separate mechanism (Flow/Email Alert) for sending the message—and when defining recipients in an Email Alert, you can’t target a list of “users who got access via sharing rules” as a dynamic recipient set. Practically, you’d end up duplicating membership logic in two places: once in sharing rules and again in the email’s recipient list. That’s harder to maintain and error-prone. Also, the question’s goal is ensuring proper users receive the email, not expanding access. Public Groups directly satisfy the recipient target; sharing rules alone do not provide an addressable notification audience.

C. Move the project users to the same role and send the email alert to everyone in the role.
Changing users’ roles just to target an email is an anti-pattern. The Role Hierarchy models management/reporting structure, influences implicit record access (role roll-ups), and affects many other areas (e.g., forecast rollups, reporting). Moving cross-functional project members into a single role merely to send an email breaks your org’s security model and reporting semantics. It also scales poorly: each new project would need a new role (or shuffling users across roles), causing constant churn and potentially violating the principle that roles reflect organizational lines, not ad hoc teams. Even if you could aim an Email Alert at a role, that list would include everyone in that role, not just the curated team for a given project. Because project teams are cross-role by design, a Public Group—which can include users from any role/department—is the correct, minimal-disruption solution.

Bottom line:
Queues are for ownership/work routing (not mailing lists), sharing rules grant visibility (not notifications), and roles reflect org structure (not ad hoc teams). Public Groups are the right construct to represent a project team and to receive a single email alert when the project status flips to Allocated.

Explanation:

The scenario describes a two-tiered password policy: a baseline for all users and a more stringent policy specifically for administrators. The key is to understand where Salesforce allows you to define and enforce different password rules for different sets of users.

Why C is Correct: Profile-Specific Password Policies
Salesforce allows for granular password policies to be defined at the Profile level. This is the mechanism designed explicitly for this use case.
The administrator at Ursa Major Solar has already set the organization-wide default (8 characters, 90 days). However, the requirement is to create a stricter rule for a specific group of users (those with the System Administrator profile).
How it works:
By navigating to Setup -> Administration -> Users -> Profiles, selecting the "System Administrator" profile, and then clicking on "Password Policies," the admin can override the org-wide default. Here, they can set the Minimum Password Length to 15 and the Password Expiration period to 30 days.
Result:
Any user assigned to the System Administrator profile will be governed by these stricter rules, while all other users will remain under the more lenient organization-wide policy. This perfectly satisfies the security team's new directive.

Why the Other Options Are Incorrect:

A. Organization-wide password policies:
This is where the baseline policy for all users is set (Setup -> Security -> Session Settings). Changing this would affect every user in the org, forcing all sales reps, service agents, etc., to have 15-character passwords that expire every 30 days. This contradicts the scenario, which requires different rules for different user types.
B. Password complexity requirements on the permission set:
This is a distractor. Permission Sets are used to grant access (to apps, objects, fields, etc.), but they do not contain settings for password policies like length and expiration. Password complexity (requiring a mix of letters, numbers, and symbols) is part of the org-wide policy, not something assignable via Permission Sets.
D. Session Settings on the User record:
Session Settings (which include session timeouts and other security controls) are configured at the org-wide or profile level. There is no option on an individual User record to set a custom password expiration period or minimum length for that single user. This level of granularity is managed at the profile level.

Conclusion
When a security policy requires different password rules for different classes of users (e.g., standard users vs. administrators), the correct and only supported method is to define those stricter rules on the specific Profile assigned to those users. The System Administrator profile has its own Password Policy section that overrides the organization-wide defaults.

Key Topic:
Salesforce Help & Training documentation on "Password Policies," specifically the section explaining that you can set password policies for the entire organization and then define more restrictive policies for specific administrator profiles.

Explanation:

The goal is to reduce the file size of a full data export. A full export includes all of an organization's data.

Why A is Correct:
The most direct way to reduce the export size is to export fewer objects. If the business goal doesn't require a complete snapshot of every single object, excluding non-essential ones will significantly decrease the total data volume and speed up the export process.

Why C is Correct:
Files stored as attachments, documents, and in the Notes & Attachments related list are often the largest contributors to export size. Deselecting the "Include images, documents, and attachments" checkbox excludes this binary file data from the export, resulting in a much smaller and faster export that contains only the structured data (records and fields).

Why E is Correct:
In Salesforce, when a record is deleted, it is moved to the Recycle Bin and is still stored in the database. A full data export includes the contents of the Recycle Bin. Therefore, by regularly emptying the Recycle Bin (thus keeping deleted record counts to a minimum), you permanently remove that data, which will no longer be included in the export, reducing its size.

Why B is Incorrect:
The frequency of backups (e.g., every 5 days) does not affect the size of an individual export file. A more frequent export schedule creates more files over time, but each file's size is determined by the data in the org at that moment. This recommendation does not address the core problem of reducing the size of a single export.

Why D is Incorrect:
There is no "Unselect the recycle bin" checkbox in the Data Export service. The only options are to include or exclude files and to schedule the export. The Recycle Bin data is automatically included in a full export; the only way to exclude it is to empty it before the export (as stated in E).

Reference: Salesforce Help: "Export Data from Your Organization"
The documentation for the Data Export service clearly shows the option to "Include images, documents, and attachments," noting that selecting it will "increase the size of the downloaded file." It also explains that the export includes all data, which inherently includes records in the Recycle Bin until they are permanently deleted.

Explanation:

Cloud Kicks needs to make inventory data from a legacy application available for viewing and reporting in Salesforce without duplicating or manually managing the data. The solution should integrate the external data seamlessly into Salesforce. Here’s why creating an external object is the best approach and why the other options are less suitable:

A. Create an external object that maps to the inventory application:
External objects in Salesforce allow integration with external data sources (like the legacy inventory application) using Salesforce Connect. This enables real-time access to the external data, which can be viewed, queried, and included in reports within Salesforce as if it were native data. External objects are ideal for this scenario because they avoid data duplication, support reporting, and maintain data in the legacy system while making it accessible in Salesforce.

How it works:
Set up Salesforce Connect with an OData or custom adapter to connect to the legacy application’s API.
Define an external object in Salesforce that maps to the inventory data tables/fields in the legacy system.
Create external object relationships or custom report types to enable viewing and reporting in Salesforce.
Why it’s best:
This provides a scalable, real-time integration without manual data imports, aligning with the goal of viewing and reporting on inventory data.

Why not B (Import the data into a custom object when needed; delete after it is used)?
Importing data into a custom object requires manual or scheduled uploads (e.g., via Data Loader), which is inefficient and prone to errors. Deleting the data after use prevents historical reporting and creates a maintenance burden. This approach also risks data inconsistencies between Salesforce and the legacy system, unlike real-time access via external objects.

Why not C (Build a Lightning component and use SFDX to connect to the inventory app)?
While a Lightning component could display external data by calling the legacy application’s API, building a custom component requires significant development effort. Salesforce Developer Experience (SFDX) is a tool for source-driven development, not a direct integration method. This approach is overkill compared to external objects, which provide native integration and reporting capabilities without custom coding.

Why not D (Upload an Excel spreadsheet with the data into the Files tab)?
Uploading an Excel spreadsheet to the Files tab allows storage but does not integrate the data into Salesforce for viewing or reporting. Files cannot be queried or included in Salesforce reports, making this unsuitable for the requirement.

Additional Notes
Prerequisites: Ensure the legacy application has an API (preferably OData-compatible) or supports a custom adapter for Salesforce Connect. Salesforce Connect requires a separate license.
Reporting: To enable reporting, create a custom report type including the external object or relate it to other Salesforce objects (e.g., Accounts) if needed.
Security: Configure external object access via profiles or permission sets to ensure only authorized users can view the inventory data.

References
Salesforce Help: Salesforce Connect (Trailhead module: “Salesforce Connect” in the Admin Advanced Trailmap for external object setup).
Salesforce Help: External Objects (covers mapping external data for viewing and reporting).

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.