C100DEV CRUD Operations Practice Question
A reporting service reads from the 'sensor_readings' collection, which contains millions of documents. The service runs a query that filters on 'deviceId' and returns results sorted by 'recordedAt' descending. The query performs a collection scan and an in-memory sort, causing high memory usage. Which index should you create to allow the query to use an index for both filtering and sorting?
⚠ Common exam trap
The trap here is assuming the sort field must always be the first key in a compound index, when an equality filter field should precede the sort key for the index to serve both operations.
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
✓
db.sensor_readings.createIndex({ deviceId: 1, recordedAt: -1 })
The optimal index follows the equality-sort-range rule: equality fields first, then the sort field. Because the query filters on deviceId with equality and sorts on recordedAt descending, a compound index { deviceId: 1, recordedAt: -1 } lets MongoDB use the prefix for filtering and read entries in the requested sort order, avoiding the blocking in-memory sort and its memory overhead.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
db.sensor_readings.createIndex({ recordedAt: -1, deviceId: 1 })
Why it's wrong here
This compound index places the sort field first and the equality filter field second. While it can support sorting on recordedAt alone, the equality predicate on deviceId cannot be efficiently served as a prefix, so the planner will not use it to satisfy both the filter and the sort in one scan. The query would still need to examine extra index entries and may not fully avoid the sort stage.
- ✗
db.sensor_readings.createIndex({ deviceId: 1 })
Why it's wrong here
An index on deviceId alone helps the equality filter, but it does not include recordedAt, so the sort cannot be satisfied by the index. MongoDB would have to perform an in-memory sort of all matching readings, which is exactly the behavior causing the high memory usage and the reason a compound index is required.
- ✓
db.sensor_readings.createIndex({ deviceId: 1, recordedAt: -1 })
Why this is correct
This index matches the query pattern: an equality field (deviceId) followed by the sort field (recordedAt) in the same direction as the sort. MongoDB can use the index prefix for the equality filter and then return entries already ordered by recordedAt descending, eliminating the in-memory sort and reducing memory pressure for the reporting service.
- ✗
db.sensor_readings.createIndex({ recordedAt: 1 })
Why it's wrong here
A single-field index on recordedAt supports sorting in ascending order only; a descending sort can be served by scanning the index in reverse, so sorting is possible, but the deviceId filter is not covered. The planner would still need to fetch and filter many documents, and with millions of readings this remains inefficient and does not address the filtering cost.
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.