Disaster Recovery practice questions

Use Azure Site Recovery for VMs, geo-replication for Azure SQL Database, and geo-redundant storage (GRS) for Blob Storage.

Why wrong: GRS provides geo-redundant storage but does not offer read access in the secondary region without failover, which could delay recovery. Also, geo-replication for SQL DB is not the standard name; active geo-replication is needed for low RPO.

Use Azure Backup for VMs, geo-redundant storage for SQL Database backups, and geo-redundant storage for Blob Storage.

Why wrong: While Azure Backup ensures crash-consistent or file-consistent snapshots, it is fundamentally a backup service, not a disaster-recovery replication engine: VM restore RTO typically ranges from hours to a day because entire machines must be retrieved from vault storage, and the RPO is bounded by the scheduled backup frequency (often 12–24 hours), not by continuous replication. The same limitation applies to geo-redundant storage for SQL Database backups, which protects backup files but does not maintain a live, readable secondary database; failover would require restoring from the latest backup, incurring data loss and unacceptable recovery time. Additionally, GRS for Blob Storage without read access forces a wait for a full failover before you can access the secondary copy, so it fails the sub-1-hour RTO and minimal RPO requirements. Thus, this option is a backup-centric plan, not a rapid DR solution.

Use Azure Front Door with multi-region deployment of VMs and Azure Cosmos DB for the database.

Why wrong: Azure Front Door is a global layer-7 load balancer that can route traffic to multi-region deployments, but it does not itself replicate or protect the underlying VMs—those VMs would still need a DR mechanism like Site Recovery or an active-active design with replicated compute and storage. More critically, swapping the required Azure SQL Database for Azure Cosmos DB fundamentally changes the application's data platform: Cosmos DB is a NoSQL document database, so existing relational schemas, T-SQL queries, transactions, and stored procedures would require a substantial rewrite and data migration, making it a costly redesign rather than a drop-in DR solution. Furthermore, this option makes no provision for geo-replicated Blob Storage, leaving that component entirely unaddressed. Therefore, even with Front Door and a multi-region footprint, this approach pivots the architecture rather than meeting the existing DR requirements.

Use Azure Site Recovery to replicate the HANA large instance VMs with a replication frequency of 30 seconds and enable auto-failover

Why wrong: Azure Site Recovery can replicate VMs but does not ensure HANA application consistency at the database transaction level. It may cause data loss or corruption because it captures VM-level state, not HANA-consistent checkpoints. RPO near zero cannot be achieved with VM replication.

Schedule HANA database backups every 5 minutes to Azure Blob Storage with geo-redundant storage (GRS), and restore in the secondary region on demand

Why wrong: This approach can only achieve an RPO of 5 minutes at best, because any transactions committed after the last backup are lost. Manual restore from blob storage to a secondary region requires provisioning a new HANA Large Instance, restoring the full backup, replaying log backups, and starting SAP HANA — a process that typically takes hours, far exceeding the 30-minute RTO. Geo-redundant storage protects against regional outages but does not automate failover or guarantee HANA transaction consistency, and backup frequency alone cannot provide near-zero RPO.

Set up HANA System Replication with synchronous mode to the secondary region

Why wrong: Synchronous HANA System Replication forces every commit on the primary to wait for acknowledgment from the secondary before completing. Over a WAN link between Azure regions (e.g., West US to East US) this adds round-trip latency to every database transaction, severely degrading production performance and potentially exceeding SAP latency tolerances. Asynchronous replication decouples commit latency while still providing a very low RPO, so it is the appropriate mode for long-distance DR; synchronous mode is only viable on low-latency, typically in-region links.

Recovery Plans

Why wrong: An Azure Site Recovery Recovery Plan groups multiple VMs into a single failover unit, allowing you to define sequencing, runbooks, and automated action steps for orchestration. However, it is an execution framework for real failover and failback, not a mechanism for isolated validation. Running a recovery plan without a test-failover action would trigger actual failover, potentially disrupting production, so the plan itself cannot provide a non-disruptive drill environment.

Planned failover

Why wrong: Planned failover is a migration operation that flushes all pending replication data to the secondary region and then shuts down the source VMs to ensure zero data loss. It assumes you are intentionally accepting downtime and switching production from primary to DR, which is not a validation exercise. Because it impacts the live application and changes the active region, it cannot serve as an isolated test of your disaster recovery readiness.

Network mapping

Why wrong: Network mapping is a configuration setting in Azure Site Recovery that links a source virtual network to a target subnet in the DR region, determining the IP addressing and connectivity of failed-over VMs. It does not perform any compute or boot activity, nor does it segregate test workloads from production. As a static prerequisite for failover, it lacks the ability to create an isolated testing environment, so it is not a tool for running disaster-recovery drills.

B

Why wrong: Creating a second Recovery Services vault in North Europe and backing up to both vaults substantially increases operational overhead and storage cost because the same SQL Server databases would be protected twice. The SQL IaaS Agent extension registers the VM with a single vault; backing up to a second vault requires a second backup schedule and duplicate metadata, and you still need to enable cross-region restore anyway to meet the DR objective. Azure Backup's built-in CRR already replicates the same vault data to North Europe, so a separate vault adds unnecessary complexity with no additional resilience benefit.

C

Why wrong: Manually copying .bak files (or using SQL Server Managed Backup to a storage account) to a North Europe storage account is a fragile, labor-intensive process that requires custom scripts, scheduling, and monitoring to stay current with the transaction log chain. Unlike Azure Backup, which orchestrates backups, verifies consistency, and manages retention automatically, a manual copy introduces a significant window of data loss between copies, risks corruption or incomplete file sets, and does not provide a native restore experience. This approach is not scalable for production SQL Server workloads and lacks the built-in cross-region restore capabilities that are available with a Recovery Services vault.

D

Why wrong: Azure Site Recovery (ASR) is a disaster-recovery service that replicates entire VMs for failover, not a backup service for SQL Server databases. ASR recovery points are snapshots of the entire VM with limited retention (typically up to 72 hours), and it does not support SQL Server–consistent point-in-time restore or long-term retention of transaction log backups. While ASR could be used alongside Azure Backup, it cannot replace it, and mixing the two does not address the requirement for long-term backup retention with cross-region restore. The correct service for database-level backup, log chains, and retention is Azure Backup, not ASR.

SQL Server log shipping to a VM in the secondary region

Why wrong: SQL Server log shipping is a database-level feature that periodically copies transaction log backups to a secondary VM but requires manual recovery of the database to bring it online, and every drill would break the log chain, forcing a full backup and reseed. It does not replicate the VM's operating system or SQL Server configuration, and the combination of manual steps and log restore is unlikely to guarantee a 1-hour RTO or a clean, non-impactful DR test.

Azure Backup with cross-region restore

Why wrong: Azure Backup with cross-region restore is fundamentally a backup service, not a continuous replication engine; it takes scheduled snapshots and, for cross-region restore, uses geo-redundant storage to restore a VM in the paired region from a recovery point. Creating a restored VM from a backup typically takes hours, far exceeding the required 1-hour RTO, and performing a restoration for a drill would not be a non-disruptive failover but rather a separate, full VM recovery that doesn't test automated failover processes.

Azure SQL Database geo-replication

Why wrong: Azure SQL Database geo-replication is a PaaS feature designed for Azure SQL Database and SQL Managed Instance, providing readable secondaries and auto-failover groups, but the mission-critical workload runs on SQL Server installed on an Azure VM, which is not a supported target for this service. Since geo-replication cannot be applied to an IaaS-hosted SQL Server, this option is inapplicable; adopting it would require migrating the database to Azure SQL Database, which fundamentally changes the architecture rather than protecting the existing VM.

SQL Server Always On Availability Groups

Why wrong: SQL Server Always On Availability Groups require SQL Server Enterprise Edition to support the multiple synchronous and asynchronous secondary replicas needed for a cross-region disaster recovery topology; Standard Edition only offers Basic Availability Groups limited to a single database without the same failover flexibility. While AGs can provide low RPO and automated failover, they do not include a native test-failover function — conducting a drill would require adding a temporary replica or manually flipping the primary, both of which are disruptive and risk unintended data writes. Additionally, deploying AGs across Azure regions demands an internal load balancer, a domain controller, and careful listener configuration, adding significant complexity when compared to the integrated failover orchestration of Azure Site Recovery.

Azure Backup with cross-region restore

Why wrong: Azure Backup with cross-region restore is fundamentally a backup-and-restore solution rather than continuous replication, so its RPO is typically 24 hours (or longer for weekly backups) and its RTO involves restoring managed disks to a new VM, reconnecting virtual networking, and validating SQL log backups — often taking hours to days. It provides no automated failover mechanism and no isolated test-drill workflow; any disaster-recovery exercise requires a full restore into the recovery region, which runs side-by-side with production and is extremely time-consuming. While it can serve as a sensible long-term retention and corruption-protection layer, it cannot meet the low RPO/RTO requirements of a critical SQL Server database, especially when a replication-based service like Azure Site Recovery is available.

Azure SQL Database geo-replication

Why wrong: Azure SQL Database geo-replication is unsuitable because the company runs SQL Server on an Azure virtual machine, whereas this service is exclusively for Azure SQL Database (PaaS) instances. This option is tempting as it provides regional disaster recovery with suitable RPO/RTO and non-disruptive drills. It would be the correct choice if the scenario involved an Azure SQL Database PaaS instance rather than SQL Server deployed on an IaaS virtual machine.

Use Azure File Sync to sync the file share to an on-premises server, and then back up the on-premises server using Azure Backup.

Why wrong: Azure File Sync is a synchronization and cloud tiering service designed to keep an Azure file share and an on-premises Windows server in sync; it is not a backup mechanism. If you back up the on-premises server, you are only backing up a cached replica, not the authoritative cloud share, and any accidental deletions or corruption that syncs from the client to the cloud will also be replicated to the local cache. This approach exposes you to data loss and provides no file-level restore history or cross-region recovery of the Azure file share, so it fails to meet the requirement.

Enable soft delete and versioning on the storage account, and configure replication to a secondary region using RA-GRS.

Why wrong: Enabling soft delete and versioning on the storage account is meaningful for blobs, but Azure file shares do not support blob-style versioning; share snapshots are the closest equivalent, and the option does not mention a backup policy. Soft delete protects against accidental share deletion but is not a scheduled backup service and provides no point-in-time restore to arbitrary times. RA-GRS replication gives you read-only access to a secondary region, but without the Recovery Services vault and cross-region restore, you cannot perform a full restore or granular file recovery from that secondary copy, so this falls short of the required backup and DR capability.

Create a scheduled Azure Automation runbook that takes snapshots of the file share every day and copy them to a storage account in West US.

Why wrong: Building a custom Azure Automation runbook to take daily snapshots and copy them to West US introduces significant operational complexity, including writing custom scripts to manage snapshot creation, retention, and geographic copying. Azure file share snapshots are bound to the storage account and must be manually copied to another region; there is no built-in monitoring, alerting, or restore UI, and the runbook becomes a single point of failure if credentials expire or execution fails. This DIY approach lacks the enterprise qualities of Azure Backup, such as policy-based scheduling, archive tiering, and failover support, so it is not a managed or reliable solution.

Point-in-time restore

Why wrong: Point-in-time restore (PITR) reconstructs a single database to a specific timestamp using automated backups, protecting against logical corruption or accidental data deletion. However, PITR operates only within the same logical server and region; it does not replicate data to another region or provide a readable secondary. In a regional outage, you cannot automatically fail over—you would first need to recover the server or redeploy the restored database, so it fails the DR requirement for a critical database.

Long-term backup retention

Why wrong: Long-term backup retention (LTR) stores full database backups for up to 10 years to satisfy compliance or audit requirements, typically retaining weekly, monthly, or yearly backups. These backups are, at best, stored in geo-redundant storage, but they do not represent a continuously updated secondary replica; restoring from LTR means a backup recovery rather than an automated failover. This approach incurs significant data loss (up to the last retained backup) and recovery time measured in hours, so it cannot meet the RPO/RTO expectations of a critical regional DR solution.

Always On availability groups (self-managed)

Why wrong: Always On availability groups are a built-in SQL Server engine feature that you can configure on SQL Server on Azure VMs or Azure SQL Managed Instance, but they require Windows Server Failover Clustering (WSFC), manual configuration, and ongoing patching and maintenance. Azure SQL Database (single database or elastic pool) exposes only the service endpoint, not the underlying SQL Server instance, so you cannot deploy or manage an availability group directly on this PaaS offering. Since the question specifically references 'Azure SQL Database,' this option is out of scope; failover groups are the PaaS-native mechanism for geo-failover.

SQL Server Always On Availability Group with asynchronous commit.

Why wrong: With asynchronous commit, the primary replica accepts a transaction and acknowledges it without waiting for the secondary replica to harden that log block. Under normal operation the secondary stays near-real-time, but any lag—network latency, heavy log volume, or a regional disruption—creates a window where committed transactions on the primary are absent from the secondary. If a failover is triggered during that window, those transactions are lost, so the recovery point objective (RPO) is non-zero. Because the requirement mandates zero data loss, asynchronous commit fails even though it avoids the performance penalty of synchronous replication.

Azure Site Recovery to another region.

Why wrong: Azure Site Recovery continuously copies Azure VM disks asynchronously, producing recovery points that are typically 5–15 minutes old, and it is not application-aware for SQL Server transactional consistency. Even when application-consistent snapshots are enabled, ASR only guarantees that VSS-backed applications are in a consistent state at the snapshot moment—it does not guarantee that every SQL transaction committed before failure is included in the recovered copy. A database failover via ASR therefore restores to a point in time before the outage, losing any transactions committed after the last captured recovery point. This cannot satisfy an RPO of zero and is better suited for crash-consistent DR where limited data loss is acceptable.

Deploy the VMs in a different availability zone within the same region.

Why wrong: Deploying the SQL Server VMs in separate availability zones places them in different fault domains and power/cooling/network domains within the same Azure region, which protects against a single datacenter failure but not an outage that takes down the entire region. A regional event—such as a natural disaster or a large-scale platform failure affecting all zones—would still make the database unavailable, and the cluster or AG replicas would be in the same regional blast radius. The requirement explicitly says 'across regions,' so zone-level redundancy is technically outside the scope. While zones do help with in-region SLA, they do not provide cross-region disaster recovery or guarantee zero RPO for a regional outage.

Deploy an active-passive configuration with Azure Front Door and Traffic Manager

Why wrong: Azure Front Door and Traffic Manager provide global DNS/HTTP load balancing and health-based traffic steering, but they do not replicate VM disks, memory, or application state. An active-passive configuration only directs user traffic to a pre-provisioned secondary site; unless the VMs themselves are continuously replicated to that site, a failover would present stale or missing data, failing the 15-second RPO and minute-level RTO. Additional replication infrastructure would be required, making this incomplete and insufficient.

Configure the VMs in an availability zone across East US and West US

Why wrong: Availability zones are physically separate datacenters located within the same Azure region, so you cannot span a single availability zone across East US and West US, which are distinct regions. Deploying VMs across availability zones within one region only provides resilience against local datacenter failures, not against a regional catastrophe. This option confuses high availability within a region with disaster recovery across regions.

Use Azure Backup with cross-region restore for the VMs

Why wrong: Azure Backup for VMs relies on scheduled snapshot-based backups, with the default policy capturing a recovery point once per day, yielding an RPO of up to 24 hours—far looser than the required 15 seconds. While cross-region restore can copy backup data to another region, the restore point's age and the time required to materialize a VM from backup mean the RTO is unlikely to be in minutes. Thus it protects against data loss but not the near-zero RPO/RTO required here.

Use Azure Backup for VM replication and perform restore drills.

Why wrong: Azure Backup is a backup service that creates point-in-time recovery points, typically with a maximum frequency of daily (or up to four times a day for newer policies), and it does not offer continuous replication or a configurable snapshot frequency like 15 minutes. Restore drills validate that you can recover data, but they do not test failover orchestration, networking isolation, or runbook behavior—key elements of a disaster-recovery drill. Its purpose is data protection against corruption or deletion, not site-level failover.

Configure a recovery plan with a pre-script to take a snapshot every 15 minutes.

Why wrong: Recovery plans in Azure Site Recovery only orchestrate failover sequences—such as boot order and pre/post-scripts—during an actual failover or test failover, not ongoing replication. Snapshot frequency is a property of the replication policy attached to the protected VM, and you cannot change it via a script. A pre-script running every 15 minutes would need a separate scheduler and cannot influence ASR's own replication snapshots, so this approach does not meet the RPO and misuses recovery plan functionality.

Enable multi-VM consistency group with a 15-minute consistency frequency.

Why wrong: While a multi-VM consistency group can ensure crash-consistent or app-consistent recovery points across several VMs at the same time, it is unnecessary for a single critical VM and does not alter the basic snapshot frequency capability of ASR. Setting a consistency frequency of 15 minutes groups writes for cross-VM consistency, but it does not implement test failover drills—that requires the separate Test Failover action on the recovery plan or protection group. Thus, this option misses the drill requirement and adds complexity not needed for one VM.

Deploy AKS in three regions with Azure Traffic Manager. Use Azure Cosmos DB with multi-region writes. Use Azure Event Hubs with geo-disaster recovery. Use Azure Cache for Redis Enterprise with active geo-replication.

Why wrong: Azure Traffic Manager is a DNS-based traffic router, so regional failover depends on DNS TTL and client re-resolution, typically taking 30 seconds or more — far exceeding the 10-second RTO. Additionally, Azure Event Hubs geo-disaster recovery alone is an active-passive namespace-level failover mechanism, not an active-active pattern; without paired namespaces and client-side routing, it would still incur downtime and potential event loss during a failover. Even though Cosmos DB multi-region writes and Redis Enterprise active geo-replication provide zero-loss data services, the front-end and event ingestion layers fail the strict recovery-time objective.

Deploy AKS in two regions with Azure Front Door. Use Azure Cosmos DB with single write region and auto-failover. Use Azure Service Bus with geo-disaster recovery. Use Azure Cache for Redis Enterprise with active geo-replication.

Why wrong: Cosmos DB with a single write region and auto-failover cannot guarantee RPO=0 during a regional outage because the failover promotes a different region, and any writes that were not yet replicated to the secondary are lost. Azure Service Bus geo-disaster recovery is also active-passive: it requires a manual or scripted namespace failover and does not replicate existing queues/topics or their messages to the secondary unless you set up additional forwarding logic. This combination cannot meet the 10-second RTO or zero-data-loss requirement, and the solution is not truly active-active across regions.

Deploy AKS in two regions with Azure Front Door. Use Azure SQL Database with auto-failover groups. Use Azure Event Hubs with geo-disaster recovery. Use Azure Cache for Redis Enterprise with active geo-replication.

Why wrong: Azure SQL Database auto-failover groups are active-passive, relying on asynchronous geo-replication; a regional failover can lose recently committed transactions, so RPO=0 cannot be guaranteed. Azure Event Hubs geo-disaster recovery is likewise active-passive, requiring manual namespace failover and providing no automatic replay of missed events — this breaks the continuous-availability goal. While Azure Front Door offers fast failover and Redis Enterprise active geo-replication is appropriate, the relational and event services force a failover model rather than a true active-active one, so the architecture cannot meet the required recovery point objective or the 10-second RTO.

Use Azure SQL Database active geo-replication for the database and Azure Backup for VMs.

Why wrong: Active geo-replication is intended for read-scale scenarios: it maintains a readable secondary replica but lacks automatic failover, requiring manual promotion and application-level monitoring to redirect connections. Azure Backup for VMs, meanwhile, takes scheduled snapshots at daily or coarser intervals with a default RPO around 24 hours, not continuous replication. Together they do not provide the low RPO or automated failover needed for disaster recovery.

Use Azure Backup to back up VMs and Azure SQL Database to a secondary region.

Why wrong: Azure Backup copies virtual machines and Azure SQL Database to a Recovery Services vault, which may be geo-redundant, but those are point-in-time backups, not live replicas. The default backup frequency for VMs is 24 hours, and even SQL backups are snapshots rather than continuously applied transaction log replication. That yields an RPO far higher than the required 1-hour objective and requires full restore before the workload is usable, both of which fail the stated DR requirements.

Use Azure Traffic Manager to distribute traffic to VMs in multiple regions and Azure SQL Database failover groups.

Why wrong: Traffic Manager is a DNS-based load balancer that routes traffic only to endpoints that already exist and are healthy; it does not provision, replicate, or cold-start VMs in a secondary region. While SQL Database failover groups handle the database tier, the VM tier has no presence in the secondary region, so redirected traffic would have no compute resource to serve it. The solution therefore addresses availability but not the actual replication of compute, missing the RPO and RTO targets.

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 wrong: 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 wrong: 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 wrong: 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.

Azure Backup for SQL Server

Why wrong: Azure Backup for SQL Server is fundamentally a backup and restore tool, not an always-available disaster recovery solution. It captures full, differential, and transaction-log backups, but failing over requires orchestrating a restore of the recovery chain to a target SQL Server, which can exceed the 2-hour RTO once backup frequency and restore time are considered. It also lacks native test-failover capability, so DR drills would interrupt production or require elaborate manual restores.

SQL Server Log Shipping to an Azure VM

Why wrong: SQL Server log shipping copies transaction log backups from the primary to a secondary SQL Server at a set interval, typically 15 minutes or more, so offline data loss is limited, but RTO is not guaranteed by the feature itself. Failover requires applying any pending log backups, performing manual recovery to bring the database online, and redirecting clients, all of which can easily consume more than 2 hours. Log shipping also has no built-in drill mechanism, so testing failover involves manually taking the secondary through the recovery process, which risks breaking the replication chain.

Geo-replication for Azure SQL Database

Why wrong: Geo-replication for Azure SQL Database is a PaaS feature that automatically maintains readable asynchronous replicas in the same or a paired region and supports auto-failover groups. Because your SQL Server is installed directly on an Azure VM (IaaS), the instance sits in your control and does not appear as a database resource in the Azure SQL service, so geo-replication simply cannot be enabled for it. To protect SQL Server on an Azure VM, you must instead use VM-level or SQL Server-level replication technologies.

Azure Traffic Manager

Why wrong: Azure Traffic Manager is a DNS-based traffic load balancer that routes user requests to healthy endpoints, but it does not replicate virtual machines or their underlying disk data. Even when configured for failover, it requires pre-existing VM replicas in another region to point DNS at; without Site Recovery creating and maintaining those replicas, the VMs would be unavailable. For this scenario, Traffic Manager cannot satisfy the replication requirement.

Azure Front Door

Why wrong: Azure Front Door operates at the application layer (HTTP/HTTPS) providing global routing, TLS termination, CDN caching, and a web application firewall, but it has no mechanism to copy VM disks or guest OS state to a secondary region. It is designed to route traffic to origin backends, and those backends must already be deployed and running. Because it cannot create or maintain standby replica VMs, it fails as a solution for replicating Azure VMs.

Azure Backup

Why wrong: Azure Backup provides point-in-time snapshots of VM disks to restore data after accidental deletion or corruption, but it is batch-oriented with periodic recovery points, typically giving a 24-hour or at best 12-hour RPO. It does not maintain a continuously running replica or enable automatic failover to a different region. While essential for data protection, it cannot provide the low recovery time objective expected of disaster-recovery replication like Site Recovery.

Azure DNS

Why wrong: Azure DNS is a hosting service for DNS domains that provides name resolution via the public DNS hierarchy; it does not inspect HTTP/HTTPS traffic or route requests based on endpoint health, latency, or geographic location. While DNS can be used to point at a static IP, it offers no automatic failover or cross-region load-balancing decisions on its own. Therefore, it cannot serve as a cross-region traffic routing service in the way the question requires.

Azure CDN

Why wrong: Azure CDN is primarily a content delivery network that caches static objects (images, videos, files) at edge locations to reduce latency and origin load. It can accelerate dynamic content but does not provide active-active or active-passive load balancing across regional application backends, nor does it perform health-based failover for application availability. Caching can mask an outage for cached content, but it is not a disaster recovery or cross-region routing service.

Azure Application Gateway

Why wrong: Azure Application Gateway is a regional Layer 7 load balancer that operates inside a single Azure region and a single virtual network. It can route traffic to a backend pool, perform cookie-based session affinity, and do URL path-based routing, but it cannot spread traffic across regions or automatically fail over to a secondary region without additional services. Its regional scope disqualifies it from providing cross-region redundancy by itself.

Deploy the VM in an Availability Set and use premium storage.

Why wrong: An Availability Set protects against intra-region hardware failures by placing VMs in different fault and update domains. It does not replicate any data or VM state to another geographic region, so it cannot provide disaster recovery. Premium storage only improves disk performance and durability within the source region, not cross-region availability.

Configure Azure Backup with daily snapshots stored in a Recovery Services vault.

Why wrong: Azure Backup with daily snapshots produces one recovery point per day, meaning the maximum data loss, or RPO, is up to 24 hours. This far exceeds the 1-hour RPO requirement in the scenario. While backups can be restored to another region, the restore operation requires manually creating a new VM and copying data, which is slow and unlikely to meet a strict RTO.

Use Azure Front Door to distribute traffic between the primary and secondary regions.

Why wrong: Azure Front Door is a global HTTP/HTTPS load balancer and content delivery network that routes traffic based on the health of backend endpoints. It can redirect user requests to a secondary region during an outage, but it has no capability to replicate virtual machine state, disks, or compute resources. Therefore, Front Door cannot by itself restore a failed VM or meet the RPO/RTO; it is only a traffic-level mechanism that complements a true DR solution.

Azure Backup

Why wrong: Azure Backup delivers snapshots and point-in-time recovery of Azure VMs and workloads to a Recovery Services vault, allowing you to restore data from a previous state after corruption or accidental deletion. However, it does not provide continuous asynchronous replication to a secondary region, nor does it orchestrate a DNS cutover or failover of VM compute — meaning there is no automatic failover to a standby location. For that reason, Backup is effectively the 'safety net' for data, not the DR failover mechanism.

Azure Front Door

Why wrong: Azure Front Door is a global reverse proxy that routes HTTP(S) traffic and provides CDN capabilities, web application firewall (WAF) protection, SSL termination, and path-based routing, rather than cheap DNS-based geoproximity routing like Traffic Manager. While Front Door could technically serve as a global load balancer in a DR design, it adds significant complexity and cost, and it is redundant if you've already implemented Traffic Manager for geo-routing of a DR scenario. It is certainly not a requirement or replacement for Site Recovery; it's an optional entry point, and using both for the same DR route is over-engineered.

Azure Backup Server installed on-premises.

Why wrong: Azure Backup Server (MABS) is an on-premises backup product that is used to protect files, folders, virtual machines, SQL Server, and other workloads by copying them to a Recovery Services vault. This is fundamentally different from Azure Site Recovery, which performs continuous block-level replication and provides orchestrated failover and failback capabilities. MABS does not maintain a continuous replica of the VM state, nor does it support the automatic failover required by a disaster recovery plan. Therefore, it is not a required component for ASR replication and installing it on-premises would not enable or enhance the Site Recovery process.

An ExpressRoute connection from on-premises to Azure.

Why wrong: An ExpressRoute connection is not a mandatory component for Azure Site Recovery of Hyper-V VMs because ASR can operate over the public internet using encrypted HTTPS (TLS) communications, or over a site-to-site VPN connection. The replication traffic from the Hyper-V host flows to an Azure storage account, and the Provider communicates with the ASR service endpoints; all of this works with standard internet connectivity as long as the required IP ranges and FQDNs are allowed. ExpressRoute may be used to achieve lower latency, higher bandwidth, and a more predictable private path, but it is purely an optional optimization. Requiring it would incorrectly exclude environments that rely on VPN or internet only, which are fully supported by Azure Site Recovery.