C100DEV Data Modeling Practice Question
A team is modeling orders and customers. Orders are frequently displayed with basic customer details such as name and email, but customer profiles are large and change often. Which approach best balances read performance with avoiding duplication problems?
⚠ Common exam trap
The trap here is choosing between all-or-nothing embedding and referencing, when a partial embed of frequently read fields is often the right middle ground.
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
✓
Embed a small subset of frequently accessed customer fields in the order while keeping the full profile in the customers collection.
A selective embedding of only the fields commonly shown with orders keeps those reads fast and self-contained, while the authoritative, larger profile stays in its own collection to avoid widespread duplication. This balances read locality with manageable update cost. The other choices either over-duplicate volatile data or force a lookup on every read.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Embed the entire customer profile document inside every order.
Why it's wrong here
Embedding the full profile duplicates large, frequently changing data across many orders, so updates must touch many documents and storage grows quickly. The scenario notes profiles are large and change often, which makes full embedding a poor fit. It also does not match the stated need for only basic details at read time.
- ✗
Normalize customers and orders into separate collections with no duplicated fields and use $lookup for every read.
Why it's wrong here
Full normalization with $lookup on every read adds join cost to the most frequent operation and does not exploit MongoDB's document model for read locality. It avoids duplication but at a performance cost the scenario is trying to prevent. The requirement is fast display of basic customer details.
- ✓
Embed a small subset of frequently accessed customer fields in the order while keeping the full profile in the customers collection.
Why this is correct
Embedding a small, stable subset of customer fields makes the common read self-contained and fast, while the full profile remains in one place to avoid duplicating large or volatile data. This balances read performance against duplication and update cost. It directly matches the scenario's emphasis on frequently displayed basic details.
- ✗
Store only a customerId reference in each order and always perform an application-side join.
Why it's wrong here
A bare reference requires an extra lookup for every order display, which adds latency when basic customer details are shown frequently. It avoids duplication but does not meet the read-performance goal. The scenario implies the common read needs some customer fields directly available.
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.