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 is the property that guarantees a transaction is treated as a single, indivisible unit: either every operation within it is committed, or none is. If any statement fails, the entire transaction is rolled back, so partial updates are never written to the database (e.g., a funds transfer won't debit one account without crediting another). This all-or-nothing behavior is exactly what the colleague is describing. Atomicity is typically implemented via write-ahead logging or undo/redo logs so recovery can roll back uncommitted changes.

• ✗

  Consistency

  Why it's wrong here

  Consistency ensures that a transaction transforms the database from one valid state to another, preserving all defined rules, constraints, triggers, and cascades. However, it says nothing about the indivisibility of the transaction's operations; even a consistent transaction could be interrupted mid-way and leave a state that still violates nothing if constraints are deferred, but more fundamentally consistency does not address rollback. The all-or-nothing guarantee is a separate concern, belonging to atomicity. In other words, consistency is about the outcome's correctness relative to rules, not about the way partial execution is handled.

• ✗

  Isolation

  Why it's wrong here

  Isolation governs how concurrent transactions are executed relative to each other, ensuring that uncommitted changes from one transaction are not visible to others (depending on isolation level). It deals with locking, versioning, and serializable schedules, not with the single-transaction guarantee of all-or-nothing. Even with perfect isolation, a transaction could fail partway and leave partial changes if atomicity were absent; isolation only prevents interference, not rollback. Thus it is not the term describing the required behavior.

• ✗

  Durability

  Why it's wrong here

  Durability guarantees that once a transaction is committed, its changes persist permanently, surviving crashes, power losses, and system restarts. It is implemented via flushing the transaction log to stable storage before acknowledging commit. Durability does not concern the execution phase; it only matters after a successful commit. The all-or-nothing behavior during the transaction itself is atomicity, so durability is the wrong choice here.