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.

• ✗

  Deploy the application in two EU regions with Azure Front Door and Azure SQL Database geo-replication.

  Why it's wrong here

  Azure Front Door is a global-layer load balancer that terminates connections at Microsoft's nearest point of presence, but it does not enforce data residency because it routes requests to any configured origin, including origins outside the EU. While Azure SQL Database geo-replication can maintain readable secondaries for disaster recovery, failover groups and geo-replication can replicate data across regions if configured that way, and the lack of a built-in EU-only data-boundary mechanism makes this option insufficient for strict data residency requirements. Unlike Traffic Manager's simple DNS-based routing, Front Door adds WAF and global Anycast routing, but those benefits do not address the core compliance constraint.

• ✗

  Deploy the application in a single Azure region in Ireland with Azure Site Recovery for DR.

  Why it's wrong here

  Deploying only in a single Azure region in Ireland fails the explicit requirement to maintain disaster recovery across geographically separated regions, as Azure Site Recovery replicates workloads only to a paired secondary region from a source region, and a single-region deployment provides no independent second location. Even if paired-region replication were used, Site Recovery is primarily an asynchronous DR mechanism—it does not minimize latency for active user traffic, and it can replicate data outside the EU depending on the chosen target region. Azure Site Recovery protects virtual machines through continuous replication to a recovery vault in another region, but selecting a single EU region still leaves no active-active presence for performance or resilience.

• ✓

  Deploy the application in two EU regions with Azure Traffic Manager and Azure Cosmos DB multi-region writes.

  Why this is correct

  This option correctly satisfies both the low-latency and EU-data-residency requirements. Azure Traffic Manager performs DNS-based traffic routing to the nearest available regional endpoint, so users are directed to the closest of the two EU-deployed regions, reducing network round-trip time, while Azure Cosmos DB in multi-region write mode allows the application to write and read in either EU region with replication confined to the configured EU geography. Because Cosmos DB multi-region writes provide active-active replication with automatic failover and 99.999% availability, the solution achieves resilience across two EU regions without requiring cross-region data egress. Traffic Manager and Cosmos DB together give both geo-routing and globally distributed data plane behavior, but when all regions are within the EU, data stays inside EU boundaries.

• ✗

  Deploy the application in a single EU region with Azure Site Recovery and Azure Redis Cache.

  Why it's wrong here

  Deploying in a single EU region with Azure Site Recovery and Azure Redis Cache still does not address the requirement to minimize latency for active traffic across multiple regions, because Site Recovery is designed for disaster recovery failover, not for active request routing or load balancing. Redis Cache in a single region only caches data close to that region's compute; users located in other EU countries will still traverse the network to that one region, so latency remains high. Additionally, Site Recovery replication to a recovery region would use a paired region, but because only one region is explicitly deployed, there is no active second region to serve read/write traffic, leaving the architecture vulnerable to regional outage and failing the low-latency goal.

Go deeper

Related to this question