Design business continuity solutions practice questions

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

Why it fails: 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 it fails: 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 it fails: 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.

B

Why it fails: 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 it fails: 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 it fails: 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.

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

Why it fails: 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 it fails: 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 it fails: 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.

Azure SQL Database with geo-restore

Why it fails: 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 it fails: 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 it fails: '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 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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.

Active geo-replication

Why it fails: Active geo-replication is asynchronous and maintains a readable secondary in a paired region, but it requires manual failover and offers no orchestration or automatic policy. Because replication is asynchronous, the secondary can lag, so a forced failover may lose committed transactions and the RPO will be greater than zero. This makes it unsuitable for meeting a strict zero-data-loss requirement with fast, automated recovery.

Auto-failover groups with read-scale enabled

Why it fails: Auto-failover groups with read-scale enabled, in the Business Critical or Premium service tier, use synchronous replication between the primary and secondary, guaranteeing zero data loss on failover. The group provides automatic failover triggered by the service, with an RTO typically under 30 seconds, and it also permits read-only query traffic on the secondary. This combination of synchronous durability, automatic response, and read-scale capability satisfies the critical database requirement for a regional disaster.

Point-in-time restore

Why it fails: Point-in-time restore recovers a database to any earlier point within the configured retention window by creating a new database, which helps remediate logical corruption, accidental deletes, or malformed data changes. However, it is an operational data recovery feature, not a disaster recovery mechanism, and it cannot protect against a regional outage because it relies on backups stored in the same region. Restoring from a point in time also involves RPO and RTO that are not designed for automatic, short-failover objectives.

Enable application-consistent recovery for all VMs and use ExpressRoute.

Why it fails: Enabling application-consistent recovery for every VM invokes VSS and extra agents, which adds CPU/memory overhead and increases replica storage costs, while ExpressRoute only improves network reliability—it does nothing to reduce replication storage transactions or RPO cost. More importantly, independent app-consistent snapshots do not guarantee a single shared recovery point across the entire multi-tier application; that requires a multi-VM consistency group. Thus, this approach is more expensive and still fails to meet the crash-consistency requirement.

Use standard recovery plans and default replication policy.

Why it fails: The default Azure Site Recovery policy creates a recovery point every 5 minutes, so the cost for storage and network replication is higher than needed when a 15-minute RPO is acceptable. Standard recovery plans orchestrate failover and scripted steps, but they do not create a consistent point-in-time across multiple VMs; each VM is replicated independently. Consequently, using the default policy with a recovery plan yields unnecessary expense and cannot satisfy the multi-VM consistency needed for this critical tiered application.

Configure a single recovery plan with manual failover and use Premium SSD managed disks.

Why it fails: Manual failover in a recovery plan lets an operator initiate failover, but it does nothing to align the recovery points of the VMs—each VM may fail over to a different timestamp, risking inconsistent data across tiers. Premium SSD managed disks deliver better performance but carry higher storage costs and have no effect on RPO, replication frequency, or cross-VM crash consistency. This option therefore increases expenditure while leaving the core consistency problem unsolved.

Azure Site Recovery for VMs and SQL Server Always On Availability Groups with synchronous commit

Why it fails: Always On Availability Groups with synchronous commit mandates that the primary replica wait for the secondary replica to acknowledge hardening of the transaction log before committing. Across Azure regions, typical network round-trip latencies of 50–100 ms add directly to every transaction, severely degrading application performance and potentially causing timeouts. Although synchronous commit can provide zero data loss, the latency penalty is unacceptable for a cross-region DR solution and is therefore not cost-effective or practical.

Azure Site Recovery for VMs and SQL Server log shipping

Why it fails: SQL Server log shipping relies on periodic transaction log backups to a secondary server, so the recovery point is bounded by the log backup frequency, which is generally minutes apart and far above the required 30-second RPO. On failover, remaining log backups must be manually applied and the database brought online, which extends the RTO well beyond the stated 10-minute goal and requires manual intervention. Combining log shipping with Azure Site Recovery adds complexity without automating SQL-level consistency, making it an unsuitable DR option for this critical workload.

Azure Backup for VMs and SQL Server database mirroring

Why it fails: Azure Backup for SQL Server can take transaction log backups, but the minimum log backup interval is currently 15 minutes, which cannot satisfy the 30-second RPO requirement for this critical application. In addition, database mirroring is a deprecated feature of SQL Server and lacks the automated, cross-region failover capabilities that Always On Availability Groups provide. Relying on VM-level Azure Backup snapshots would also introduce an even larger RPO and RTO, so this combination does not meet the stated DR objectives.

Azure Site Recovery for VMs and active geo-replication for the database

Why it fails: Azure Site Recovery correctly replicates the VMs, but active geo-replication is the wrong database technology because it is only supported on Azure SQL Database (single databases and elastic pools), not on Azure SQL Managed Instance. A managed instance requires auto-failover groups for geo-replication and automatic failover. Therefore, this combination is invalid because the database replication cannot actually be configured on the target service, making the solution unworkable.

Azure Backup for VMs and auto-failover groups for the database

Why it fails: Azure Backup for VMs provides scheduled, snapshot-based backup and restore, not continuous replication to a secondary region, and it does not include any automatic failover orchestration. In a disaster, you must manually initiate a restore to a new VM, which is a slow, hands-on process that can easily breach the 2-hour RTO. Auto-failover groups are appropriate for the database, but without Azure Site Recovery on the VM tier the overall solution still fails to meet the disaster recovery requirement.

Deploy a second region with VMs and database replicas manually configured and Azure Traffic Manager

Why it fails: Manually configuring a second region with VM replicas and database replicas gives you copies of your resources, but Azure Traffic Manager only performs DNS-level load balancing and endpoint health checks—it does not replicate data or coordinate database failover. Both VM failover and database promotion would have to be executed manually by an administrator after an outage is detected, leading to RPO and RTO values that are measured in hours or days rather than minutes. This ad-hoc approach is far less reliable and efficient than using native Azure services like Site Recovery and auto-failover groups to automate the entire process.

Azure Traffic Manager with active-passive and geo-replication for Azure SQL Database

Why it fails: Azure Traffic Manager operates at the DNS level and can direct traffic to endpoints in different regions, but it cannot inspect HTTP/S requests, rewrite URLs, or provide WAF-based security, which are often required for global web applications. For SQL, geo-replication alone replicates data but does not automatically fail over; you must configure auto-failover groups to achieve the necessary RPO/RTO, and DNS TTL plus client caching can delay failover. Thus, this combination lacks the HTTP-layer routing and integrated security that Azure Front Door provides.

Azure Application Gateway with backend pools in multiple regions and SQL Database failover groups

Why it fails: Azure Application Gateway is a regional layer-7 load balancer that operates within a single Azure region; it cannot route or fail over traffic to backend pools in another region automatically, because its frontend IP and configuration are region-scoped. Even if SQL Database failover groups are configured for geo-redundancy, the web tier would still be unreachable if the entire region that hosts Application Gateway becomes unavailable, since no global ingress point exists. Therefore, while it provides advanced HTTP routing and WAF, it lacks the cross-region global routing capability essential for this scenario.

Azure Load Balancer with multiple regions and Azure SQL Database automatic failover

Why it fails: Azure Load Balancer is a regional layer-4 load balancer that forwards traffic based on IP and TCP/UDP without inspecting HTTP headers or paths, and it cannot route traffic across Azure regions; its frontend and backend are confined to a single region. Although Azure SQL Database automatic failover (via auto-failover groups) can shift the database to another region, the application's entry point would still be a regional Load Balancer, leaving the web app inaccessible if that region fails. This combination fails to provide global HTTP-level routing, health-based failover across regions, or WAF protections that a globally available web solution requires.

Azure Site Recovery.

Why it fails: Incorrect. Azure Site Recovery is a disaster recovery replication tool, not a backup service. It does not support long-term retention or granular database restore.

Azure Database Migration Service.

Why it fails: Incorrect. Azure Database Migration Service is used for migrating databases to Azure, not for backup or long-term retention.

Azure Storage with incremental snapshots.

Why it fails: Incorrect. Azure Storage incremental snapshots are a storage-level feature, not a backup service. They lack backup orchestration, retention policies, and application consistency.

Azure SQL Database: Distributed cache for low-latency data access

Why it fails: This pairing incorrectly assigns a caching role to Azure SQL Database. SQL Database is a durable, disk-backed relational database management system that stores data in B-tree structures and guarantees transactions through ACID properties; it is not engineered as an in-memory distributed cache. The description of a distributed cache for low-latency data access belongs exclusively to Azure Cache for Redis, which keeps data in memory and sacrifices durability for speed. Conflating the two misunderstands the fundamental trade-off between persistent transactional storage and ephemeral high-speed caching.

Azure Cosmos DB: Fully managed SQL Server database with high availability

Why it fails: This is incorrect because Azure Cosmos DB is not a SQL Server database engine. While it offers a SQL API (Core API) that supports queries over JSON documents, the underlying storage engine is a proprietary schema-agnostic index built on atom-record-sequence (ARS), not the relational engine used by SQL Server. A fully managed SQL Server database with high availability describes Azure SQL Database or Azure SQL Managed Instance, which provide true T-SQL compatibility and relational semantics. Cosmos DB is purpose-built for globally distributed, multi-model NoSQL workloads, not as a drop-in SQL Server replacement.

Use Azure SQL Database automatic failover groups with manual failover.

Why it fails: Configuring a failover group with manual failover still uses active geo-replication for the data path, but the failover action itself requires human intervention to detect the outage, evaluate the situation, and execute the switch. This operational lead time—including notification, decision-making, script execution, and DNS propagation—typically adds several minutes to the recovery, which violates the stated RTO of less than one minute. Even though manual failover can provide zero data loss, it cannot meet the sub-minute recovery target.

Use Azure SQL Database zone-redundant configuration.

Why it fails: A zone-redundant configuration uses Always On availability groups to maintain synchronous replicas across multiple availability zones within the same primary region. This design protects against a single data center or zone failure, but it does not protect against a regional outage where the entire Azure region becomes unavailable. Because the replicas remain in the same geography, zone redundancy cannot satisfy a disaster-recovery requirement that needs the database to be restored to a different region.

Use Azure SQL Database geo-restore from geo-redundant backups.

Why it fails: Geo-restore is a backup-based disaster recovery method that creates a new database from the latest geo-redundant backup stored in a paired region. However, these backups are taken periodically and copied asynchronously, so the RPO can be as high as five minutes, and the restore process often takes hours to locate, download, and provision the database files. This option is unable to deliver the required RTO of less than one minute and also risks losing recently committed transactions, making it unsuitable for a stringent DR requirement.

Configure backup replication across two Recovery Services vaults in different regions.

Why it fails: Azure Backup does not support replication across vaults natively.

Enable geo-redundant storage (GRS) for the Recovery Services vault.

Why it fails: GRS stores data in a paired region but does not automatically enable restore; Cross-region restore must be enabled.

Use zone-redundant storage (ZRS) for the Recovery Services vault.

Why it fails: ZRS protects against zone failure within a region, not region failure.

Deploy App Service in one region with multiple instances. Use Azure SQL Database failover groups with manual failover.

Why it fails: Manual failover does not meet the 5-minute RTO.

Deploy App Service in two regions with Azure Front Door. Use Azure SQL Database with zone-redundant configuration.

Why it fails: Zone-redundant configuration does not protect against regional outages.

Deploy App Service in two regions with Azure Traffic Manager. Use Azure SQL Database geo-restore for the database.

Why it fails: Geo-restore has an RTO of several hours, exceeding the 5-minute requirement.

The recovery point retention is set to 5 days, causing storage issues.

Why it fails: Retention is 1440 minutes (1 day), not 5 days.

The replication provisioning state failed.

Why it fails: Provisioning state is Succeeded, not failed.

The replication interval is set to 15 minutes, exceeding the required RPO.

Why it fails: The interval is 300 seconds (5 minutes), not 15 minutes.

Daily backup policy with 30-day retention

Why it fails: A daily backup policy with 30-day retention is inadequate for protecting VMs from accidental deletion because it only keeps a single tier of recovery points: one per day, and all are purged after 30 days. While it does capture recent changes, it lacks weekly, monthly, or yearly snapshots, so you cannot restore a VM state from, say, six months ago if an accidental deletion is discovered after the 30-day window. This short retention is fine for operational recovery but does not meet the long-term preservation needed to guard against deletions that go unnoticed for an extended period.

Monthly backup policy with 12-month retention

Why it fails: A monthly backup policy with 12-month retention is wrong for this scenario because it only creates one backup every month, with no daily or weekly recovery points. If a VM is accidentally deleted a day after the last monthly snapshot, you would lose up to a month of changes, and with only 12 monthly backups, you cannot restore states from more than a year ago. This policy is designed for cheap archival, not for comprehensive deletion protection where frequent, granular recovery points are essential.

Azure Backup Enhanced policy

Why it fails: Azure Backup Enhanced policy is not the correct answer because it is specifically tailored for SQL Server and SAP HANA workloads, offering sub-hourly log backups and file-level consistency tailored to database transaction logs. For a general-purpose Azure VM, an enhanced policy does not provide the same simple multi-tiered retention for full VM backups; it is not a generic VM protection option. The question assumes a basic VM scenario, so choosing an enhanced policy would be a category mismatch—it protects databases, not arbitrary VMs, and does not inherently offer GFS-style retention.

Azure Backup

Why it fails: Azure Backup is designed to create recovery point snapshots and retain them for long-term compliance, but it lacks any health monitoring or automatic traffic redirection capability. To fail over, an operator would have to manually restore and reconfigure services, which cannot meet the stated automatic failover requirement or the 15-minute RPO. Backup is a data-protection mechanism, not a disaster-recovery orchestration layer, so it is incorrect for this scenario.

Azure Site Recovery for VM replication

Why it fails: Azure Site Recovery replicates entire virtual machines to a secondary region, enabling full VM failover, but this is unnecessary for stateless tiers that can be quickly redeployed from templates or scale sets. Running ASR continuously would incur extra costs and replication overhead while providing no benefit because no state needs to be copied. The correct approach for stateless tiers is to use Traffic Manager for routing and redeploy compute resources, not to replicate VM states.

Azure Front Door

Why it fails: Azure Front Door provides global load balancing and application acceleration at the HTTP/S layer, but it does not perform automatic database failover or manage replication between database replicas; the RPO of 15 minutes and automatic failover for the database require a native database-level solution such as Azure SQL Database failover groups. It is tempting because Front Door can route traffic away from a failed web or business tier, and in a scenario where only stateless tiers need regional failover with no database RPO constraint, it would be the correct choice.