Explanation:

When a user is locked out due to too many failed login attempts, Salesforce automatically freezes the account for security. An administrator can resolve this in two simple, declarative steps directly from the User record detail page in Setup: (C) Click Reset Password to generate and email a new temporary password (which also resets the security token), and (D) Click Unlock to immediately remove the lockout flag. These actions are instant, secure, and standard admin procedures—no code or downtime required—and they restore access within seconds while maintaining audit trails in Login History.

Why the Other Options Are Not Correct

A. Log in as the user to unlock the user and reset the password
Login As is disabled by default in most orgs for security compliance (GDPR, SOC2), and even when enabled, it does not unlock a locked account or reset passwords. It only lets admins impersonate active users—it cannot fix lockouts or generate new credentials.

B. Reset the password policies to allow the user to login
Password policies (complexity, expiration, lockout duration) are org-wide settings in Setup > Security > Password Policies. Changing them (e.g., increasing failed login attempts) does not unlock an already-locked user—it only affects future lockouts. The current lock must still be manually cleared via the User record.

References:
Salesforce Help: Unlock a Locked User
Salesforce Help: Reset a User’s Password
Trailhead: Manage User Access and Security

Explanation:

The requirement is to send data from Salesforce to an external system. This is a classic integration scenario, and an Outbound Message is the specific workflow action designed for this purpose.

Let's break down each option:

B. Outbound Message
Correct. An Outbound Message is a workflow action that sends a configured SOAP message (a standard web service protocol) to a designated external endpoint. The administrator can define which fields to send, and when the workflow rule triggers (e.g., when a record is created or meets certain criteria), it will send this message to the external accounting system's URL.

A. Assign Task
Incorrect. This action creates a task for a user within Salesforce. It is for internal task management, not for sending data to an external system.

C. Create Record
Incorrect. This action creates a new record within Salesforce. It does not send any information to an external system.

D. Custom Notification
Incorrect. A Custom Notification sends an alert to a user or group of users within Salesforce (or via the mobile app). It is an internal communication tool, not a method for system-to-system integration.

Summary:
For point-to-point integration where Salesforce needs to proactively notify an external system of a data change, the Outbound Message is the standard, declarative workflow action to use.

Reference:
Salesforce Help: "Outbound Messages"

This documentation describes outbound messages as a way to "send information to an external system" and explains how they are triggered from workflow rules or processes.

Explanation:

The Marketing User checkbox is a specific permission that grants a user the ability to manage campaigns, including creating, editing, and deleting them, as well as managing campaign members. Without this box checked, a user can typically only view campaigns and run reports.
Enabling this checkbox is the most direct way to give a user the ability to add and update campaign members, which is the exact issue the sales user is facing.

Why other options are incorrect:

A. Create a permission set to allow the user to edit Campaign Members:
While a permission set could theoretically be used to grant this access, the "Marketing User" checkbox is the primary and most comprehensive feature license designed for these specific campaign management capabilities.

B. Provide the user access to both Leads and Contacts to edit all Members:
Permissions for the Lead and Contact objects are separate from the permissions needed to manage Campaign Member records. Having access to a Lead or Contact does not automatically grant the ability to add or update them as Campaign Members.

D. Run a Campaign report and update any Member information via Data Loader:
This is a workaround that an administrator could perform, but it does not solve the user's inability to manage campaign members directly in the user interface. The goal is to troubleshoot the user's access, not to perform the task for them.

Explanation:

The requirement is to control which columns (fields) are displayed in a related list on a record page for different sets of users. This configuration is performed using the Page Layout Editor.

Let's break down each option:

C. Page Layout editor
Correct. The administrator can create two different Account Page Layouts—one for Sales users and one for Customer Care users. On each layout, the administrator can customize the Cases related list. They can add, remove, and reorder the columns to show the specific fields each team needs (Created Date and Status for Sales; Owner, Status, and Contact for Customer Care). By assigning these different page layouts to the respective user profiles, each team will see the tailored related list.

A. Related Lookup Filters
Incorrect. Related Lookup Filters are used to filter which related records appear in the list (e.g., only show Cases where Status is "New"). They do not control which fields/columns are displayed for those records.

B. Compact Layout Editor
Incorrect. Compact Layouts control the fields that appear in the hover panel (or "pop-up") when you click a record name, such as in search results or a lookup dialog. They do not control the columns in a related list on a record page.

D. Search Layout Editor
Incorrect. Search Layouts determine which fields are displayed in the search results list for an object. They do not affect the columns shown in a related list on a record page.

Summary:
The columns displayed in a related list are a property of the Page Layout. To show different fields to different users, you must create different page layouts and assign them via profiles or permission sets.

Reference:
Salesforce Help: "Customize Related Lists Using the Page Layout Editor"
This documentation explains the process of modifying related list columns directly on a page layout, which is the solution for this requirement.

Explanation:

A. Currency Locale
Configuring the Currency Locale is a core Company Setting that controls how currency values are formatted across the org—things like the currency symbol (€, $, £), decimal and thousands separators, and placement of the symbol relative to the number. This is especially important for a global user base because it ensures monetary amounts display consistently and in a way that aligns with the company’s preferred formatting. If your org does not use Multiple Currencies, the Currency Locale effectively dictates the single currency format used throughout Salesforce; if Multiple Currencies is enabled, you’ll still choose a Corporate Currency, but the locale setting remains a Company-level preference for formatting. Making this change at the Company Settings level provides a unified experience without requiring per-user tweaks.

B. Default Language
Default Language is also part of Company Settings and determines the baseline language for UI labels, standard text, and setup menus across the org. While individual users can select their personal language preference, setting the Company’s Default Language creates a consistent foundation for new users and serves as a fallback when a user-specific choice isn’t set or when certain translations aren’t available. For global teams, choosing an organization-wide default (often English) and then allowing user overrides is the standard best practice—ensuring onboarding is straightforward while still accommodating regional needs.

Why the others are not correct

C. Password Policy (Not a Company Setting)
Password Policies are configured under Security and govern authentication requirements (length, complexity, expiration, lockout thresholds). Although they’re typically org-wide (with optional profile-level overrides), they are not part of the Company Settings area that deals with language/locale/fiscal year/business hours. They’re security controls rather than company identity or localization settings. So while crucial for a global team, they don’t answer a question specifically about “Company Settings.”
D. Login Hours (Not a Company Setting)
Login Hours are configured on Profiles, not at the Company Settings level. They restrict when users assigned to a profile may log in (for example, 8:00–18:00 in a given time zone). Because this is profile-based, it’s considered a security/Access configuration rather than a global Company Setting. For a global team with varied time zones, company-level configuration doesn’t apply here; you’d set appropriate windows per profile (or avoid using them if they would block legitimate off-hours access).

Practical admin tip:
For global org readiness under Company Settings, focus on Default Language, Locale, Time Zone, Currency Locale, Fiscal Year, Business Hours, and Holidays. Use profiles/permission sets for access controls like Login Hours and keep Password Policies under Security to meet compliance without conflating them with Company Settings.