SF-Data-Arch Data Modeling and Database Design Practice Question
A large university is modeling academic records in Salesforce. Each Course can be taught by multiple Instructors, and each Instructor can teach multiple Courses. The university must report on the aggregate number of Courses each Instructor is teaching per semester and enforce that an Instructor cannot be assigned to the same Course twice within the same semester. Which data modeling approach should the architect implement?
⚠ Common exam trap
The trap here is assuming a Lookup-based junction or picklist can enforce uniqueness and support roll-up summaries, when only two Master-Detail relationships on a junction object provide both.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Create a junction object Course_Instructor__c with two Master-Detail relationships (to Course and Instructor) plus a semester field, and configure a unique composite key across Course, Instructor, and Semester.
A junction object with two Master-Detail relationships is the standard Salesforce pattern for many-to-many relationships, and it enables roll-up summary fields on both parents. Adding a semester field and a unique composite key satisfies the duplicate-prevention rule. Reciprocal lookups, asymmetric relationships, and multi-select picklists cannot simultaneously support per-assignment attributes, aggregate reporting, and uniqueness enforcement.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Store Instructor assignments as a multi-select picklist on the Course object and use a formula field to count selections.
Why it's wrong here
Multi-select picklists cannot store per-assignment attributes such as semester, and formula counting is limited and cannot enforce uniqueness. This approach also caps the number of Instructors and prevents reporting on Instructor-level aggregates, so it fails both the reporting and uniqueness requirements.
- ✗
Create a Lookup relationship from Course to Instructor and from Instructor to Course, then build a report to deduplicate overlapping assignments.
Why it's wrong here
Two reciprocal Lookup relationships create two separate one-to-many paths and cannot represent a single assignment record with shared attributes. Reports cannot enforce uniqueness, so an Instructor could still be assigned to the same Course twice within a semester, violating the requirement.
- ✓
Create a junction object Course_Instructor__c with two Master-Detail relationships (to Course and Instructor) plus a semester field, and configure a unique composite key across Course, Instructor, and Semester.
Why this is correct
A junction object with two Master-Detail relationships natively models the many-to-many relationship and allows roll-up summary fields to count Courses per Instructor. Adding a semester field and a unique composite key enforces the business rule preventing duplicate assignments for the same Course, Instructor, and semester combination.
- ✗
Create a single Course_Instructor__c object with a Master-Detail to Course and a Lookup to Instructor, then use a validation rule to count existing records.
Why it's wrong here
A Master-Detail plus a Lookup creates an asymmetric relationship where Instructor does not own the junction record. Roll-up summaries cannot be created on the Instructor side, and a validation rule cannot reliably count existing records to enforce the composite uniqueness requirement.
Quick reference
Asymmetric Encryption Algorithm Comparison
| Algorithm | Key Exchange | Signatures | Equivalent Security Key | Notes |
|---|---|---|---|---|
| RSA-3072 | Yes | Yes | 128-bit | Widely deployed; slow for bulk data |
| ECDSA P-256 | No | Yes | 128-bit | Fast signatures; standard TLS certs |
| ECDH / ECDHE | Yes | No | 128-bit | Perfect forward secrecy in TLS 1.3 |
| DH / DHE | Yes | No | 128-bit (3072-bit key) | Replaced by ECDHE in modern TLS |
| Ed25519 | No | Yes | ~128-bit | SSH keys, modern PKI |
About these practice questions
Courseiva writes every SF-Data-Arch question from scratch — 222 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
Written and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official Salesforce exam blueprint
This SF-Data-Arch practice question is part of Courseiva's free Salesforce certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the SF-Data-Arch exam.