C100DEV Drivers, Tools, Transactions, and Search 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.

• ✓

  It provides a consistent snapshot of the data at the start of the transaction, ensuring reads see the same version of documents throughout the transaction.

  Why this is correct

  The snapshot read concern ensures that all reads within the transaction see a consistent version of the data as of the transaction start time. This prevents non-repeatable reads and provides isolation. It is the recommended read concern for multi-document transactions to avoid inconsistencies.

• ✗

  It allows reads to see uncommitted changes from other transactions, improving performance.

  Why it's wrong here

  Snapshot read concern does not allow dirty reads. It provides isolation from uncommitted changes. Allowing reads of uncommitted data would violate isolation and is not how snapshot works. The snapshot read concern actually prevents such anomalies.

• ✗

  It ensures that reads are distributed across secondary nodes for load balancing.

  Why it's wrong here

  Snapshot read concern does not control which nodes are read from. In a transaction, reads are typically served from the primary. Read preference can direct reads to secondaries outside transactions, but snapshot read concern is about consistency, not load balancing.

• ✗

  It automatically retries reads if a transient error occurs, without failing the transaction.

  Why it's wrong here

  Snapshot read concern does not include automatic retry logic. Transient errors still cause the transaction to fail and must be handled by the application. The read concern only affects the consistency guarantee, not error handling or retry behavior.