Design business continuity solutions practice questions

Deploy multiple App Service instances in the same region with Traffic Manager

Why wrong: Placing multiple App Service instances behind Traffic Manager in a single Azure region does not create cross-region redundancy. Traffic Manager is a DNS-based load balancer; if that entire region experiences an outage, all endpoints in that profile become unavailable and Traffic Manager has no healthy regional endpoint to route users to. The solution requires endpoints spread across at least two Azure regions, ideally with Azure Front Door, to provide true regional failover.

Use App Service auto-scaling rules to handle increased load

Why wrong: App Service autoscaling rules scale the number of instances within an existing App Service plan in a single region, based on metrics such as CPU or request count. While this handles cyclical or unexpected load spikes, it cannot move workloads to another region or react to a datacenter-level failure. Therefore autoscaling is a capacity-management tool, not a disaster-recovery mechanism, and it does not address the stated requirement.

Enable Azure Site Recovery for the App Service

Why wrong: Azure Site Recovery is an IaaS-focused disaster recovery service that replicates Azure VMs (and on-premises VMs) to a secondary site; it does not support Azure App Service as a protectable workload. App Service is a PaaS service, so you cannot replicate an app service plan or slot with ASR, and attempting to use it would leave the web application without a recovery path. Multi-region deployment with a global front end is the appropriate PaaS-native DR approach.

Azure Backup

Why wrong: Azure Backup captures point-in-time recovery points of on-premises data and workloads to a Recovery Services vault, but it is a backup (data protection) service, not a disaster recovery service. Restores are manual and require recreating or re-provisioning the entire workload, with no health monitoring, no orchestrated failover, and no automatic replication of the underlying OS or apps. For a critical on-premises workload that must fail over quickly and automatically to Azure, Azure Backup alone cannot satisfy RTO/RPO because it does not provide continuous replication or compute failover.

Azure Migrate

Why wrong: Azure Migrate is a centralized discovery, assessment, and migration hub used to evaluate and move on-premises workloads to Azure. Although it includes replication for one-time migration cutover, that replication is not continuous and is not designed for ongoing disaster recovery protection. After migration is complete, Azure Migrate does not monitor or automatically fail over the workload; it simply assists with the actual move, so it cannot provide the required DR failover capability for critical workloads.

Azure Disaster Recovery

Why wrong: There is no Azure service named "Azure Disaster Recovery" in the Microsoft cloud lineup; the official service for disaster recovery is Azure Site Recovery. Using a non-existent service name indicates a fundamental misunderstanding of the Azure portfolio, and any explanation of "Azure Disaster Recovery" would incorrectly imply a separate product. The correct answer must be Azure Site Recovery, which is the actual implementation of DR-as-a-service within Azure.

B

Why wrong: Azure Disk Encryption (ADE) protects the source VM's OS and data disks at rest using BitLocker for Windows and DM-Crypt for Linux, but it does not propagate that encryption to the backup snapshots received by the Recovery Services vault. The vault stores backup data in a separate service-side encrypted storage layer governed by the vault's own encryption settings—either platform-managed keys or a customer-managed key configured on the vault. Merely enabling ADE on VMs will not make backup data encrypted with your own key, so this approach fails the stated compliance requirement. The correct step is to provision the vault with CMK encryption, not to rely on disk-level encryption alone.

C

Why wrong: Azure Site Recovery (ASR) is a disaster recovery solution that performs continuous replication of VMs to a secondary Azure region for the purpose of failover, not for archival backup retention. Its recovery points are controlled by the replication policy and are intended for short-term recovery windows—usually in the order of hours to a few days—rather than a 5-year compliance archive. ASR also does not offer configurable monthly/quarterly/yearly retention points like a Recovery Services backup policy would. Therefore, using ASR instead of Azure Backup would not meet the long-term retention or compliance requirements, making this option incorrect.

D

Why wrong: While it is true that Azure Backup encrypts backup data in the Recovery Services vault with platform-managed keys by default, this does not mean customer-managed keys are unsupported. You can enable 'Encryption using customer-managed keys' on a Recovery Services vault and supply an RSA key from Azure Key Vault for the backup data encryption. This is a supported configuration, but you must plan carefully because CMK must be specified at vault creation time (or via a migration path for existing vaults) and the key vault must enable purge protection. Hence, the claim that only platform-managed keys are available is factually incorrect.

Azure Backup

Why wrong: Azure Backup uses scheduled point-in-time snapshots combined with retention policies, but it does not perform continuous, block-level replication like Azure Site Recovery. While you can restore a backup to a different region, that restore is a manual, time-consuming process and requires you to recreate or reconfigure the VM, meaning you cannot achieve quick failover or non-disruptive validation. Azure Backup is designed for data retention and recovery from corruption or accidental deletion, not for meeting strict recovery time objectives (RTOs) in a regional disaster.

Azure Traffic Manager

Why wrong: Azure Traffic Manager operates at the DNS level and routes user traffic to healthy endpoints, but it never replicates VM data or state. For Traffic Manager to fail over to a secondary region, that secondary region must already have a running, up-to-date VM environment; it cannot spin up new VMs or synchronize application data after an outage. Thus, it is a traffic-routing mechanism, not a disaster recovery replication or failover service, and it has no concept of test failover or continuous copying of virtual machines.

Azure Blueprints

Why wrong: Azure Blueprints is a governance and compliance service that lets you define repeatable Azure environments using ARM templates, policies, and role assignments. It does not involve any runtime replication, monitoring of VM health, or failover behavior; it only helps you deploy and organize resources consistently. Therefore, Blueprints cannot replicate an existing application to another region, nor can it provide any form of automated recovery in the event of a regional outage, making it entirely unrelated to disaster recovery.

Network mapping and IP customization

Why wrong: Network mapping and IP customization configure the target network topology and address translation for replicated VMs—network mapping binds the source VNet/subnet to a target VNet/subnet, while IP customization assigns static addresses to failover replicas so they can communicate on the destination network. These settings are necessary for reachability and DNS after a failover, but they are static configuration values: they neither dictate the order in which application services start across tiers nor provide a built-in method to run a safe drill against an isolated environment. Without a Recovery Plan, failover remains an ad hoc collection of individual VMs coming online with no dependency awareness.

Replication policy with crash-consistent snapshots

Why wrong: Replication policy settings define the recovery point objective (RPO) and consistency guarantee for each replicated VM; crash-consistent snapshots capture the disk state at the instant of a crash, equivalent to pulling the power plug, so no in-memory data or pending I/O is included. This policy ensures the VM can be rebooted with a bootable disk, but it says nothing about application-level consistency—and more importantly, it applies per VM, so cross-tier startup ordering is entirely unaddressed. It also offers no mechanism to execute an isolated test failover; the policy only controls how replication copies data, not how recovered workloads are orchestrated or validated.

Azure Automation runbooks and Azure Monitor alerts

Why wrong: While Azure Automation runbooks are commonly embedded as pre/post actions inside a Recovery Plan, runbooks by themselves are just executable scripts—they lack the sequencing engine that knows which VM/tier must start first, and they cannot conduct a failover drill because they are not tied to Site Recovery's Test Failover lifecycle. Azure Monitor alerts are useful for detecting workload degradation or triggering an incident response, but monitoring is unrelated to the core requirement of deterministic startup order and safe testing. Selecting only these components omits the Recovery Plan container and Test Failover action, so you get automation and notification tooling without the disaster-recovery orchestration that the scenario explicitly requires.

Configure Azure SQL Managed Instance with an auto-failover group to a secondary instance in North Europe.

Why wrong: Auto-failover groups for Azure SQL Managed Instance are the PaaS-native DR solution: they pair a primary instance in the UK South region with a secondary in North Europe, replicating synchronously so RPO is zero. When an outage occurs, failover is automatic and the secondary becomes the primary, keeping RTO low (usually around 1 hour). The secondary can also be used for read-only workloads, making the option both robust and cost-effective for a critical application.

Enable read-access geo-redundant storage (RA-GRS) on the storage account hosting the database files.

Why wrong: Read-access geo-redundant storage (RA-GRS) applies to Azure Blob Storage accounts, not to SQL Managed Instance database files, which are fully managed by the Azure SQL platform and not exposed as user-accessible blobs. Even if the underlying storage were geo-replicated, RA-GRS provides no database-level synchronization, failover, or connection routing for SQL workloads. It therefore cannot satisfy the requirement for automatic failover to a secondary region and would not be a valid DR solution for a SQL Managed Instance.

Use Azure Site Recovery to replicate the SQL Managed Instance to a secondary region as a virtual machine.

Why wrong: Azure Site Recovery (ASR) is designed to replicate and fail over infrastructure workloads, specifically virtual machines, between Azure regions or from on-premises to Azure. SQL Managed Instance is a PaaS database service, so ASR cannot replicate its database files or provide automatic failover for the SQL workload. To use ASR, you would first need to migrate SQL Server to a VM-based deployment—changing the architecture—and even then ASR would only handle VM replication, not transaction-consistent SQL database failover, making it an inappropriate and overly complex solution here.

Use a Recovery Services vault with Locally Redundant Storage (LRS) and enable cross-region restore

Why wrong: Locally redundant storage (LRS) keeps three synchronous copies of data within a single Azure region, but it never replicates to any secondary region. Azure Backup's cross-region restore feature specifically relies on the vault having a geo-redundant copy so that recovery can be performed from the paired region. Therefore, an LRS-based vault cannot support cross-region restore, even if the option is selected, because the secondary region simply contains no data source.

Use Azure Site Recovery to replicate the entire VM to the secondary region

Why wrong: Azure Site Recovery (ASR) is a disaster-recovery solution designed for continuous replication and rapid failover of running workloads, not for scheduled, point-in-time backups with long-term retention. ASR does not produce the same compliance-friendly backup artifacts as Azure Backup, and it lacks the retention policies and restore points needed to meet the stated backup requirement. While ASR can get workloads running in a secondary region, it does not deliver the backup and compliance functionality the company is specifically required to have.

Manually copy backup snapshots to a storage account in the secondary region

Why wrong: Manually copying backup snapshots to a secondary storage account is an unsupported, script-based process that bypasses Azure Backup's lifecycle, so the secondary copy has no native restore item, backup policy, retention schedule, or audit integration. The copied data can become stale, incomplete, or corrupted with no metadata to identify valid recovery points, and the process carries significant operational overhead and error risk. This approach fails both the automation requirement and the compliance requirement, and it does not leverage the built-in, managed replication provided by GRS.

Azure SQL Database with geo-restore

Why wrong: Geo-restore creates a new database from a geo-redundant backup stored in Azure's paired region, but because backup copies are taken asynchronously, the recovery point is often several hours behind the live database, and the restore operation can take many hours to complete. This approach is intended for disaster recovery where losing up to an hour of data is acceptable, not for automatic failover with near-zero downtime. The RTO is unpredictable, making it unsuitable for a critical application requiring rapid, controlled recovery.

Azure SQL Database with a standby replica

Why wrong: Azure SQL Database does not offer a 'standby replica' feature; the platform's HA options are zone-redundant configurations (for local resilience) and active geo-replication (for cross-region DR). A standby replica implies a passive server that is not actively serving traffic, whereas Azure SQL's secondaries in geo-replication are always online, continuously applying transactions, and can be used for read-only workloads. Therefore, selecting 'standby replica' is not a valid Azure SQL Database capability.

Azure SQL Database with cross-region failover

Why wrong: 'Cross-region failover' is not a standalone Azure SQL Database feature; it is the operational outcome of using active geo-replication and a failover group that defines the primary and secondary regions and the automatic failover policy. Without a failover group, geo-replication only supports an explicit, manual failover, which does not meet the requirement for automatic failover during an unplanned outage. Thus, this option fails because it lacks the necessary mechanism to automate the failover process.

Use Azure Backup for the VMs and restore them in order after failover

Why wrong: Azure Backup creates scheduled, point-in-time snapshots (typically once or twice a day with a 24-hour RPO) and does not provide continuous replication or an orchestrated failover workflow. Restoring VMs manually after a region outage not only breaks application startup dependencies but also exposes the recovery to stale data; a full DR drill would require restoring into a separate environment and is inherently disruptive to production if done in place.

Use an availability set to control startup order and use disaster recovery drills in a separate VNet

Why wrong: An availability set controls placement of VM instances across fault domains and update domains within a single Azure datacenter to protect against rack failures and maintenance, not to order startup sequences. It has no role in cross-region replication or failover orchestration, and a DR drill in a separate VNet would still require creating and manually starting new VMs because availability sets do not contain any mechanism for copying data or executing application boot order.

Use Azure Traffic Manager to route traffic after failover and manually start VMs in order

Why wrong: Azure Traffic Manager is a DNS-based global load balancer that forwards clients to healthy endpoints based on routing methods (priority, weighted, performance), but it does not start, stop, or sequence VMs and it cannot invoke scripts to boot tiers in order. Manually starting VMs after failover introduces human error and misses the automation requirement; Traffic Manager alone cannot guarantee a coordinated multi-tier recovery, and it would only handle one part of the traffic-routing problem.

SQL Server Failover Cluster Instance (FCI)

Why wrong: A SQL Server Failover Cluster Instance protects the entire SQL Server instance at the compute/storage level using shared storage (e.g., Azure Shared Disks or Storage Spaces Direct in Azure VMs). It does not replicate data on its own; the single copy of data lives on shared storage, and the secondary node owns the same storage after failover. It cannot provide synchronous zero-data-loss replication across separate storage, and it has no readable secondary replicas for reporting, so it does not meet the stated requirements.

Azure Site Recovery

Why wrong: Azure Site Recovery orchestrates VM-level replication to a secondary Azure region for disaster recovery, continuously replicating managed disks using asynchronous snapshots. It targets regional outages, not high availability within the primary region; RPO is typically a few minutes, so it cannot guarantee zero data loss. Even if used for failover, it replicates the whole VM rather than enabling readable secondary SQL replicas, so it cannot satisfy the zero-data-loss or reporting-offload requirements.

Azure Backup

Why wrong: Azure Backup provides application-consistent snapshots and long-term retention of SQL Server VMs, but it is purely a backup and restore mechanism. It does not monitor SQL Server health or perform automatic failover, and a restore inherently recreates data only as of the last recovery point. Because backups are taken on a schedule (e.g., daily or hourly), recent transactions since the last backup would be lost, so it cannot achieve zero data loss or provide active readable secondaries for reporting.

Azure Backup

Why wrong: Azure Backup is designed for backups and point-in-time restore, not for continuous replication and automated failover with specified RPO/RTO for disaster recovery.

Azure Migrate

Why wrong: Azure Migrate is used for assessing and migrating on-premises workloads to Azure, not for ongoing replication and disaster recovery.

Manual VM replication to secondary region

Why wrong: Manual replication cannot guarantee the required RPO/RTO and does not provide automated failover or a simple way to perform non-disruptive testing.

Azure Backup full VM restore

Why wrong: Azure Backup full VM restore recreates the entire VM from a recovery point, including all disks, network settings, and system configuration, which is a time-consuming and resource-intensive operation. For recovering a single file, this approach is overkill and inefficient, as it requires a complete VM deployment or overwrite, potentially incurring downtime and additional costs, whereas file recovery is designed to give instant access to just the needed data.

Azure Site Recovery

Why wrong: Azure Site Recovery is fundamentally a disaster recovery solution that continuously replicates entire Azure VMs to a secondary region for planned or unplanned failover, with orchestrated networking, replication, and recovery plans. It is not a backup-and-restore service for individual files; attempting to retrieve a single file from Site Recovery would require failing over an entire VM and then copying the file out of it, which introduces significant downtime, complexity, and cost. Azure Backup is the appropriate service for granular file-level recovery, whereas Site Recovery is designed to maintain business continuity at a site level.

Azure Storage snapshots

Why wrong: Azure Storage snapshots, such as managed disk snapshots, are point-in-time read-only copies of the underlying storage, but they are independent of Azure Backup and lack a centralized Recovery Services vault, backup policies, retention management, and role-based access control. To restore a file, you would need to manually share or attach a snapshot to a VM, which requires scripting and exposes a cumbersome process that doesn't scale for policy-based protection. Additionally, Azure Backup itself creates snapshots at the storage layer for speed, but the user-facing file recovery feature provides a much simpler and safer interface than raw snapshots.

SQL Server Always On Failover Cluster Instance (FCI) with shared disks

Why wrong: A Failover Cluster Instance (FCI) is a single SQL Server instance running on clustered nodes that share one disk, so there is only ever one copy of the database; failover moves the shared storage from one node to another but does not create a readable secondary copy. Even though FCI provides automatic failover, the lack of an online secondary replica means it cannot satisfy any requirement to offload read-only workloads, and relying on Azure shared disks introduces a storage-level single point of failure.

Azure SQL Database Managed Instance with active geo-replication

Why wrong: Azure SQL Managed Instance is a Platform-as-a-Service offering, not a deployment of SQL Server on Azure VMs, so it is not a direct replacement for an existing VM-based environment. Its active geo-replication feature copies data asynchronously to a secondary in another region and requires manual failover or failover groups, and it lacks the ability to manage the underlying OS or run traditional Always On Availability Group listeners, making it architecturally unsuitable for this scenario.

Azure SQL Database with active geo-replication

Why wrong: Azure SQL Database's active geo-replication is designed for the single database and elastic pool PaaS offerings, not for SQL Server on Azure VMs. Geo-replication is asynchronous by default, so committed transactions can be lost in a regional outage, which is unacceptable for a critical database that requires synchronous zero-data-loss replication. This option also has no availability-zone-local synchronous replica concept comparable to Always On Availability Groups, and moving to it would require re-platforming rather than maintaining the existing SQL Server VM architecture.

Azure Backup and Azure Traffic Manager

Why wrong: Azure Backup provides backup and restore but does not meet the RPO/RTO for replication and does not support automated failover or test failovers.

Azure Site Recovery and Azure Front Door

Why wrong: Azure Front Door, while a global traffic management service, is primarily designed for optimising performance, caching, and WAF capabilities for web applications. It can route traffic and perform automatic failover between backend pools, but it doesn't integrate directly with Azure Site Recovery's failover process to automatically update DNS records or endpoint configurations in the same way Azure Traffic Manager does for a full regional disaster recovery event. This combination is tempting because Azure Front Door offers global routing and automatic failover for web applications, making it suitable for active-active deployments or performance-based routing scenarios.

Azure Backup and Azure Front Door

Why wrong: Azure Backup does not provide the required replication capabilities, and Azure Front Door alone cannot replicate VMs.

Create a recovery plan and add a manual step or script to move VMs to the availability set after failover

Why wrong: A recovery plan’s manual step or script runs after failover, but Azure Site Recovery’s native replication settings cannot guarantee automatic placement into a specific availability set during the failover process itself—the VM would be created without that constraint, requiring post-failover intervention that violates the “automatically placed” requirement. This approach is tempting because recovery plans are designed for custom orchestration tasks, such as starting services or updating DNS, and would be correct if the goal were to adjust VM configuration after failover rather than enforce placement as part of the failover operation.

Convert the managed disks to unmanaged disks for replication, then specify the availability set

Why wrong: Converting managed disks to unmanaged disks before replication is both unnecessary and counterproductive. ASR fully supports managed disk VMs and, in the target compute and network settings, lets you choose an availability set directly for managed disks; unmanaged disks require a storage account and still do not enable any additional placement capability. The conversion would require downtime and additional data movement, and because the correct placement control already exists for managed disks, this approach introduces risk without solving the stated requirement.

Azure Site Recovery does not support placing VMs into an availability set in the target region

Why wrong: The premise of this option is factually incorrect: Azure Site Recovery does support placing VMs into an availability set in the target region. During replication configuration, the 'Compute and Network' blade allows you to specify a target availability set, and ASR will apply that setting when the VM is failed over. The service even supports this for both managed and unmanaged disk VMs, so choosing this option would incorrectly conclude that the requirement is impossible to meet via native ASR.

Recovery plan with manual steps

Why wrong: A recovery plan with only manual steps depends on a human operator to remember and execute the exact startup order for the web, app, and data tiers and to run custom scripts by hand during a live disaster. This human intervention lengthens RTO, is prone to errors or skipped dependencies, and cannot guarantee that scripts are executed at the correct moment in the failover sequence. In contrast, a recovery plan with automation runbooks executes the same steps automatically the instant failover occurs, so this option fails both the ordering and scripting requirements.

Failover with network mapping

Why wrong: Failover with network mapping only lets you specify which Azure virtual network each VM's NIC should connect to after failover; it does not influence the order in which tiers start or run any custom preparation scripts. While mapping to the correct VNet is necessary for connectivity, it is completely orthogonal to sequencing and script execution. A VM can have the correct network mapping yet still come up before its database dependency is ready, so this option does not meet the requirements.

Test failover with isolation

Why wrong: Test failover with isolation is designed for disaster-recovery drills: it creates a network-isolated copy of the replicated VMs so the test does not affect the production site or the actual recovery plan. It validates that the replicated images and settings are healthy, but it does not define the production failover startup sequence, nor does it execute custom scripts in the real failover workflow. Relying only on test failover as the recovery strategy would still require manual steps and incorrect dependency start order in a genuine outage.

Use Azure Site Recovery with a replication policy of 30-second frequency, create multi-VM consistency groups for each tier, build a recovery plan with script actions for ordering and static IP mapping, and use test failover for drills

Why wrong: Incorrect: Azure Site Recovery for Azure VMs does not support a 30-second replication frequency; the minimum is 5 minutes. This configuration cannot meet the 5-minute RPO.

Use Azure Site Recovery with a replication policy of 15-minute frequency and configure manual IP mapping after failover

Why wrong: Incorrect: 15-minute replication frequency exceeds the 5-minute RPO, and manual IP mapping after failover would increase RTO.

Use Azure Backup with daily snapshots and a geo-restore option, then manually restore VMs in order

Why wrong: Incorrect: Azure Backup with daily snapshots cannot achieve a 5-minute RPO or 15-minute RTO; manual restore does not support IP retention or automated ordering.

Azure Backup with backup policies set to 15-minute frequency

Why wrong: Azure Backup's 15-minute frequency feature provides frequent recovery points, but it is a backup service that stores point-in-time snapshots in a Recovery Services vault, not a disaster recovery solution. It lacks continuous replication to a secondary region, automated failover orchestration, and recovery plans, so restoring a multi-VM application within the 2-hour RTO would require manual, time-consuming steps and does not support non-impactful test failover.

Azure Site Recovery with crash-consistent replication

Why wrong: Crash-consistent replication in Azure Site Recovery replicates data as it exists at the exact moment of a crash, without flushing memory buffers or ensuring application transactions are committed. While it can achieve the 15-minute RPO, it does not guarantee that the application's data files and database logs across multiple VMs are transactionally aligned, which risks corruption or data loss when the application is recovered after failover.

Azure Backup with application-consistent snapshot

Why wrong: Azure Backup's application-consistent snapshots do capture consistent application state via VSS, but they are used only for backup/restore scenarios, not for continuous DR replication. The service does not maintain a warm standby in a secondary region, does not provide automated cross-region failover, and lacks recovery plan automation; therefore, meeting a 2-hour RTO for a multi-VM application would require manual intervention and does not include isolated test failover capabilities.

Active geo-replication

Why wrong: Active geo-replication is a feature exclusive to Azure SQL Database (single databases and elastic pools); it is not supported on Azure SQL Managed Instance. For Managed Instance, the equivalent disaster recovery mechanism is auto-failover groups, which provide the necessary synchronous replication and automatic failover semantics. Attempting to use active geo-replication for a Managed Instance would be architecturally invalid because the feature is simply unavailable for this deployment option, making it an incorrect choice regardless of its data-loss characteristics.

Geo-restore of backups

Why wrong: Geo-restore relies on geo-redundant storage (GRS) backups that are asynchronously replicated to a paired region, resulting in a typical recovery point objective (RPO) of up to 1 hour — meaning up to an hour of committed transactions can be lost. Additionally, the restore process involves provisioning a new Managed Instance from the backup, which can take several hours depending on database size, far exceeding the required sub-1-hour RTO. Therefore, geo-restore fails the zero-data-loss and recovery-time guarantees required by this critical application.

Azure Site Recovery

Why wrong: Azure Site Recovery is designed to orchestrate disaster recovery for Azure IaaS virtual machines, replicating the entire VM at the hypervisor level, not the database transaction level. It cannot be used to create a read-only secondary for Azure SQL Managed Instance, nor does it provide the SQL-aware synchronous replication needed to guarantee zero data loss. Since the application runs on a platform-as-a-service database, Site Recovery is an irrelevant tool and would not meet the specified RPO/RTO requirements.

Azure SQL Database backup to geo-redundant storage

Why wrong: Geo-redundant backup storage relies on automatically taken database backups (full, differential, and transaction log) that are copied to a paired region, but geo-restore can only restore the database to a point in time corresponding to the last successfully uploaded log backup, which yields a typical RPO of 1 hour and an RTO of up to 12 hours. It does not maintain a continuously synchronized hot secondary, so during a regional outage you would be restoring a database that could lose up to an hour of committed transactions and face a long rebuild time. Therefore, though backups are essential for point-in-time recovery, they are not an adequate DR solution for a critical application with tight RPO/RTO.

Azure SQL Database with zone-redundant configuration

Why wrong: A zone-redundant configuration for Azure SQL Database places the database across multiple availability zones within the same region (for example, the Provisioned tier with zone redundancy), which protects against a single datacenter or availability zone failure but cannot survive a regional outage or disaster. Since the replicas remain inside the same geographic region, any incident that impacts the entire region—such as a large-scale natural event—takes down all replicas together, so this option does not provide geo-disaster recovery. It is a high-availability feature rather than a disaster-recovery feature.

Azure SQL Database with failover group using manual failover

Why wrong: An Azure SQL Database failover group with manual failover still requires an operator to initiate the failover action, so the database remains unavailable until someone detects the outage, decides to fail over, and runs the command—this can easily exceed the 1-hour RTO and introduces human error risk. While a failover group uses geo-replication behind the scenes, manual failover mode does not automatically respond to unplanned regional outages, and it will not fail over by itself. For planned maintenance, a manual failover can be acceptable, but for an unplanned disaster the lack of automation makes the RTO unpredictable.