C100DEV Data Modeling Practice Question
A logistics application stores shipment documents. Each shipment references a carrier by carrierId. Carriers are a small, slow-changing set (about 40 documents) that the application joins on nearly every shipment view. Which design decision is most appropriate for the carrier reference?
⚠ Common exam trap
The trap here is assuming that frequent joins always justify embedding, when a small, stable referenced set is exactly the case where a reference plus caching is cheaper and keeps a single source of truth.
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
✓
Keep carrierId as a reference and resolve carrier details with $lookup, optionally caching the small carrier set in the application.
When the referenced set is small and slow-changing, a reference is preferable to embedding because it avoids duplicating data and keeps one authoritative source. The $lookup join is inexpensive for a tiny collection, and the application can cache the whole carrier set, so shipment reads rarely pay join cost. Full denormalization or cross-database joins add complexity without benefit here.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Denormalize all carrier fields into the shipment and treat the shipment copy as authoritative for carrier data.
Why it's wrong here
Making each shipment the authority for carrier data creates many conflicting versions of the same carrier and breaks any centralized carrier management or reporting. It also forces updates across all shipments whenever a carrier changes. The small carrier collection is better kept as the single source of truth behind a reference.
- ✓
Keep carrierId as a reference and resolve carrier details with $lookup, optionally caching the small carrier set in the application.
Why this is correct
Because carriers are few and slow-changing, a reference plus $lookup is cheap, and the application can cache the entire carrier set in memory, avoiding the join on most reads. This preserves a single authoritative carrier record while keeping shipment documents small. It fits the scenario's small, stable, frequently joined data set.
- ✗
Embed the full carrier document in every shipment to eliminate the join entirely.
Why it's wrong here
Embedding the full carrier record duplicates slow-changing data across thousands of shipments. When a carrier's contact details change, every shipment must be updated, which is a wide write amplification for data that did not need to be copied. The small carrier set makes a reference cheap to resolve, so full embedding is unnecessary.
- ✗
Store carrier details in a separate database and use a manual application-side join for every shipment read.
Why it's wrong here
Moving carriers to another database adds network hops and forces the application to implement join logic that MongoDB and its driver ecosystem already handle. It increases latency and failure surface without addressing any constraint in the scenario. A reference within the same database plus $lookup or caching is simpler and sufficient.
About these practice questions
Courseiva writes every C100DEV question from scratch — 259 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 MongoDB exam blueprint
This C100DEV practice question is part of Courseiva's free MongoDB 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 C100DEV exam.