C100DEV Data Modeling Practice Question
You are modeling an IoT telemetry system in MongoDB. Each sensor device emits a reading every 5 seconds, and the application most often queries the last 24 hours of readings for a single device. You want to minimize the number of index entries and document reads per query. Which schema design should you choose?
⚠ Common exam trap
The trap here is assuming that one document per reading is the most granular and therefore most flexible design, when in fact it multiplies index entries and read operations for the fixed time-window queries this workload actually performs.
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
✓
Store readings in per-device, per-hour bucket documents that hold a readings array, with a compound index on { deviceId: 1, startTime: -1 }.
Bucketing groups many measurements into a single document, so a fixed time-window query for one device scans a small, predictable number of documents and index keys. Grouping by device and hour keeps buckets bounded in size, avoiding the 16MB limit, while the index on deviceId and startTime supports fast range filtering. The other designs either explode the number of documents or introduce unbounded growth and joins.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Store readings in a separate collection and use $lookup to join them to a device document at query time.
Why it's wrong here
A $lookup join adds a blocking stage that must match every reading document against the device document, dramatically increasing work per query and preventing efficient index range scans on the readings collection. It neither reduces index entries nor document reads, and it adds join overhead that the bucketed design avoids entirely.
- ✓
Store readings in per-device, per-hour bucket documents that hold a readings array, with a compound index on { deviceId: 1, startTime: -1 }.
Why this is correct
Bucketing collapses 720 readings per hour into one document, so a 24-hour query touches roughly 24 documents and 24 index keys instead of tens of thousands. This directly reduces both index entries and document reads, and the { deviceId: 1, startTime: -1 } index efficiently bounds the time range for a single device.
- ✗
Store each reading as its own document with a compound index on { deviceId: 1, timestamp: -1 }.
Why it's wrong here
One document per reading produces 17,280 documents per device per day, forcing the query engine to fetch many documents and creating a very large index with one key per reading. This maximizes index entries and read amplification, which is exactly what the scenario asks you to minimize, so it fails the stated requirement.
- ✗
Store all readings for a device in a single document containing a readings array that grows indefinitely.
Why it's wrong here
An unbounded array will eventually push the document past the 16MB BSON limit, at which point writes fail outright. Even before that, every read of the document pulls the entire history into memory, so a 24-hour query is far more expensive than needed. This approach does not reliably minimize document reads or index entries.
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.