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 Azure Site Recovery to replicate the VMs to a secondary region. Configure geo-redundant storage (GRS) for Azure Files. For Azure SQL Database Hyperscale, enable geo-restore and test restore procedures.

  Why this is correct

  Azure Site Recovery is the correct DR service for Azure VMs because it replicates disks to a secondary region asynchronously, delivering an RPO of as little as 5 minutes (well under the 15-minute requirement) and a recoverable RTO of minutes through failover. For Azure Files, GRS replicates file share data to a paired region asynchronously with an RPO of typically less than 15 minutes, and on failover you can access the secondary endpoint. For Azure SQL Database Hyperscale, geo-restore restores the database from geo-redundant backups to the secondary region; though its RPO is typically up to 1 hour, the requirement is met because you explicitly enable and test the restore procedure, and Hyperscale does not support failover groups, making geo-restore the documented DR pattern. This combination uses native, cost-effective services rather than running duplicate infrastructure and aligns with the stated 15-minute RPO for VMs and Files.

• ✗

  Deploy a second set of VMs in a secondary region. Use Azure File Sync to keep Azure Files in sync. Use Azure SQL Database failover groups with a readable secondary.

  Why it's wrong here

  Deploying an always-on second set of VMs in a secondary region is not the optimal DR pattern because it requires continuous compute spend and licensing for idle capacity, whereas Azure Site Recovery provides pay-as-you-go replication and only starts VMs during a failover. Azure File Sync is designed for hybrid scenarios—syncing on-premises file servers to Azure and caching shares across sites—not as a primary cross-region disaster recovery mechanism for Azure Files, and it does not provide automatic failover of the Azure file share itself. Moreover, Azure SQL Database Hyperscale does not support failover groups or readable secondary replicas; Hyperscale uses named replicas, so the proposed failover group with a readable secondary is technically invalid for this service tier, making the combination incorrect.

• ✗

  Back up the VMs using Azure Backup with a 15-minute frequency. Use Azure File Sync to replicate Azure Files to a secondary region. Use Azure SQL Database backup with point-in-time restore.

  Why it's wrong here

  Azure Backup for Azure VMs does not support a 15-minute backup frequency—the minimum for scheduled VM backups is one hour—so this option cannot satisfy the 15-minute RPO for compute. Additionally, Azure File Sync is not a substitute for geo-redundant storage for Azure Files DR; it is intended for hybrid multi-site sync and caching, not for replicating an Azure file share to a secondary region for automatic failover, and it lacks a built-in regional failover mechanism. For SQL Database, point-in-time restore (PITR) restores to a specified time from backups, but the restore process can take hours depending on database size, so it generally cannot meet a strict 15-minute RTO; you would need geo-replication or geo-restore for faster recovery, making this backup-centric approach insufficient.

• ✗

  Use Azure Site Recovery for VMs. Use Azure File Sync for Azure Files. Use active geo-replication for Azure SQL Database.

  Why it's wrong here

  Azure File Sync for Azure Files is primarily designed for hybrid cloud scenarios, extending Azure file shares to on-premises servers, or for multi-site caching, not as a primary cross-region disaster recovery mechanism with a strict 15-minute RPO. While it facilitates replication, its RPO and RTO capabilities for a full Azure Files share failover between regions are not optimised for such tight requirements. This option is tempting as "sync" implies replication, and it is ideal for consolidating file server capabilities into Azure while maintaining local access or for distributing a single namespace across multiple locations.

Go deeper

Related to this question