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.

• ✓

  Deploy Azure Cache for Redis Enterprise with active geo-replication.

  Why this is correct

  Azure Cache for Redis Enterprise uses active geo-replication to create a global cache cluster spanning two or more regions, where every participating cache accepts both reads and writes and synchronizes asynchronously with built-in conflict resolution. If a regional data center fails, the remaining cache automatically continues serving traffic without a manual failover step, preserving cache availability and reducing impact to application sessions. This makes it a true active-active cache tier rather than a passive replica, which is why it is correct for a global business continuity design.

• ✓

  Deploy Azure Front Door with origin groups for the AKS clusters.

  Why this is correct

  Azure Front Door with origin groups places each AKS cluster behind a single global HTTP(S) endpoint and uses layer-7 health probes to detect whether a regional ingress or backend is healthy. When a primary AKS cluster degrades or fails, Front Door automatically shifts client traffic to the next healthy origin in the group, usually within seconds and without relying on DNS TTL propagation. Because it understands application-level signals and supports features such as host/path routing and session affinity, it is the appropriate traffic-routing layer for AKS-based global deployments.

• ✗

  Use Azure Traffic Manager to route traffic to the primary region.

  Why it's wrong here

  Azure Traffic Manager routes traffic by publishing DNS responses that resolve to the IP addresses of the primary region’s AKS endpoint; when it detects a failure, it changes DNS responses, but the actual failover time is governed by DNS TTLs and client DNS caching, which can take minutes and is not guaranteed. It also performs endpoint health checks only at the level of a monitored endpoint (typically the domain/IP), not by probing application-specific HTTP behavior or AKS ingress health. This makes it less suitable than Azure Front Door for fast, application-aware failover of Kubernetes workloads.

• ✓

  Configure Azure Cosmos DB with multiple write regions.

  Why this is correct

  Configuring Azure Cosmos DB for multiple write regions creates an active-active database where every regional replica can accept insert, update, and delete operations, and changes propagate to other regions using the chosen consistency and conflict resolution policies. Because the application can continue writing to any remaining region without a database endpoint promotion, it achieves effectively zero data loss and near-zero recovery time at the data tier for committed writes. This directly supports the need for global write availability, though you must configure conflict resolution (like LWW) to reconcile concurrent changes.

• ✗

  Use Azure SQL Database with failover groups for the database tier.

  Why it's wrong here

  Azure SQL Database failover groups use an active-passive model in which only the primary database accepts writes, while the secondary database is a readable but non-writable replica located in another region. In an unplanned outage, the failover group must promote the secondary, and because replication is asynchronous, any transactions committed to the old primary but not yet replicated can be lost, violating strict RPO or zero-data-loss goals. This is why a failover group cannot replace an active-active database like Cosmos DB with multiple write regions in a global multi-region write scenario.

Go deeper

Related to this question