C100DEV MongoDB Overview and Document Model 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.

• ✗

  { timestamp: 1, sensorId: 1 }

  Why it's wrong here

  This index orders primarily by timestamp, which means queries filtering on a specific sensorId would need to scan many index entries across all timestamps. For retrieving the latest reading for a given sensor, the query would have to examine all timestamps for that sensor, making it inefficient. The sensorId should come first to allow direct lookup.

• ✗

  { value: 1, sensorId: 1 }

  Why it's wrong here

  Indexing on value first does not help with queries that filter by sensorId and sort by timestamp. The query pattern requires efficient retrieval by sensor and time, not by value. This index would only be useful for queries that filter or sort on value, which is not the primary access pattern described.

• ✗

  { sensorId: 1, value: 1 }

  Why it's wrong here

  While sensorId first is good, the second key is value, not timestamp. The query needs to sort by timestamp to get the latest reading. This index would not provide the correct sort order, forcing an in-memory sort after fetching all readings for the sensor, which is inefficient for large datasets.

• ✓

  { sensorId: 1, timestamp: -1 }

  Why this is correct

  Placing sensorId first allows the index to quickly locate all readings for a specific sensor. The descending timestamp then orders those readings from newest to oldest, so the first entry for that sensor is the latest reading. This supports an efficient query using `find({ sensorId: X }).sort({ timestamp: -1 }).limit(1)` with a covered index scan.