C100DBA Indexing and Performance Practice Question
A collection 'events' has a compound index { tenantId: 1, createdAt: -1 }. A developer runs db.events.find({ tenantId: "acme", createdAt: { $gte: ISODate("2024-01-01") } }).sort({ createdAt: -1 }).limit(50). The explain output shows the index is used but the query still performs a large in-memory sort. Which action resolves the sort performance issue?
⚠ Common exam trap
The trap here is assuming any sort requires a new index, when a correctly ordered compound index already provides the sort and the real cause is a collation or type mismatch.
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
✓
Ensure the index is { tenantId: 1, createdAt: -1 } and verify the query does not use a collation or type mismatch that prevents index-provided sort.
A compound index can provide both the equality match and the sort when the equality fields form the prefix and the sort field follows. With { tenantId: 1, createdAt: -1 }, the query's equality on tenantId and sort on createdAt should be served without an in-memory sort. A blocking SORT in explain therefore points to a mismatch such as collation, type, or query shape rather than a missing index.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Add a sort key to the index: { tenantId: 1, createdAt: -1, _id: 1 }.
Why it's wrong here
Appending _id does not change how the sort on createdAt is satisfied by the index prefix. The index already provides createdAt ordering within the tenantId equality, so adding _id only lengthens index keys and increases storage and write cost without removing the sort stage reported in explain.
- ✓
Ensure the index is { tenantId: 1, createdAt: -1 } and verify the query does not use a collation or type mismatch that prevents index-provided sort.
Why this is correct
The compound index with equality field tenantId first and sort field createdAt second already satisfies the equality, sort, and range pattern, so the sort should be index-provided. A collation difference, a mismatched field type, or a $or/$in shape can silently force a blocking SORT stage, so confirming these conditions is the correct diagnostic step.
- ✗
Reverse the compound index to { createdAt: -1, tenantId: 1 }.
Why it's wrong here
Putting the range field createdAt first breaks the equality-then-sort prefix rule. Because createdAt is a range predicate, the index cannot use tenantId as a bound after it, so the query would scan more index entries and still require a sort. The correct ordering places the equality field first, which the existing index already does.
- ✗
Create a separate single-field index on createdAt.
Why it's wrong here
A standalone { createdAt: 1 } index cannot serve the equality predicate on tenantId, so MongoDB would either use the compound index and still sort, or pick the single-field index and fetch more documents to filter tenantId. It does not eliminate the blocking sort stage and adds write overhead, making it the wrong remedy for this specific compound-filter-plus-sort scenario.
Visual reference
About these practice questions
This C100DBA question is part of Courseiva's 222-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 C100DBA 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 C100DBA exam.