C100DEV MongoDB Overview and Document Model Practice Question
An e-commerce application stores products in a collection. Each product has a variable number of attributes, such as 'size', 'color', or 'material'. Which data modeling approach best leverages MongoDB's flexible schema while maintaining query efficiency?
⚠ Common exam trap
Developers often use a separate collection for every optional attribute, erroneously trying to mimic relational EAV patterns instead of using flexible embedded fields.
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 variable attributes directly within each product document.
Using a polymorphic schema with optional fields directly in the document is the canonical MongoDB approach. This strategy avoids the JOIN operations required by relational databases when attributes are stored in separate tables. By keeping data together, developers achieve high performance for read operations and take full advantage of MongoDB's indexing capabilities on specific document fields, regardless of whether every document contains that field.
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 all attributes into a secondary 'attributes' collection linked by ProductID.
Why it's wrong here
Normalization forces costly application-level joins or multiple database roundtrips to retrieve a complete product view. This approach undermines MongoDB's document-oriented design, which is specifically optimized to avoid complex joins by storing related data in a single, self-contained, and naturally hierarchical document structure.
- ✗
Implement a fixed schema using a single large object containing every possible attribute as a null value.
Why it's wrong here
Storing every possible attribute as a null value increases document size unnecessarily without adding value. MongoDB documents only store data that exists, which is more storage-efficient. A fixed schema approach ignores the primary benefits of MongoDB's flexible schema design and leads to bloated, inefficient storage footprints.
- ✓
Embed variable attributes directly within each product document.
Why this is correct
Embedding directly supports data locality, allowing the entire product state to be fetched in a single read operation. Since MongoDB documents are schemaless, having varying fields across products is natively supported, efficient for indexing, and avoids the performance degradation associated with relational JOINs in highly dynamic datasets.
- ✗
Serialize the entire attribute set into a single base64-encoded string field.
Why it's wrong here
Encoding data into base64 strings makes it impossible for the MongoDB query engine to inspect, index, or filter the individual attributes. This forces the application to retrieve the entire document and decode it manually, negating MongoDB's server-side query processing power and limiting the ability to optimize database reads.
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.