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

  In this healthcare scenario, Atomicity guarantees that a multi-step transaction—such as writing a patient diagnosis, associated medications, and lab results together—either commits all changes to the medical history or rolls back completely. If any statement in the transaction fails, the database discards all earlier writes, leaving the patient record untouched. This all-or-nothing behavior directly matches the requirement that incomplete updates never appear, which is why Atomicity is correct. Azure SQL Database uses a transaction log and rollback segments to enforce this property even when the service fails mid-transaction.

• ✗

  Consistency

  Why it's wrong here

  Consistency is an ACID property that ensures a transaction transforms a database from one valid state to another, preserving declared constraints like primary keys, foreign keys, check constraints, and data type rules. It does not, however, force a transaction to be applied as a single indivisible unit; a partially executed transaction could theoretically leave the database in a valid but incomplete state if no constraint happens to be violated. In a patient medical history, Consistency would prevent duplicate patient IDs or invalid codes, but it cannot guarantee that all elements of a multi-record update appear together. That indivisibility requirement belongs to Atomicity, so Consistency is incorrect here.

• ✗

  Durability

  Why it's wrong here

  Durability, once a transaction commits, makes its changes permanent on non-volatile storage so they survive power failures, crashes, or service restarts. In the medical history context, it assures clinicians that a saved diagnosis will still be there after a system failure, but it only applies after the transaction has successfully reached commit. Durability has no mechanism for reversing a partial multi-step transaction; if a failure occurs before commit, it simply preserves whatever was already written. Therefore, while durability supports reliable persistence, it does not enforce the all-or-nothing semantics this question requires.

• ✗

  Isolation

  Why it's wrong here

  Isolation governs how concurrent transactions interact, ensuring that an uncommitted transaction cannot be observed by others and that intermediate states are hidden from concurrent readers and writers. In a healthcare system, isolation prevents one clinician from seeing another's unfinished edits to a patient record, thus avoiding dirty reads and lost updates. But isolation does not decide whether a single transaction's own multiple writes are rolled back as a unit; two concurrent transactions could both be atomic yet still interfere unless isolation levels like READ COMMITTED or SERIALIZABLE are used. The scenario asks about the transaction's own failure behavior, not about concurrency interference, so Isolation is not the correct answer.

Go deeper

Related to this question