Explanation:

When a Salesforce implementation "Go-Live" overlaps with a high-stakes institutional event—such as a major capital fundraising campaign—the most significant risk is the lack of available time and personnel from the subject matter experts (SMEs).
Conflict of Priorities:
During a capital campaign, the Advancement staff’s primary focus is on donor outreach, event management, and gift processing. They will have little to no bandwidth for the final stages of a Salesforce rollout, which require intensive User Acceptance Testing (UAT), data validation, and end-user training.
Operational Risk:
Launching a new CRM during a peak period can lead to data loss or processing delays if issues arise during the migration. Without the Advancement team available to troubleshoot and verify donor records, the campaign's success is jeopardized.
Mitigation:
A consultant must identify this early to either shift the Go-Live date or secure dedicated resources that are not tied to the campaign's daily operations.

Why other options are incorrect:

B. Technical complexity:
While always a factor, the technical difficulty of the build does not change specifically because of a fundraising campaign. The timing is the primary risk here, not the code or configuration.
C. Staff cross-training:
While necessary for long-term success, cross-training is a standard project task. It does not carry the same "critical" weight as the potential total absence of staff during a launch window.
D. Cost of the implementation:
The budget is typically finalized during the discovery and scoping phases. While a campaign might provide more funding, the immediate threat to a project's Go-Live success is human capital (resource availability), not financial capital.

Reference:
Salesforce Change Management: Project Timing and Strategy: Highlights the importance of avoiding major institutional "blackout dates" during implementation.
Advancement Excellence in Education Cloud: Best practices for transitioning legacy systems to Salesforce specifically for fundraising offices.
Trailhead: Build a Change Management Strategy: Emphasizes that resource availability and staff readiness are the top predictors of a successful Go-Live.

Explanation:

When implementing Student Success Hub and Pathways, external users (such as students accessing their academic plans) need visibility into Program Plans. Program Plans define the academic structure (courses, requirements, milestones) that students follow.

By default, Salesforce orgs often set Program Plan sharing to Private for security. While this protects sensitive data, it also means external users cannot see the Program Plans unless explicit sharing rules are configured. The recommended setup is to create a Program Plan sharing rule that grants Read access based on record type.

This ensures:
Students can view their assigned Program Plans without being able to edit them.
Advisors and staff maintain full access to manage and update Program Plans.
Security is preserved, since sharing is limited to specific record types and profiles.
Pathways (which visualize degree requirements) can display correctly for external users.

❌ Why not the other options?
A. Create an Account sharing rule to provide Read access based on record type
Accounts (Households, Administrative Accounts) are not the primary object for Pathways or Program Plans. This does not meet the requirement.

C. Change the default Program Plan sharing setting to Private
This is already the default and would restrict access further, preventing external users from seeing Program Plans.

🔗 References
Salesforce Help: Program Plan Sharing in Student Success Hub
Trailhead: Student Success Hub Basics

Explanation:

In Education Data Architecture (EDA), Primary Affiliation fields on the Contact record (e.g., Primary Department, Primary Academic Program, Primary Business Organization) are lookup fields that automatically populate when a primary Affiliation is created for a specific Account Record Type.
To configure which Account Record Types map to which Primary Affiliation fields on the Contact (and thus control what appears in the Primary Affiliations section on the Contact page layout), the consultant navigates to EDA Settings → Affiliations → Affiliation Mappings.
Here, you can:
- View default mappings (e.g., Academic Program Record Type → Primary Academic Program field).
- Create new mappings for custom Account Record Types.
- Select the corresponding Contact Primary Affiliation field.
This declarative configuration determines how primary Affiliations sync to and display on the Contact record.

Why the other options are incorrect:

A. Affiliation TDTM records
TDTM (Table-Driven Trigger Management) records control trigger execution order and enable/disable handlers (e.g., for Affiliation automation). They do not configure field mappings for Primary Affiliations.

B. Field Sets for Affiliations
Field Sets control which fields appear on related lists, page layouts, or components (e.g., fields shown when creating a new Affiliation). They do not manage Primary Affiliation field mappings on Contact.

D. Affiliation Sharing Rules
Sharing Rules control record visibility/access. They have no role in configuring Primary Affiliation fields or mappings.

References:
Trailhead: "Configure EDA Settings" → Navigate to Affiliations section → Affiliation Mappings to customize primary affiliations on Contact.
EDA Documentation: Affiliation Mappings control which Account Record Types populate specific Primary Affiliation fields on Contact.
Education Cloud Consultant Exam Guide: Objectives around EDA configuration include managing Affiliations and Primary Affiliation mappings.

Explanation:

The requirement is to segment alumni by Household and filter for those who work for Fortune 500 companies. This requires joining data about the individual (Contact: alumni), their family unit (Household Account), and their employer (another Account, representing the Fortune 500 company).
Affiliations are the key. In Education Data Architecture (EDA), an Affiliation is the object that formally links a Contact (the alumnus) to an Account (their employer). To filter for alumni who "work for Fortune 500" companies, you must use the Affiliation object to access the employer Account and its fields (e.g., a custom "Fortune 500" checkbox).
Cross-Filter Logic: The correct report type would use Contacts as the primary object and employ a cross-filter like:
"Contacts with Household Accounts" (to segment by household)
AND "Contacts with Affiliations" where Affiliation__r.Account__r.Fortune_500__c = TRUE (to filter by employer)

Why not A. Contact and Account report? This is too vague. A "Contact and Account" report could refer to the Household Account, but it provides no direct path to filter based on the employer Account (the Fortune 500 company). The Affiliation is the necessary junction.

Why not C. Contact and Relationships report? The Relationship object in EDA is designed for bi-directional, informal connections between two Contacts (e.g., "John is a friend of Sarah"). It is not the correct object for representing the formal employment relationship between a Contact (alumnus) and an organization (Account).

Key Concept:

Affiliation Object: A core EDA object that records a Contact's formal association with an Account, such as employment, membership, or enrollment. It is the primary tool for answering "Where does this alum work?" or "Which organization is this donor affiliated with?"

Cross-Filter Reports: These allow you to create segments based on related records. For advancement/development use cases, combining Household and Affiliation data in reports is standard practice for donor segmentation and prospect research.

Reference: Education Data Architecture (EDA) data model documentation, specifically the objects Contact, Account, and Affiliation__c. Trailhead modules on "Reports and Dashboards for Advancement" in the Education Cloud context.

Explanation:

Why this is correct
For K–12, where the school needs to track families/guardians and communicate with parents, the Household Account Model is the best fit because it’s designed to represent a family unit (household) and relate multiple Contacts (students, parents/guardians, siblings) to that household, along with relationship roles. This aligns with the “family-first” structure schools use for outreach and case management.

Why the other options are wrong
A. Standard Account Model
The standard B2B-style model is oriented around organizations and doesn’t naturally represent family groupings and parent/student relationships as cleanly as the household model.

C. Administrative Account Model
Administrative Accounts are typically “one account per contact” in EDA’s default model behavior and are useful for institutions that don’t want households; it’s not ideal when the main requirement is tracking families and communicating with parents as a unit.

Reference
Salesforce Help / EDA: Account Models overview, including Household Account Model use cases for family-style grouping