AZ-305 Design infrastructure solutions 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.

• ✗

  Upgrade the SQL Database in East US to a higher DTU tier and enable auto-scaling.

  Why it's wrong here

  DTU-based service tiers for Azure SQL Database do not offer auto-scaling; you would need to manually raise the DTU count, which increases cost linearly through a broader single-node resource pool. Even if you scale to a Premium tier, you only add capacity to the primary in East US rather than distributing the read workload across the existing geo-replicated readable secondaries, and you still pay for the replicas separately. This approach is a blunt, expensive vertical scale that fails to reduce latency for users in other regions and does not address the architectural imbalance between heavy global reads and one primary.

• ✓

  Configure read-only routing in the application connection string to use the geo-replicated databases for read queries, and keep writes directed to the primary.

  Why this is correct

  For an Azure SQL Database with active geo-replication, you can set the application connection string to include ApplicationIntent=ReadOnly; the gateway then automatically routes incoming read-only queries to the nearest readable secondary, while the login remains pointed at the primary for any write transactions. This offloads the bulk of the SELECT traffic from the primary DTU pool, effectively increasing total system throughput without changing the database tier and saving the primary for writes. Because the geo-replicas already exist, the only change is a connection string property, making this the lowest-complexity, highest-leverage fix for a global read-heavy workload and the reason it is the correct answer.

• ✗

  Implement a second-level cache using Azure Cache for Redis with a local cache pattern in the web front-end.

  Why it's wrong here

  Implementing Azure Cache for Redis with a local in-memory cache in the web front-ends can reduce repeated SQL reads and lower perceived latency, but it is an application-side mitigation that does not touch the database DTU throughput bottleneck itself. A local cache pattern introduces distributed cache invalidation complexity, requiring TTL tuning and cross-region consistency handling, which can easily serve stale data during flash sales or after product updates. Redis also does nothing to reduce the volume of writes or the load on the primary database connection pool, so it is a valuable optimization but not a solution for the scenario's core database scaling need.

• ✗

  Shard the database by customer region and deploy shards in each region.

  Why it's wrong here

  Sharding the database by customer region and deploying separate shards per region is a substantial data-architecture overhaul that requires rewriting application queries, implementing a shard map, and managing cross-shard joins and transactions. It may even increase the blast radius, because a customer who travels or places orders across regions will force distributed queries that can be slower than the current single database, and you must still handle global writes and consistency. The geo-replication plus read-only routing option provides an immediate, low-risk scale-out of reads without requiring the application to know which region owns which customer, so sharding is disproportionate complexity that is unlikely to solve the immediate DTU bottleneck in a short timeframe.

Go deeper

Related to this question