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.

• ✗

  Store data in Azure Files and use Azure File Sync for replication.

  Why it's wrong here

  Azure Files with Azure File Sync provides multi-site file share synchronization, not VM-level crash-consistent or application-consistent replication. File Sync replicates only file changes in a storage share to Windows Server endpoints; it does not capture the OS, installed applications, registry, or VM state. Therefore, it cannot restore a full VM after a regional disaster, and it provides no RPO/RTO guarantees for compute workloads — failing the 15-minute RPO requirement.

• ✓

  Implement Azure Site Recovery with replication to a secondary region.

  Why this is correct

  Azure Site Recovery (ASR) continuously replicates Azure VMs to a secondary region using the Mobility service, capturing data changes at near-synchronous intervals. ASR supports recovery point objectives (RPO) as low as 15 seconds (and up to 15 minutes depending on workload), with recovery time objectives (RTO) of minutes when using Azure's orchestrated failover and recovery plans. This directly satisfies the stated 15-minute RPO and fast RTO, making it the correct primary disaster recovery solution for critical VMs.

• ✗

  Use Azure Traffic Manager to distribute traffic between regions.

  Why it's wrong here

  Azure Traffic Manager operates at the DNS layer to route incoming traffic across regional endpoints based on routing methods such as priority or performance. It does not replicate data, synchronize VM state, or maintain a standby copy of the workload. If a region fails, Traffic Manager can only redirect new connections to an already-active secondary site; it has no capacity to spin up VMs or restore data, so it cannot meet the RPO/RTO recovery requirements on its own.

• ✗

  Configure Azure Backup for daily backups with geo-redundant storage.

  Why it's wrong here

  Azure Backup with geo-redundant storage (GRS) copies backup data to a paired region, but the backup schedule defines when recovery points are created. The vault-standard backup policy supports a minimum of four backups per day, yielding a theoretical RPO of 6 hours; even custom policies cannot achieve the sub-hourly RPO needed for a 15-minute recovery point. Additionally, file-consistent or app-consistent backups from Azure Backup are point-in-time snapshots, not continuous replication — restoring requires data transfer and VM rebuild, driving RTO beyond minutes.

• ✓

  Enable application-consistent snapshots for the VMs within the replication policy.

  Why this is correct

  Application-consistent snapshots in Azure Site Recovery are taken as part of the replication policy to ensure that the VM's OS, applications, and file systems are in a consistent state when a recovery point is created. These snapshots use VSS (on Windows) to flush in-memory data and transaction logs, preventing corruption when the VM is failed over. However, enabling app-consistent snapshots alone is not the full solution — they are a component of ASR's replication policy, and the overall ASR replication engine (with its continuous data replication) is what ultimately meets the RPO and RTO targets.

Go deeper

Related to this question