DP-900 Practice Question: Identify considerations for relational data on Azure

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Implement read replicas for reporting queries

  Why it's wrong here

  Read replicas in Azure SQL Database, such as read scale-out or geo-replicas, serve only read-only workloads by redirecting reporting queries to a secondary copy. They do not reduce lock contention on the primary replica because update transactions still serialize on the same row, page, or table locks there. Replicas also introduce replication lag, so they cannot resolve conflicts between concurrent writers or shorten lock duration in any way.

• ✗

  Use the READ UNCOMMITTED isolation level

  Why it's wrong here

  Using the READ UNCOMMITTED isolation level (or the NOLOCK hint) bypasses shared locks and lets queries read uncommitted data, which avoids blocking but risks dirty reads, non-repeatable reads, and phantom rows. For an inventory system, this can cause applications to report stock levels that are later rolled back, violating accuracy and consistency. It is a tactical workaround, not a recommended solution for reducing update conflicts, because it addresses read-blocking rather than write-write contention.

• ✓

  Add appropriate indexes to reduce lock duration

  Why this is correct

  Adding appropriate indexes, such as covering or composite indexes, lets queries locate and modify only the necessary rows without scanning large tables. This shortens the time that locks are held and reduces the number of locks acquired, lowering the chance of lock escalation and blocking between concurrent inventory updates. Proper index design is a direct, proactive way to reduce lock duration and is the best-practice response to update conflicts and transaction contention.

• ✗

  Scale up to a higher service objective

  Why it's wrong here

  Scaling up to a higher service objective in Azure SQL Database adds more compute, memory, and I/O resources, which may improve throughput when queries are resource-bound. However, it does not change the lock manager behavior, transaction isolation, or the number of rows scanned per statement, so it does not specifically reduce lock duration or update conflicts. If the bottleneck is lock waits rather than CPU or I/O, a larger service objective often has little effect and wastes cost.

Go deeper

Related to this question