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.

• ✓

  Azure Site Recovery for VMs and active geo-replication with auto-failover groups for Azure SQL Database

  Why this is correct

  Azure Site Recovery continuously replicates the source VMs to the secondary region using a recovery point objective (RPO) as low as a few seconds, easily satisfying the 5-minute RPO requirement, and its recovery plans orchestrate compute failover to meet the 1-hour RTO. Active geo-replication for Azure SQL Database maintains a readable secondary replica in the paired region and, when combined with an auto-failover group, automatically redirects connections to the secondary on outage with an RPO of 5 seconds and an RTO typically under 1 hour. Together, these two services provide a cohesive disaster recovery solution for both the IaaS VM tier and the PaaS database tier, with asynchronous replication that meets the stated recovery objectives.

• ✗

  Azure Backup for VMs and Azure SQL Database backup to another region

  Why it's wrong here

  Azure Backup for VMs takes periodic snapshots (typically daily or weekly) that are retained in a Recovery Services vault, so its RPO is measured in hours or days rather than minutes, and restoring from a backup can take from minutes to hours depending on the data volume and restore type. Azure SQL Database backup to another region relies on geo-restore of backups, which can have an RTO of several hours and an RPO of up to 12 hours for the latest backup, far exceeding the 5-minute RPO and 1-hour RTO limits. This option is fundamentally a backup and restore strategy, not a true disaster-recovery replication strategy, and therefore cannot meet the recovery objectives required by the company.

• ✗

  Azure Site Recovery for VMs and Azure DNS for database failover

  Why it's wrong here

  While Azure Site Recovery does handle the VM replication and failover properly, Azure DNS is simply a global DNS service that resolves domain names to IP addresses and manages DNS records; it cannot replicate or fail over the Azure SQL Database. For the database tier, a service like active geo-replication with auto-failover groups is needed to maintain a synchronized secondary copy and automatically redirect traffic on an outage. Omitting database replication leaves the data tier without a viable failover path, so the overall solution fails to meet the RPO/RTO targets even though the VM tier is covered.

• ✗

  Azure Load Balancer for VMs and Azure SQL Database failover groups

  Why it's wrong here

  Azure Load Balancer operates at the network layer and distributes incoming traffic across healthy VMs in a single region; it does not replicate VMs or data to another region, nor does it provide any form of failover for the virtual machines themselves. The use of Azure SQL Database failover groups addresses only the database tier, but the VMs—which run the critical application—remain unprotected because a load balancer cannot create instances or maintain a secondary site. To meet the 5-minute RPO and 1-hour RTO, theVMs must have a replication mechanism like Azure Site Recovery, not just a traffic distribution service, and the database must have active geo-replication configured to support those failover groups.

Go deeper

Related to this question