C100DEV Indexing Practice Question
A support team frequently runs a query that filters on status and sorts by created_at, both fields in the same collection. An existing index { status: 1 } is in place, but the query still performs an in-memory sort and gets killed once result sets grow past the 100 MB sort limit. Which index should you create to let the server satisfy both the filter and the sort without a blocking sort stage?
⚠ Common exam trap
The trap here is assuming any index containing both fields can satisfy the sort, when field order and sort direction inside the index determine whether a blocking sort is avoided.
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
✓
{ status: 1, created_at: 1 }
An index that lists the equality predicate field first and the sort field second stores entries for each status value in created_at order. The server can then read the matching range sequentially and emit results already sorted, which removes the blocking SORT stage and its 100 MB memory ceiling. Reversing the field order or flipping the sort direction prevents the index from supplying the required order.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
{ created_at: 1, status: 1 }
Why it's wrong here
Placing created_at first makes the index ordered by timestamp before status, so the equality filter on status can still be scanned, but the index cannot provide the requested sort order while also bounding the status range efficiently. The planner would likely fall back to a blocking SORT stage, leaving the 100 MB in-memory sort limit in play.
- ✗
{ status: 1, created_at: -1 }
Why it's wrong here
This index orders created_at descending inside each status group, so it serves only a descending sort. If the application requests ascending order, the planner cannot use the index to avoid a blocking sort, and the query can again exceed the in-memory sort limit as the result set grows.
- ✓
{ status: 1, created_at: 1 }
Why this is correct
With the equality field first and the sort field second, the index entries for a given status value are already ordered by created_at. The query engine can walk that range and return documents in sorted order, eliminating the blocking SORT stage entirely. This is the equality-sort pattern that keeps the query from ever hitting the 100 MB in-memory sort ceiling.
- ✗
{ created_at: 1 }
Why it's wrong here
A single-field index on created_at gives the correct sort order but cannot restrict the scan to documents matching the status filter, so many non-matching entries must be examined and discarded. The planner may still choose a blocking sort when selectivity is poor, so this does not reliably remove the in-memory sort stage.
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.