Explanation:

Opportunity Splits let companies share credit across multiple reps.
They require Opportunity Teams, since splits are allocated to team members.
By default, Salesforce provides Revenue Splits and Overlay Splits, and you can add custom types later — but enabling teams is the prerequisite.

A. Ensure open opportunities are owned by active users
❌ Not specifically a prerequisite.
While ownership by active users is important for general Salesforce data integrity, it’s not a requirement for turning on Opportunity Splits.

B. Enable Opportunity Teams and confirm the owner is a team member
✅ Correct.
Opportunity Splits relies on Opportunity Teams.
You must first enable Opportunity Teams, because splits are applied to team members (including the owner).
The owner must also be on the team, otherwise they can’t receive a split allocation.

C. Add customized split types to opportunities
❌ Incorrect.
Custom split types can be defined after Opportunity Splits is enabled, but they are not a prerequisite.

Salesforce Reference
Salesforce Help: Opportunity Splits
“Before you enable Opportunity Splits, make sure Opportunity Teams are enabled.”

✅ Exam Tip:
If you see “Opportunity Splits prerequisite” → always think Opportunity Teams first.

Explanation:

Cloud Kicks wants to:
Track contractors who frequently change companies
Retain the history of company relationships through Accounts
Avoid duplicating Contact records or losing relationship context
The Contacts to Multiple Accounts feature is purpose-built for this scenario. It allows:
A single Contact record to be associated with multiple Accounts
Each relationship to be defined with a Contact Role (e.g., “Marketing Contractor”)
Historical tracking of which companies the contractor was affiliated with over time
This ensures CK maintains a clean Contact database while preserving accurate Account relationships.

❌ Why the Other Options Don’t Fit:
A. Use a custom object to represent previous companies
Adds unnecessary complexity and breaks native Account-Contact relationships. Reporting and automation become harder to manage.
C. Implement Person Accounts
Person Accounts are designed for individual consumers, not for tracking B2B relationships across multiple companies. They don’t support multi-account relationships natively.

📘 Reference:
Salesforce Help: Contacts to Multiple Accounts
Trailhead: Data Modeling

Explanation:

reCAPTCHA Verification: The most direct and immediate solution to combat bot-generated spam on a standard Web-to-Lead form is to enable reCAPTCHA verification. This feature, available directly within Salesforce's Web-to-Lead settings, adds a challenge-response test (like "I'm not a robot" checkboxes or image puzzles) that is easy for humans to solve but difficult for automated bots. Since UC is already using a standard Web-to-Lead form, this is the most efficient and native "first line of defense."

Why the other options are incorrect:
A. Use a custom Web-to-Lead alternative with built-in protection: This is a valid long-term solution, but it's not the "first line of defense" for a company already using the standard Web-to-Lead. It requires custom development and would be more time-consuming than simply enabling a built-in feature.
B. Use an AppExchange package with custom Web-to-Lead handling: Similar to a custom solution, an AppExchange package is a more robust, but not immediate, solution. It requires evaluation, installation, and configuration, which goes beyond the initial, quick fix of enabling a native Salesforce setting.

Explanation:

The core issue is about sharing access to Contact records. In Salesforce, Contacts are separate objects with their own Organization-Wide Default (OWD) sharing settings. Even if a user can see an Account, they may not automatically see the Contacts related to that Account.
Account Teams are a powerful sharing tool. When you add a user to an Account Team, you can grant them specific object-level permissions for that particular Account and its related records.
One of these configurable permissions is "Read" access to Contacts. By adding the Opportunity owner to the Account Team and selecting this permission, the Account owner can selectively grant that user read access to all Contacts associated with that specific Account.
This provides a precise, manual method for the Account owner to share Contacts with other users (like the Opportunity owner) on a case-by-case basis, which is exactly what the requirement asks for.

Why the Other Options Are Incorrect:
A. Add Opportunity owners to the Opportunity Team and configure Contact sharing.
Opportunity Teams control sharing for the Opportunity object and its related records (like Opportunity Contact Roles). They do not control sharing for the Account object or its related records (like Contacts).
There is no setting on an Opportunity Team that can grant access to Account Contacts. This option misunderstands the scope of the Opportunity Team sharing model.

C. Transfer Contact ownership from themselves to the Opportunity owner.
This is a drastic, incorrect, and unsustainable solution.
Ownership implies responsibility; transferring Contact ownership away from the correct owner (likely the Account owner or a marketing user) to a sales rep just for viewing rights breaks data management best practices.
It is not "selective sharing"—it is a complete transfer of responsibility and would break any role hierarchies or sharing rules based on ownership.
This process would have to be repeated manually for every single Contact and then reversed, which is highly inefficient and error-prone.

Reference:
Salesforce Help: Account Teams

Key Concept: Understanding that visibility to an Account does not automatically grant visibility to its child objects (like Contacts and Cases). Sharing must be configured for each object. Account Teams provide a manual, record-level mechanism for the Account owner to share access to related objects with other users.

Explanation:

The Cloud Kicks team’s attendance at a conference next week indicates a potential scheduling conflict that could impact project activities, such as requirements gathering, workshops, or other planned tasks. The consultant should update the project plan to account for this downtime, rescheduling tasks or adjusting timelines as needed, and communicate the updated plan to stakeholders to ensure alignment and transparency. This approach maintains project momentum and keeps everyone informed.
Why not A.
Use the downtime to develop User Acceptance Testing (UAT) scripts?
While developing UAT scripts is important, it is premature if the project is still in the requirements gathering phase (as implied by the “last requirements meeting”). UAT scripts are typically developed during the Build or Test phases, after requirements are finalized. Using the downtime productively is a good idea, but updating the project plan is the priority to address the immediate impact of the team’s absence.
Why not C.
Ask the client to sign off on requirements and start the Build phase?
Asking for sign-off and moving to the Build phase assumes that requirements are complete, which may not be the case since the question only mentions a recent requirements meeting. Forcing a premature sign-off risks missing critical requirements, leading to rework later. The conference attendance suggests a temporary pause, not a signal to rush the process.

Reference:
Salesforce Trailhead: Project Management for Salesforce Implementations (covers managing project plans and stakeholder communication during changes).