C100DEV Drivers, Tools, Transactions, and Search Practice Question
A developer is debugging a multi-document transaction in the MongoDB Node.js driver. The transaction updates a document in the `orders` collection and inserts into `audit`. The commit fails with a `WriteConflict` error that does not carry the `TransientTransactionError` label. What is the most appropriate action?
⚠ Common exam trap
The trap here is assuming every WriteConflict carries the TransientTransactionError label and can be retried without examining the cause.
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
✓
Inspect the error, resolve the conflict by re-reading or reordering operations, and retry the transaction with backoff.
A WriteConflict that lacks the TransientTransactionError label is not automatically retryable by the driver's standard loop. The developer must inspect the error and decide how to resolve the conflict, often by re-reading the latest document version or reordering operations, then retrying with backoff. Blindly retrying the commit or the whole transaction without addressing the cause is unlikely to succeed.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Inspect the error, resolve the conflict by re-reading or reordering operations, and retry the transaction with backoff.
Why this is correct
A WriteConflict without the transient label means the conflict is deterministic at that moment, such as concurrent updates to the same document. The application should examine the error, potentially re-read the conflicting document, adjust logic and retry with backoff. This is the correct approach because it addresses the root cause rather than blindly retrying.
- ✗
Retry the entire transaction from the beginning.
Why it's wrong here
A WriteConflict without the TransientTransactionError label indicates a conflict that is not automatically retryable by the driver. Retrying the whole transaction immediately may hit the same conflict again. The application should instead handle the conflict explicitly, for example by retrying with backoff or re-reading data, rather than assuming transient semantics.
- ✗
Retry only the commit operation with the same transaction number.
Why it's wrong here
Retrying only the commit is appropriate for UnknownTransactionCommitResult, not for a WriteConflict. A WriteConflict means the transaction could not complete its writes, so the transaction state is not simply an unknown commit. Re-committing the same transaction number will not resolve the underlying conflict.
- ✗
Abort the transaction and report a permanent failure to the user.
Why it's wrong here
Aborting and reporting permanent failure is too drastic because WriteConflict can often be resolved by retrying with backoff or re-reading. Treating it as permanent would cause unnecessary failures under concurrent load. The scenario expects a recovery strategy, not immediate surrender.
Visual reference
About these practice questions
One of 259 original C100DEV practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. 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.