C100DEV Data Modeling Practice Question
A mobile banking app stores each customer's account document with an embedded array of the last 20 transactions for quick display, while the full transaction history lives in a separate transactions collection. Which data modeling consideration most directly justifies this split?
⚠ Common exam trap
The trap here is assuming that embedding data provides cross-collection ACID guarantees or referential integrity, when MongoDB provides neither automatically.
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
✓
The embedded array keeps the frequently accessed working set small while the unbounded history is stored separately.
Keeping a small, bounded embedded array of recent items alongside an unbounded separate collection is a common way to keep the hot working set small and avoid unbounded document growth. The account document stays compact and fast to read, while the full history remains queryable. The other choices describe features MongoDB does not provide through embedding.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
The separate collection enforces referential integrity on the transaction documents.
Why it's wrong here
MongoDB does not enforce referential integrity between collections; a reference is only a stored value, not a foreign key constraint. Nothing in the scenario requires the database to reject orphaned transactions. The real motivation is managing document size and read locality, not enforcing relational-style constraints.
- ✗
Storing history separately allows the account document to exceed 16MB without error.
Why it's wrong here
No document may exceed 16MB regardless of how it is modeled; splitting data across collections does not raise that ceiling for the account document. The benefit is avoiding growth toward the limit, not circumventing it. The statement also misidentifies the purpose of the design.
- ✓
The embedded array keeps the frequently accessed working set small while the unbounded history is stored separately.
Why this is correct
Embedding only the most-recently-used transactions keeps the account document compact, so the working set fits in RAM and the 16MB document limit is not threatened by unbounded growth. The complete history is preserved in a dedicated collection that can be queried when needed. This is the classic rationale for splitting high-frequency small data from large, growing data.
- ✗
Embedding transactions guarantees ACID transactions across the account and history collections.
Why it's wrong here
Embedding data in a single document does not by itself guarantee multi-collection ACID transactions; MongoDB's multi-document transactions are a separate feature. The scenario describes a read-performance and size concern, not a transactional-consistency concern. Claiming embedding provides ACID across collections misstates how MongoDB atomicity works.
About these practice questions
One of 259 original C100DEV practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. 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.