AZ-305 BCDR Decision Guide: Azure Backup, Site Recovery, Zones, or GRS?

For AZ-305 business-continuity questions, start with the recovery objective. Use availability zones when the design must survive a datacenter or zone failure inside one Azure region. Use Azure Site Recovery when VM-hosted or hybrid workloads need orchestrated failover and failback to another zone or region. Use Azure Backup when the requirement is restore, retention, deletion recovery, ransomware recovery, or point-in-time recovery. Use ZRS, GRS, GZRS, RA-GRS, or RA-GZRS for storage-account durability and read/failover behavior, not as a complete application DR plan by themselves.

This is exam-relevant because the current AZ-305 blueprint measures Design business continuity solutions at 15-20%, including recovery solutions that meet recovery objectives, backup and recovery for compute, databases, and unstructured data, plus high availability for compute and data (Microsoft AZ-305 exam page, AZ-305 study guide).

The Decision Shortcut

Pick zones first when the failure is local. Availability zones are physically separate datacenter groups inside a region. Microsoft says zone-redundant services can fail over across zones automatically, but zonal resources need you to deploy across multiple zones and handle failover yourself (availability zones overview).

Pick Site Recovery when the workload must keep running elsewhere. Azure Site Recovery replicates physical or virtual machines from a primary site to a secondary location and supports failover and failback. Microsoft describes continuous replication for Azure VMs and VMware VMs, low replication frequency for Hyper-V, test failovers, recovery plans, and network integration (Site Recovery overview).

Pick Backup when the requirement says restore, retention, deletion, corruption, or ransomware. Azure Backup protects many Azure and hybrid sources and stores recovery points in vaults. Microsoft also notes that backup RPO depends on schedule and that backup restore time must be tested against the workload RTO (Azure Backup overview, business continuity concepts).

Pick storage redundancy when the question is about the storage account's data durability or secondary read/failover behavior. ZRS writes synchronously across zones in the primary region. GRS and GZRS replicate asynchronously to a secondary region; RA-GRS and RA-GZRS add read access to that secondary. Microsoft warns that asynchronous geo-replication can lose recent writes if the primary region cannot recover (Azure Storage redundancy).

RPO/RTO Mapping

Microsoft defines RTO as the maximum acceptable outage duration and RPO as the maximum acceptable data-loss duration. The trap is treating a product capability as the objective. The objective belongs to the workload; the service only helps satisfy it (Well-Architected reliability metrics).

Decision Cards for AZ-305 Scenarios

Azure Backup

Use Azure Backup when the scenario needs protected recovery points, long retention, restore from accidental deletion or corruption, or independent backup copies for Azure and hybrid workloads. It is the right answer when the business asks, "How do we recover last night's good version?" or "How do we retain backups for compliance?"

Boundary: Backup is not instant failover. Microsoft notes that backup recovery can involve data loss because backups are taken at intervals, and the RPO must align with the backup interval. Restore time also needs testing because backup restoration often takes time (business continuity concepts).

Fresh nuance for architects: Microsoft recommends ZRS as the minimum redundancy tier for production backup vault data and recommends GRS plus Cross Region Restore for supported data sources when you need paired-region restore. For Backup, GRS replication can take up to 12 hours after the primary backup completes, and a region outage can imply up to 36 hours of backup-data loss when you account for backup RPO plus replication delay (reliability in Azure Backup).

Azure Site Recovery

Use Azure Site Recovery when the scenario says "keep the application running during an outage" for Azure VMs, VMware, Hyper-V, physical servers, or other supported machine-based workloads. ASR is about replication, orchestration, failover, failback, dependency sequencing, and DR drills.

Boundary: ASR is not a backup-retention service. It does not replace backups for corruption recovery, long retention, or point-in-time restore. It also does not remove capacity planning; Microsoft recommends on-demand capacity reservations so target-region compute is available during failover (reliability in Azure Site Recovery).

Exam clue: if the question gives a low RTO, VM-hosted workload, recovery plan, test failover, or failback requirement, ASR is usually in play. If it asks for seven-year retention or restore after accidental deletion, Backup is the cleaner fit.

Availability Zones

Use availability zones for high availability inside one Azure region. Zone-redundant resources are spread across zones by the service, and Microsoft manages zone failover for those resources. Zonal resources are pinned to one zone; to make them zone-resilient, you must deploy separate resources in multiple zones and handle failover (availability zones overview).

Boundary: zones are not a regional DR strategy. A multi-zone app can survive a zone outage, but it does not automatically survive loss of the entire region. For mission-critical workloads, Microsoft says to consider a solution that is both multi-region and multi-zone.

Paired Regions

Use paired regions as a design input, not a magic switch. Some Azure services use region pairs for geo-replication and geo-redundancy. For example, GRS can replicate Azure Storage to a paired region. Microsoft also says many services support geo-redundancy without relying on region pairs, and deploying to a paired region does not automatically provide high availability, disaster recovery, or failover (region pairs and nonpaired regions).

Boundary: do not rely on Microsoft-managed failover as your normal DR plan. Microsoft warns that managed failover for GRS storage is catastrophic-situation behavior, not an application-level runbook.

ZRS, GRS, and GZRS Storage

Use ZRS when storage needs in-region high availability and the region supports zones. Microsoft recommends ZRS for scenarios that require high availability in the primary region; writes are acknowledged after data is written across three availability zones (Azure Storage redundancy).

Use GRS when lower-cost geo durability is needed and LRS in the primary region is acceptable before asynchronous replication to the secondary. Use GZRS when you need both ZRS in the primary region and geo-replication to a secondary region. Use RA-GRS or RA-GZRS when the application can read from the secondary endpoint during a primary-region outage.

Boundary: geo-redundant storage is asynchronous. The secondary can lag, unplanned failover can lose recent writes, and after an unplanned account failover the new primary becomes LRS until geo-redundancy is re-enabled. Microsoft says customer-managed failover is for tested DR plans and warns not to rely on Microsoft-managed failover except in extreme circumstances (storage disaster recovery guidance).

Worked AZ-305 Scenario

A retailer runs a legacy order API on Azure VMs, stores images in Blob Storage, uses Azure SQL Database for orders, and requires:

• customer checkout available after a regional outage
• no more than 15 minutes of order-data loss
• image reads available during a primary-region outage
• 30-day restore for accidental deletion
• quarterly DR testing

A strong answer is layered. Use availability zones for the VM tier in the primary region if the app can run across zones. Use Site Recovery for VM failover to the target region, with a tested recovery plan and capacity planning. For Blob Storage, use RA-GZRS if the primary region supports it and the app can read from the secondary during outage. For deletion recovery and retention, use backups or service-native point-in-time/soft-delete capabilities where the source service supports them. For Azure SQL Database, do not pretend VM-oriented ASR is the database DR answer; choose the SQL-native continuity option that meets the RPO/RTO, then prove it in the runbook (Azure SQL Database disaster recovery guidance).

The important exam move is explaining boundaries: zones reduce local failure impact, ASR moves VM workloads, RA-GZRS helps blob read continuity and durability, and backup handles restore/retention. None of those alone proves a 15-minute order-data RPO until the database layer has a matching design.

If the question is really asking which data platform to use before you design its continuity layer, review the AZ-305 Data Storage Decision Guide. If the missing piece is how users reach the recovered deployment, review the AZ-305 Load Balancing Decision Guide.

How to Remediate Missed Questions

When you miss an AZ-305 BCDR item, diagnose the missed boundary:

• If you chose Backup for a fast failover scenario, practice separating restore from continuity.
• If you chose ASR for retention or corruption recovery, practice backup-versus-replication questions.
• If you treated paired regions as automatic DR, review which service actually performs replication and failover.
• If you chose GRS without noticing read requirements, compare GRS with RA-GRS and GZRS with RA-GZRS.
• If you ignored RPO/RTO, rewrite the question as "data loss allowed" and "downtime allowed" before selecting a product.

CramHQ can turn those misses into targeted readiness work instead of a generic reread. When you are ready, take the AZ-305 assessment and review the BCDR explanations for the exact decision boundary you missed.

Bottom Line

For AZ-305, the best BCDR answer is usually the smallest layered design that satisfies the stated recovery objective. Backup restores. Site Recovery fails over machine-based workloads. Zones keep regional components available through zone failure. Region pairs inform geo-replication but do not create automatic DR. ZRS, GRS, GZRS, and read-access variants protect storage data in different scopes, but the workload RTO/RPO is only credible after you test the full recovery path.