DP-900 Describe core data concepts 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.

• ✓

  Atomicity

  Why this is correct

  Atomicity treats a transaction as an indivisible unit of work: every statement inside it must succeed for any of them to be applied. If any step fails, a rollback undoes all prior changes, restoring the pre-transaction state. This all-or-nothing property is enforced by database recovery mechanisms such as write-ahead logging or undo segments, ensuring no partial updates survive. Thus, it directly answers the question about a transaction either completing fully or not at all.

• ✗

  Consistency

  Why it's wrong here

  Consistency focuses on preserving database invariants—such as primary keys, foreign keys, check constraints, and triggers—as a transaction moves the database from one valid state to another. It does not address whether the transaction itself completes in an all-or-nothing fashion; a transaction could violate a constraint and be rejected, or it could be atomic yet still fail consistency if the committed state breaks a rule. In short, consistency is about the correctness of the final state relative to schema rules, not about the atomic completion of a multi-step operation.

• ✗

  Isolation

  Why it's wrong here

  Isolation governs how concurrent transactions interact, preventing them from observing each other's intermediate, uncommitted changes. It is achieved through locking or multiversion concurrency control, but it has no bearing on whether a single transaction's operations are applied as a single unit. A transaction can be perfectly isolated—invisible to others until commit—and still crash mid-way, leaving partial writes that isolation alone would not clean up. Therefore, isolation concerns concurrency visibility, not transaction completeness.

• ✗

  Durability

  Why it's wrong here

  Durability guarantees that once a transaction is committed, its changes remain permanent even in the face of a system crash, power loss, or media failure. This is typically implemented via persistent redo logs that allow recovery to replay committed transactions. However, durability says nothing about how a transaction behaves before commit; it neither prevents nor cleans up partial updates that occur prior to a failure. It is purely about post-commit persistence, so it does not ensure the all-or-nothing completion described in the question.

Go deeper

Related to this question