C100DEV Drivers, Tools, Transactions, and Search Practice Question
A developer uses the MongoDB Node.js driver to run a multi-document transaction that updates an accounts collection and inserts a ledger entry. The transaction commits successfully, but a second application instance immediately reads the ledger entry through a session that is not causally linked to the transaction session and receives stale data. The developer wants the second instance to observe the transaction's committed writes without changing the transaction itself. Which approach should the developer use?
⚠ Common exam trap
The trap here is assuming that reading from the primary or using snapshot read concern alone guarantees visibility of a prior transaction's writes, when causal consistency actually depends on propagating the prior session's operationTime and clusterTime.
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
✓
After the transaction commits, capture the operationTime and clusterTime from the transaction session and pass them in the readConcern and afterClusterTime of the subsequent read session.
Causal consistency requires the second session's read to wait until the cluster time has passed the transaction's commit. The transaction session exposes operationTime and clusterTime, and the subsequent read must include afterClusterTime in its readConcern to enforce that ordering. This ensures the committed ledger entry is visible without modifying the transaction or relying on read preference.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Start a new session for the read, set readConcern to "snapshot" on the read operation, and run the read without linking it to the transaction session.
Why it's wrong here
A standalone snapshot read concern provides a consistent point-in-time view for that operation, but it does not automatically include the causal context of the earlier transaction session. Without propagating the operationTime and clusterTime from the transaction session, the second instance can still read from a snapshot that predates the committed transaction, so stale data remains possible.
- ✗
Use the same session that ran the transaction for the subsequent read operation on the second application instance.
Why it's wrong here
A session is a server-side logical context tied to a specific client and driver instance; it cannot be shared across application instances or processes. The second instance cannot reuse the first instance's session, so this approach is not technically possible and would not establish the required causal ordering between the transaction and the later read.
- ✓
After the transaction commits, capture the operationTime and clusterTime from the transaction session and pass them in the readConcern and afterClusterTime of the subsequent read session.
Why this is correct
Causal consistency in MongoDB is achieved by propagating the operationTime and clusterTime from a session that performed a causally prior operation. By including afterClusterTime in the read concern of the second session, the read waits until the cluster has advanced past the transaction's commit time, guaranteeing that the ledger entry is visible.
- ✗
Set the read preference of the second instance to "primaryPreferred" and retry the read until the ledger entry appears.
Why it's wrong here
Read preference controls which replica set member receives the read but does not establish a causal relationship with a previous write or transaction. Even reading from the primary can return data from before the transaction if the read session's cluster time has not advanced, and retrying without a causal token is unreliable and inefficient.
About these practice questions
Courseiva writes every C100DEV question from scratch — 259 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or 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.