Explanation:

In Education Data Architecture (EDA), the requirement is to track specific class meeting details (days, times, and locations) for a particular instance of a course (Biology 101 next semester).
The Course Offering Schedule object is designed exactly for this purpose:
- It is a child of Course Offering (the specific semester/section instance of Biology 101).
- Each Course Offering Schedule record represents one recurring meeting pattern.
- Fields include Day of Week (multi-select picklist: Monday, Tuesday, etc.), Start Time, End Time, Facility (lookup to Account or custom location), and Room.

For this scenario:
Create two Course Offering Schedule records on the Biology 101 Course Offering:
- Tuesdays & Thursdays, 3:00–4:00 PM, Lecture Hall A
- Wednesdays & Fridays, 1:00–2:30 PM, adjacent lab facility

This allows accurate scheduling, conflict checking, faculty workload views, and student-facing display of class times/locations.

Why the other options are incorrect:

B. Time Block
Time Block is a higher-level configuration object used to define institution-wide scheduling patterns (e.g., "Standard 50-minute blocks" or "Evening blocks"). It is not used to schedule individual course sections or meetings.

C. Program Enrollment
Program Enrollment tracks a student's enrollment in an Academic Program (major/minor). It does not store class meeting schedules.

References:
EDA Documentation: "Course Offering Schedule stores the days, times, and location for each meeting of a course offering."
Trailhead: "EDA Course and Enrollment Management" → Explains using multiple Course Offering Schedule records for lecture + lab sections.
Education Cloud Consultant Exam Guide: Objectives around academic structure modeling point to Course Offering Schedule for section-specific meeting details.

Explanation:

Why this is correct
In EDA, Reciprocal Relationships rely on exact “Type” picklist values and other relationship values that must match precisely. EDA guidance for Relationships configuration explicitly says to:
- use API names for these values (case-sensitive), and
- use English names, because EDA supports only the picklist value name and not the label.

That means that even if you translate picklist labels via Translation Workbench, the reciprocal-relationship logic depends on the underlying values (and their precise matching), so you often need to handle translations manually for what users see (for example, via careful configuration/labels/mappings), especially for reciprocal relationship “Type” values.

Why the other options are wrong

A. EDA picklist values are restricted to the organization's default language.
Picklist values aren’t limited to the org’s default language; Salesforce supports translating picklist labels via Translation Workbench. The key nuance for EDA Relationships is not “restricted to default language,” but that the reciprocal logic depends on exact values and EDA notes it supports the value name rather than label.

C. Spanish is a platform-only language in EDA.
Spanish is generally a fully supported Salesforce language (platform-only language issues exist, but Spanish itself isn’t typically treated as platform-only).

Reference
EDA documentation (Relationships configuration): guidance on precise matching, API names, case sensitivity, and using English names because EDA relies on value names rather than translated labels.

Explanation:

Salesforce.org community-built solutions (e.g., open-source packages like Interactions for Recruitment, Data Generation Toolkit, Elevated Giving, and many others from community sprints) are developed, shared, and maintained through the Open Source Commons initiative.
The primary resource for customers to learn more about these community-built solutions—including project overviews, repositories, contribution guidelines, sprint recaps, and installation details—is the Trailblazer Community's Open Source Commons group (specifically the "Open Source Commons & Community Sprints" section or subgroup).
This group hosts announcements, discussions, links to GitHub repositories, sprint project catalogs, and educational content about community-driven Salesforce.org solutions.

Why the other options are incorrect:

B. Product Documentation: Is a Pro Bono Project the Right Fit?
This documentation relates to Salesforce.org's Pro Bono program (volunteer consulting services), not community-built open-source solutions.

C. Trailblazer Community: Cumulus I (CCI)
CumulusCI (CCI) is an open-source DevOps tool for managing Salesforce projects (used heavily in community sprints), but the CumulusCI group focuses on the tool itself, not on discovering or learning about the various community-built solutions.

References:
Salesforce.org Open Source Commons page directs users to the Trailblazer Community Open Source Commons group for project details and community sprints.
Education Cloud Consultant Exam Guide: Objectives around open-source and community contributions consistently point to the Open Source Commons & Community Sprints group in Trailblazer Community.
Common exam scenario: Questions about community-built/open-source Salesforce.org solutions → always recommend the Open Source Commons group.

Explanation:

Why TDTM is the Right Approach:
TDTM allows selective deactivation of triggers during data loads
Prevents:

• Trigger recursion
• Validation rule conflicts
• Unnecessary automation

Maintains data integrity while improving performance

Implementation Steps:
Identify triggers affecting imported objects
Temporarily disable via TDTM custom metadata
Run data import
Re-enable triggers

Why Other Options Are Wrong:
A (Disable sharing rules): Would break security model, not performance-related
B (Change account model): Structural change that would require data restructuring

Best Practices for Large Imports:
Use Bulk API
Schedule during maintenance windows
Run in batches

Explanation:

In EDA, when a new Contact is created using the Default Account Model, the system automatically creates a corresponding Account. The Account Name for these auto-created accounts is determined by a formula field defined in the EDA Settings. To include the contact's first and last name in the Account name at creation, the consultant must edit the relevant Account Name Format setting (specifically for the model in use, e.g., "Administrative Account Name Format" if the default model is Administrative) to incorporate fields like {!Contact.FirstName} {!Contact.LastName}.

Why the Other Options Are Incorrect:

A. Select the Run Backfill button:
The "Run Backfill" utility is used to retroactively create missing Accounts for existing Contacts. It does not configure the naming formula for Accounts created going forward when new Contacts are created.

C. Set the Account Model to Household:
Changing the Default Account Model determines what type of Account is created (Household vs. Administrative), but it does not by itself control the naming format. The name format must still be configured within the settings for the chosen model. Furthermore, the requirement is to configure the existing setup, not necessarily to change the model.

Key Concept:
This tests hands-on knowledge of EDA configuration, specifically the Automatic Account Creation settings. Configuring the Account Name Format formula in EDA Settings is the standard way to define how auto-generated Accounts are named, a key setup task during implementation. This is documented in EDA setup guides under "Configure Account Naming."