C100DEV Drivers, Tools, Transactions, and Search Practice Question
An application using the MongoDB Node.js driver must ensure that a multi-document transaction is retried correctly when it encounters a transient error. Which two practices are required? (Choose two.)
⚠ Common exam trap
The trap here is assuming that raising limits or changing write concern can replace the driver's prescribed retry logic for transaction error labels.
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
✓
On a commit error with the UnknownTransactionCommitResult label, retry the commit operation.
The Node.js driver exposes error labels that tell the application how to recover. A TransientTransactionError requires restarting the entire transaction, while UnknownTransactionCommitResult requires retrying the commit. These two behaviors are the documented retry pattern for multi-document transactions. Other options either misplace read concern, misunderstand the lifetime limit or weaken durability without addressing retries.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Increase the transaction lifetime limit beyond 60 seconds to avoid all retries.
Why it's wrong here
The transaction lifetime limit cannot be increased arbitrarily; it is a server-side cap. Changing it would not eliminate transient errors such as write conflicts or network issues. The scenario requires correct retry handling, not avoidance of retries, so this is not a valid practice.
- ✓
On a commit error with the UnknownTransactionCommitResult label, retry the commit operation.
Why this is correct
UnknownTransactionCommitResult means the commit outcome is unknown, so retrying the commit is safe and necessary. The driver surfaces this label, and the application should retry the commit until it succeeds or a definitive error occurs. This prevents lost writes when the commit response was not received.
- ✗
Set the readConcern to 'snapshot' on every individual operation inside the transaction.
Why it's wrong here
Read concern 'snapshot' is set at the transaction level, not per operation, and it is the default for transactions. Setting it on individual operations is invalid or ignored. It is not a retry mechanism and does not address transient errors or unknown commit results.
- ✗
Disable write concern to make commits faster and reduce retries.
Why it's wrong here
Write concern does not control transient error labels, and disabling durability is unsafe. It could increase the chance of unacknowledged writes and does not provide retry semantics. The driver still needs to inspect error labels and retry the transaction or commit as appropriate.
- ✓
Check the error for the TransientTransactionError label and retry the entire transaction.
Why this is correct
TransientTransactionError indicates the transaction can be retried from the beginning. The driver exposes this as a label on the error, and the application must wrap the whole transaction logic in a retry loop. This is required because partial work is not committed and the transaction must be restarted cleanly.
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.