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 horizontal partitioning (sharding)

  Why it's wrong here

  Horizontal partitioning, or sharding, splits a table into smaller pieces across multiple databases or servers based on a shard key. While this distributes load and can improve write scalability, it increases complexity for queries that need to join or aggregate across shards, and those cross-shard operations introduce extra network round-trips that can actually increase latency. For a read-latency focused design, sharding is not a direct factor because, without careful query routing, it can make point lookups slower and force distributed transactions that add overhead.

• ✗

  Use columnstore indexes

  Why it's wrong here

  Columnstore indexes store data in a columnar format that is highly compressed and optimized for scanning large row sets in analytical workloads. They are designed for OLAP queries that aggregate many rows, not for OLTP point lookups or short transactions that retrieve a few rows, so they do not directly reduce latency for transactional workloads. In fact, maintaining a columnstore index can add CPU and I/O overhead during writes and may not be used for the exact seek operations that typically benefit from a rowstore index.

• ✓

  Configure read replicas

  Why this is correct

  Configuring read replicas is a standard Azure pattern for reducing read latency in a read-heavy relational database. A read replica is a read-only secondary copy that can be placed in the same region or closer to users, and by redirecting reporting or read-only queries to the replica, the primary server is relieved of read load. This shortens response time for those queries and isolates write-heavy traffic on the primary, but it is important to remember that replicas are asynchronously updated, so they may lag behind the primary.

• ✓

  Use active geo-replication

  Why this is correct

  Active geo-replication provides readable secondary databases in multiple Azure regions, and those secondaries are continuously updated from the primary through asynchronous replication. It reduces read latency for global users because each secondary can be placed close to its users, allowing geographically distributed clients to read from a local copy instead of crossing region boundaries. Unlike a simple read replica, active geo-replication also supports planned failover, making it a dual-purpose design factor for both global read performance and disaster recovery.

• ✓

  Choose a service tier that provides higher IOPS

  Why this is correct

  The service tier of a relational database in Azure defines the guaranteed IOPS (input/output operations per second) available for storage I/O. When the workload generates more I/O than the tier supports, queries experience queuing and throttling, which directly increases response time. Choosing a service tier with higher IOPS ensures that the storage subsystem can keep up with the peak read and write demand, so for latency-sensitive applications, right-sizing IOPS is a fundamental consideration distinct from replication or indexing strategies.

Go deeper

Related to this question