AZ-305 Design business continuity 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.

• ✗

  Use Cosmos DB with geo-redundant storage and deploy a single AKS cluster with Azure Site Recovery.

  Why it's wrong here

  This design fails on both fronts. Cosmos DB geo-redundant storage (GRS) provides asynchronous replication at the storage layer, but it does not enable automatic, application-visible failover with multi-region writes—client writes still target a single write region, and a regional outage requires a manual or SDK-driven failover, risking stale reads and write unavailability during the transition. Azure Site Recovery (ASR) is not a supported or recommended pattern for AKS stateful workloads; ASR replicates VMs and disks, not container workloads, and it forces a manual, scripted failover process that is slow (RTO of minutes to hours) and prone to configuration drift, especially for stateless AKS nodes which should instead be redeployed via GitOps. Because the app is globally distributed with an availability SLA, ASR's manual failover and Cosmos DB GRS's lack of automatic write failover do not meet the required RTO/RPO, making this option incorrect.

• ✗

  Deploy AKS clusters in two regions with Azure Traffic Manager and use Cosmos DB single-region writes with async replication.

  Why it's wrong here

  This approach splits the difference but still misses the active-active requirement. AKS clusters in two regions behind Traffic Manager can route traffic, and with single-region writes all writes go to one Cosmos DB region; async replication to the secondary region is non-synchronous, so if the primary write region fails, the data not yet replicated is lost—violating a strict RPO of zero and potentially failing compliance or data-integrity requirements. Traffic Manager is DNS-based and does not provide instant failover; DNS TTL propagation delays and health-probe intervals can add minutes of downtime, and it lacks the session-affinity and path-based routing capabilities of a global Layer 7 service. While the app is technically multi-region, the single-writer combined with async replication and DNS-based traffic steering produces a worse RTO/RPO profile than the correct active-active design, so this is not an acceptable business continuity solution.

• ✓

  Configure Cosmos DB with multi-region writes and deploy AKS clusters in two regions behind Azure Front Door.

  Why this is correct

  This is the correct solution because it delivers a true active-active architecture with zero data loss and minimal downtime. Cosmos DB multi-region writes allows the database to accept writes in both regions, and the service automatically synchronizes all regions with a single write consistency model; during a regional outage, Cosmos DB automatically fails over the affected region without any manual intervention, preserving both availability and RPO. Azure Front Door fronts the two AKS clusters with global load balancing at Layer 7, providing instant failover via health probes, SSL offload, and path-based routing—it can route traffic to the healthy region in seconds, unlike DNS-only solutions. The combination of multi-region writes (no RPO loss) and Front Door (near-zero RTO) satisfies the business continuity requirement for a globally distributed application, making this the only option that meets the stated goals.

• ✗

  Deploy the application to a single region and use Azure Backup for Cosmos DB to restore in another region.

  Why it's wrong here

  This option is fundamentally not a business continuity solution, but a disaster-recovery (backup/restore) mechanism with poor recovery metrics. Deploying in a single region means a regional outage takes the application completely offline; Azure Backup for Cosmos DB restores a backup to another region, but the restore operation is a manual, time-consuming process that typically takes hours (RTO in hours or even days) and the most recent backup is at most a few minutes old, so you will lose any writes after the last backup (RPO of at least several minutes, often more). For a globally distributed application with an availability SLA, an RTO/RPO of hours/minutes is unacceptable, and a single-region deployment violates the core premise of geo-redundancy. Backup is a necessary complements tier, not a substitute for active-active replication, so this option cannot meet the business continuity requirements.

Go deeper

Related to this question