C100DEV Indexing Practice Question

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 separate index { timestamp: -1 } and keep the existing compound index.

  Why it's wrong here

  A standalone `timestamp` index cannot serve the equality predicate on `status` as the leading field, so the planner must still scan many documents and then filter. Keeping the original compound index alongside it does not change the fact that neither index matches the equality-then-sort pattern, so the inefficiency persists.

• ✓

  Create a new index { status: 1, timestamp: -1 } and drop the existing index.

  Why this is correct

  With equality on `status` and a descending sort on `timestamp`, the index must place the equality field first and the sort field in the matching direction. `{ status: 1, timestamp: -1 }` satisfies both, so the planner can perform an index scan that returns documents already ordered, avoiding a blocking sort and a collection scan.

• ✗

  Create a new index { timestamp: -1, status: 1 } and drop the existing index.

  Why it's wrong here

  This reverses the equality field and the sort field, violating the ESR guidance for this access pattern. Because `status` is an equality predicate, it should lead the index; with `timestamp` first the planner cannot use the index to satisfy both the filter and the descending sort efficiently, so a collection scan or in-memory sort remains likely.

• ✗

  Create a hashed index on `status` combined with `timestamp` to improve selectivity.

  Why it's wrong here

  Hashed indexes support only equality matches and cannot satisfy range or sort operations such as an ordered scan on `timestamp`. A hashed `status` component would force the planner to fetch and sort results in memory, so it cannot replace the compound index that the equality-plus-descending-sort query requires.