C100DEV CRUD Operations Practice Question
A banking application must atomically transfer funds between two account documents in the 'accounts' collection. The transfer decreases the balance of the source account and increases the balance of the destination account, and both changes must succeed or neither should be applied. The deployment is a replica set. Which approach guarantees this atomicity?
⚠ Common exam trap
The trap here is assuming that two sequential updates are effectively atomic because each is individually atomic, when atomicity does not extend across separate write operations.
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
✓
Use a session and start a transaction with session.startTransaction(), update both accounts within the session, then commitTransaction().
Multi-document transactions are the correct tool when atomicity must span more than one document. Starting a transaction on a session, performing the debit and credit updates with that session, and committing ensures the operations either all commit or all abort. On a replica set this provides the all-or-nothing behavior the banking scenario demands.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Embed both account balances in a single document and use updateOne with $inc on both fields.
Why it's wrong here
A single-document update is atomic, but the scenario specifies two separate account documents. Embedding balances into one document changes the data model and is not appropriate for independent accounts that can grow unbounded and be accessed separately. It does not satisfy the requirement as stated without a redesign.
- ✓
Use a session and start a transaction with session.startTransaction(), update both accounts within the session, then commitTransaction().
Why this is correct
Multi-document transactions in MongoDB provide atomicity across operations in the same session. By starting a transaction, performing both updates with the session, and committing, either all changes are applied or the transaction aborts and none are. This is the supported mechanism for atomic cross-document updates on a replica set.
- ✗
Perform two sequential updateOne calls, first on the source and then on the destination, and check the result of each.
Why it's wrong here
Two separate update operations are not atomic as a unit. If the first succeeds and the second fails, the balances become inconsistent, with funds debited but never credited. Checking results after the fact cannot undo the applied change, so this approach does not meet the all-or-nothing requirement.
- ✗
Use updateMany with a filter matching both account _id values and apply $inc to the balance field.
Why it's wrong here
updateMany applies the same update document to every matching document, so it cannot debit one account and credit another by different amounts. It also does not provide a way to apply different operations to different documents. The atomicity guarantee of a single update does not translate into the required transfer logic.
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.