Explanation:

In EDA, a Contact's employer is not stored in a standard Account lookup field. Instead, it is modeled through an Affiliation record (linking the Contact to an Account of record type "Business Organization"). To surface this employer information on the Contact page, the system uses the Primary Business Organization field, which is a lookup to the Affiliation object. The correct action is to ensure the employer's Account is created (or exists) and that an Affiliation is created, then set as primary. This field will then display the employer's name on the Contact record.

Why the Other Options Are Incorrect:
B. Select Administrative as the Default Account Model in EDA Settings:
The Default Account Model determines what type of Account is automatically created when a new Contact is created (e.g., Household, Administrative). Changing this will not solve the mapping of an existing employer to a Contact. The employer relationship is managed via Affiliations, not by changing the default model for new Contacts.

C. Select Organization as the Default Account Model in EDA Settings:
There is no "Organization" Default Account Model in EDA settings. The standard models are Household, Administrative, and Educational Institution. (Note: "Business Organization" is an Account Record Type, not a Default Account Model). This is a distractor.

Reference:
This question tests the core EDA concept of modeling relationships via Affiliations and the specific use of the Primary Business Organization field on the Contact object. In EDA, professional and organizational relationships (like employer, board membership) are managed through the Affiliation object, not through a direct Account lookup. This is a fundamental data modeling principle in EDA, covered in the "Affiliations" section of the EDA documentation.

Explanation:

Admissions Connect (Salesforce's guided application and review solution built on Education Cloud Recruitment and Admissions) manages the receipt, storage, and review of supporting documents (e.g., transcripts, recommendation letters, essays, resumes, test scores) submitted by applicants.

When applicants upload or staff add supporting documents:

- The files are stored as Salesforce Files (ContentVersion/ContentDocument objects).
- These Files are linked to the relevant Application Material record (a custom object in Admissions Connect that tracks required/submitted materials).
- Reviewers see the documents directly in the application review interface via embedded file previews or downloads.

This leverages Salesforce's native file management for security, versioning, sharing, and integration (e.g., with portals, flows, and review processes).

Why the other options are incorrect:

B. Document Type: Document Type is a picklist field on the Application Material object that categorizes the material (e.g., Transcript, Recommendation Letter, Personal Statement). It defines what the document is but does not store the file itself.

C. Action Plan Item: Action Plans (via Action Plan Templates) automate tasks for admissions staff (e.g., "Request Transcript," "Follow Up on Missing Materials"). Action Plan Items are tasks assigned to users, not storage locations for uploaded documents.

References:
Trailhead: "Admissions Connect Basics" and "Manage Application Materials" modules — Explicitly describe supporting documents as uploaded files stored in Salesforce Files and linked to Application Materials.
Salesforce Help: Admissions Connect documentation — Application materials include file uploads saved as ContentDocuments/Files.

Explanation:

The best solution for digitizing volunteer events, managing opportunities, and handling shift sign-ups is to implement a third-party app—specifically, Volunteers for Salesforce (V4S). This free app, available on the Salesforce AppExchange, is purpose-built for managing volunteer programs and offers features such as:

Volunteer job and shift scheduling
Online sign-ups via public-facing pages
Tracking volunteer hours and attendance
Recurring volunteer and job scheduling
Mass assignment and reconciliation of volunteer hours
Dashboards and reports for engagement and impact tracking

❌ Why other options don’t fit:
A. Event Monitoring: Designed for user activity and system auditing—not event or volunteer management
C. Process Builder: Supports automation, but lacks a user interface or end-to-end structure for managing volunteer events

Explanation:

University Advancement staff are required to authenticate to internal systems using two factors:

something they know (username and password), and
something they have (an app on their phone).

This requirement directly describes Multi-Factor Authentication (MFA). MFA is an identity and access management feature that requires users to provide two or more verification factors during login. In Salesforce, MFA commonly combines a username/password with a second factor such as the Salesforce Authenticator app, a third-party authenticator app, a hardware security key, or a verification code. Salesforce explicitly defines MFA as a security control that adds an extra layer of protection beyond a password alone and requires at least two different authentication factors.

From a compliance and security standpoint, Salesforce has made MFA a baseline security requirement for most direct logins. Salesforce documentation states that MFA significantly reduces the risk of account compromise and is required for users who log in directly to Salesforce products. This makes MFA not only the correct functional choice, but also the correct best-practice and standards-aligned recommendation for a university handling sensitive advancement and donor data.

Because the scenario explicitly mentions “logging in with a username and password” and “authenticating via an app on their phone,” MFA is the most precise and correct answer.

Why the other options are not correct

A. Single sign-on (SSO)
SSO allows users to log in once and access multiple systems without re-entering credentials. While SSO can work together with MFA, SSO alone does not inherently require a second authentication factor. You can have SSO without MFA, so it does not meet the stated requirement by itself.

C. Connected apps
Connected Apps are used to authorize applications to access Salesforce via OAuth. They control app-level access and scopes, not end-user authentication flows involving phone-based verification.

D. Social sign-on
Social sign-on allows users to authenticate using third-party identity providers (such as Google or Facebook). It does not guarantee multi-factor authentication and is typically not appropriate for secure internal university systems.

Salesforce References (end)
Salesforce Help – Multi-Factor Authentication Overview
Salesforce Security Guide – MFA Requirement
Trailhead – Secure Your Users with Multi-Factor Authentication

Exam Tip (ED-Con-101)
If a question describes “username and password + phone/app/code/key”, the correct answer is almost always Multi-Factor Authentication (MFA)—even if SSO or identity providers are mentioned elsewhere.

Explanation:

Table-Driven Trigger Management (TDTM) is a core architectural framework in Education Data Architecture (EDA) that manages all Apex triggers on EDA objects. Instead of writing traditional hard-coded triggers, EDA uses a configuration table (Trigger Action records) to define which Apex classes run in response to trigger events (before/after insert/update/delete) on specific objects.

A key benefit of TDTM is that it controls the execution order of trigger logic. Administrators can:
- View all active trigger handlers in one place (Setup → Custom Settings → Trigger Actions)
- Reorder the sequence of classes via the Load Order field
- Enable/disable individual handlers without code changes
- Prevent conflicts or unexpected behavior from multiple triggers/classes firing unpredictably

This makes EDA highly extensible—partners, customers, and AppExchange packages can add their own trigger logic while maintaining predictable, ordered execution.

Why the other options are incorrect:
A. TDTM prevents custom triggers:
Incorrect. TDTM encourages and supports custom trigger logic by allowing new Apex classes to be added as trigger handlers via configuration. It does not prevent custom triggers; it provides a safer, centralized way to manage them.

B. TDTM mitigates data skew:
Incorrect. Data skew (e.g., many child records owned by one parent) is addressed through Salesforce best practices like proper indexing, lookup skew handling, or account sharing. TDTM is unrelated to data skew mitigation.

References:
EDA Documentation: "Table-Driven Trigger Management (TDTM)" → Explicitly states that TDTM "allows you to control the order in which trigger logic executes."
Trailhead: "Extend EDA with Custom Triggers" → Highlights reordering trigger actions via Load Order to ensure correct execution sequence.
Education Cloud Consultant Exam Guide: Objectives around understanding EDA architecture and extensibility frequently test TDTM's role in managing and ordering trigger logic.