C100DEV MongoDB Overview and Document Model Practice Question
An application needs to store an e-commerce catalog where products have varying attributes such as clothing sizes or electronic specifications. You choose MongoDB for its dynamic schema. Which design approach best leverages the MongoDB document model for this use case?
⚠ Common exam trap
Candidates often assume normalization principles from relational databases still apply, mistakenly creating separate collections for every optional product attribute and performing application-level lookups.
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 the varying attributes directly within each product document using flexible subdocuments or arrays that match the specific item.
Storing variable attributes directly inside the document using flexible subdocuments or arrays allows efficient single-query retrieval of all product details. This harnesses the core advantage of the document model by keeping related data together, avoiding complex multi-table joins and matching the natural data access patterns of modern applications.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Normalize product attributes into multiple separate collections linked by manual application references to enforce rigid schema constraints.
Why it's wrong here
Splitting attributes into separate collections with manual references reintroduces the rigid relational modelling MongoDB was chosen to avoid, requiring application joins per product. That pattern fits highly volatile many-to-many data with independent lifecycles, not a catalogue read as whole documents.
- ✗
Serialize all product attributes into a single large binary blob string stored in a single generic text field inside the main document.
Why it's wrong here
A binary blob hides every attribute from MongoDB's query engine, index building and projection, so size or specification filters cannot be served without application-side parsing. Blobs suit opaque payloads such as images or serialised archives, not catalogues queried by attribute.
- ✓
Embed the varying attributes directly within each product document using flexible subdocuments or arrays that match the specific item.
Why this is correct
Embedding varying attributes directly within each document leverages the dynamic nature of BSON. This structure allows the database to index and query specific attributes efficiently while keeping all relevant product details contained in a single fetch.
- ✗
Enforce a strict static schema across all product documents using server-side validation rules that require every possible attribute key to be present.
Why it's wrong here
Requiring every possible attribute key to be present defeats the purpose of a flexible document model. Sparse attributes would have to be populated with null or empty placeholder values, wasting storage and complicating application logic.
About these practice questions
This C100DEV question is part of Courseiva's 259-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam 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.