RDS Multi AZ practice questions

Implement Azure DNS Private Resolver for resolution

Why wrong: Azure DNS Private Resolver provides recursive resolution and conditional forwarding for private DNS zones between on-premises and Azure virtual networks, but it is not a data-plane network connectivity service. It neither carries application traffic nor provides link failover or bandwidth; even if DNS queries resolve correctly, an outage on the underlying IP connectivity path will still prevent access to workloads. Choosing this option would address name resolution, not the required hybrid connectivity redundancy.

Use a single VPN gateway with active-standby mode

Why wrong: A single VPN gateway in active-standby mode is insufficient when the goal is overall hybrid network resilience because the gateway resource is still reliant on one underlying gateway site and one public IP, and it does not provide an independent network path for failover. The standby instance inside the same gateway only protects against an OS fault or instance maintenance, not against a regional Azure outage, an internet provider outage, or a loss of the site-to-site VPN connection. To achieve redundancy, you need either multiple gateway deployments or a second independent connection such as a second ExpressRoute circuit.

Use a single ExpressRoute circuit with a VPN gateway as failover

Why wrong: A single ExpressRoute circuit backed by a VPN gateway gives you a fallback path, but it is not as redundant as two ExpressRoute circuits because the sole circuit remains a single point of failure in the private interconnect. If the circuit experiences a fiber cut, connectivity-provider maintenance, or BGP peering loss, failover to the VPN tunnel depends on IPsec convergence and is usually constrained by the VPN Gateway's throughput, which is often lower than ExpressRoute. Meeting a strict enterprise SLA generally requires two diverse ExpressRoute circuits, not one circuit plus a best-effort VPN.

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.

Microsoft Entra ID Identity Protection

Why wrong: Microsoft Entra ID Identity Protection is a risk-based detection engine that evaluates sign-in risk and user risk using signals like anonymous IP addresses, atypical travel, or leaked credentials. While it can automatically require MFA in response to detected risk, it cannot enforce MFA based on static, administratively defined conditions such as excluding your corporate IP range or requiring a specific device compliance status. The described scenario is a deterministic access policy, not a risk-based response, so Identity Protection is not the correct tool.

Microsoft Entra ID Privileged Identity Management

Why wrong: Microsoft Entra ID Privileged Identity Management (PIM) is designed for just-in-time, time-bound, and approval-based activation of elevated roles such as Global Administrator or Role-Based Access Control assignments. It manages the lifecycle of privileged role assignments and provides alerts and access reviews for those roles, but it does not apply authentication requirements to end-user access of applications. Requiring MFA for general sensitive app access while excluding certain networks is strictly an authentication policy, which falls outside PIM's scope.

Microsoft Entra ID Identity Governance

Why wrong: Microsoft Entra ID Identity Governance focuses on access lifecycle management through entitlement management, access certifications, and access reviews to answer 'who should have access and for how long.' It does not evaluate authentication context in real time; it is not an authentication policy enforcement point. The scenario mandates MFA and device compliance at sign-in time, which is a session control condition, not an access-governance decision about resource membership or ongoing access eligibility.

Use the Cool tier for initial storage, and a lifecycle rule to move to Archive after 30 days.

Why wrong: Cool tier is for data accessed infrequently but with immediate availability. Using Cool for the first 30 days may increase cost compared to Hot because Cool has higher read costs and lower storage cost, but Hot is cheaper for frequent access. More importantly, the requirement is to minimize cost, and Hot then Archive is the optimal path.

Use the Hot tier for initial storage, and a lifecycle rule to move to the Cool tier after 30 days, then to Archive after 7 years.

Why wrong: This two-step transition is inefficient and more expensive. Moving blobs from Hot to Cool after 30 days incurs a write operation cost, and then moving them again from Cool to Archive after 7 years incurs an additional transition cost, but the data is rarely accessed and can go directly from Hot to Archive. Moreover, Cool tier storage is more expensive than Archive, so holding the data in Cool for nearly the entire 7-year retention period defeats the goal of minimizing cost. A single lifecycle rule from Hot to Archive after 30 days achieves the same retention with lower operational and storage costs.

Use the Archive tier for initial storage, and a lifecycle rule to move to Hot for the first 30 days.

Why wrong: Storing logs in Archive from day one is impractical because Archive is optimized for rarely accessed data with retrieval latency measured in hours. Any reads to these logs during the first 30 days would trigger rehydration, incurring substantial costs and delays, and the lifecycle rule to move them to Hot would also require rehydration and a costly archival read operation. This arrangement inverts the required access pattern: frequent reads require Hot, not Archive. The correct design is to keep data hot for initial access and then transition to Archive to minimize cost.

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.

Azure App Service with autoscale rules and deployment slots

Why wrong: Azure App Service is a platform-as-a-service offering that abstracts and manages the underlying VMs on your behalf; even though it supports autoscale rules and deployment slots, you are never selecting or patching the virtual machines yourself, which violates the explicit "on Azure virtual machines" constraint in the requirement. The autoscaling in App Service scales the number of worker instances running on a shared or dedicated App Service plan, not VM scale sets, and deployment slots address staging and swap rather than compute capacity. Because the prerequisites demand IaaS-level VM control, App Service is disqualified despite its operational convenience.

Azure Load Balancer with a backend pool of VMs and autoscale rules applied to individual VMSS

Why wrong: An Azure Load Balancer is a Layer-4 load balancer that distributes traffic to a backend pool, but it has no autoscale engine of its own; any scaling rules must be created on the VMSS (or a separate autoscale setting), so this option merely describes an architectural fragment rather than a complete solution. If the backend pool is simply a loose list of standalone VMs, you cannot apply CPU-based autoscale to them at all, because autoscale in Azure is attached to a scale set. Even with a VMSS behind the load balancer, the option does not state that the scale set is distributed across availability zones, so it fails part of the high-availability requirement.

Azure Traffic Manager with endpoints in separate regions and Manual scaling of VMs

Why wrong: Azure Traffic Manager is a DNS-based global traffic router used to steer users to endpoints in different Azure regions; it does not monitor CPU utilization of your VMs and cannot automatically add or remove VM instances based on load. The requirement is for automatic scaling based on CPU and protection against a zone failure within a region, and manually scaling VMs directly contradicts "automatic". Spreading endpoints across regions can protect against a regional outage if you replicate the app, but that is not the same as zone-level high availability, and the lack of autoscale makes this option invalid.

Use Hot tier for 30 days, then use Cool tier for 7 years, with a lifecycle rule to delete after 7 years.

Why wrong: Using the Cool tier for a seven-year retention period overlooks that Archive tier provides a substantially lower storage price for data that is no longer actively accessed. While the lifecycle rule correctly automates deletion after 7 years, the Cool tier's storage rate is significantly higher than Archive for long-lived, rarely read data, making this solution unnecessarily expensive over the retention period. Since the data is only frequently accessed for the first 30 days, Cool tier is an economically suboptimal middle ground for the remaining 6+ years.

Use Cool tier for 30 days, then use Archive tier for 7 years, no lifecycle rule needed.

Why wrong: Choosing Cool tier for the initial 30 days is cost-inefficient because Cool tier has higher per-GB read and retrieval costs than Hot tier, which already offers the lowest access costs for frequently used data. Additionally, without a lifecycle rule, the data will never be automatically deleted after 7 years, resulting in ongoing storage charges indefinitely. The correct pattern pairs a Hot tier for frequent reads with an Archive tier for infrequent, long-term retention, coupled with a lifecycle policy that deletes the blob at a specific age.

Use Archive tier immediately, with a lifecycle rule to delete after 7 years.

Why wrong: Placing data directly into Archive tier fails to account for the high frequency of access during the first 30 days; Archive tier's retrieval latency (typically minutes to hours) and per-GB read charges make it inappropriate for active use. Although the lifecycle rule handles the eventual deletion correctly, immediate archiving would force repeated expensive rehydration operations for the very data users need most often. A tiering strategy must match early access patterns with Hot tier, then transition to Archive only once the data becomes rarely accessed.

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.

Single-master write region with Strong consistency and multiple read regions

Why wrong: A single-master write region with strong consistency requires every write to be synchronously replicated to all read regions before acknowledging the client, so write latency scales with the distance to the farthest region and can be significantly higher than necessary. This configuration also reduces write availability because if any read region is unreachable or unhealthy, writes cannot be committed, risking availability during a partial regional outage. Since the application only needs per-user session consistency, strong consistency is an unnecessary and costly over-provisioning that does not align with the global e-commerce reading pattern, where reads dominate and writes are localized.

Multi-master write with Eventual consistency and all regions enabled for writes

Why wrong: Enabling all regions for writes (multi-master) is unjustified because the application receives writes from only one region, so a single write region avoids the need for conflict-resolution logic and reduces operational cost. Eventual consistency, without session tokens, cannot guarantee that a user reads the data they just wrote within the same session; they might see stale or conflicting data as reads are served from different regions. This directly violates the explicit session consistency requirement while adding unnecessary write-write conflict handling, higher complexity, and no tangible benefit for a workload with a single write location.

Multi-master write with Strong consistency and two regions

Why wrong: This configuration is invalid in Azure Cosmos DB because strong consistency is not supported when multiple write regions are enabled; the service only allows strong consistency with a single write region, making a multi-master strong-consistency topology technically impossible. Even if it were possible, combining strong consistency with multi-master would force every write to be synchronously replicated across all regions before acknowledgment, which eliminates the latency benefits of multi-master writes and significantly increases both write latency and RU consumption. Since writes originate from only one region and the application only requires session consistency, this approach is overkill, unsupported, and not aligned with the stated requirements.

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.

Use an Azure Load Balancer and configure NSGs on each subnet.

Why wrong: Azure Load Balancer operates at Layer 4 (TCP/UDP) and only distributes traffic based on IP address and port rules. It cannot provide SSL termination, web application firewall (WAF) capabilities, or path-based routing, all of which are essential for protecting and properly routing HTTP(S) requests in a multi-tier web application. Configuring NSGs on each subnet adds basic network-level filtering, but NSGs alone cannot inspect or sanitize application-layer traffic, leaving the web tier vulnerable to SQL injection, XSS, and other OWASP threats. Therefore, this option is incorrect because it lacks the required Layer 7 features.

Use Azure Firewall to inspect all traffic and allow internet traffic to the web tier.

Why wrong: Azure Firewall is a stateful firewall that operates at layers 3-4 with some layer 7 capabilities, but it is not optimized for inbound web traffic with SSL offloading and URL routing like a WAF-enabled service.

Use Azure Front Door to expose the web tier and NSGs for internal isolation.

Why wrong: Azure Front Door is incorrect because it is a global service designed for distributing traffic across multiple regions or public endpoints, whereas this scenario describes a multi-tier application primarily within a single virtual network. While Front Door offers SSL termination, WAF, and URL-based routing, its global scope is not the primary requirement for exposing a web tier residing regionally within a VNet. It would be appropriate for a globally distributed application requiring cross-region traffic management and acceleration.

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.

Move to Cool tier after 30 days, move to Archive tier after 365 days, delete after 7 years

Why wrong: The flaw is not the tier transitions but the deletion expression: '7 years' is not a valid Azure lifecycle numeric value. Azure lifecycle management rules only accept integers for 'days after creation' or 'days after last modification', so the policy would be rejected at validation time. Using '2555 days' is the correct equivalent for 7 years and removes ambiguity around leap-year intervals; therefore this option fails because the rule cannot be executed as written.

Move to Cool tier after 30 days, move to Archive tier after 30 days, delete after 2555 days

Why wrong: Moving to Archive after only 30 days violates the intended access pattern: for the first year logs are accessed occasionally, and Cool tier is designed for that exactly—it offers lower storage cost than Hot while still allowing near-real-time reads. Archive, by contrast, requires rehydration and can add minutes to hours of latency before access. If you transition to Archive at day 30, you'll incur unnecessary retrieval and rehydration costs for every one of the occasional accesses during the remaining 335 days, which is more expensive than leaving the data in Cool.

Move to Archive tier after 30 days, keep in Archive until deletion after 2555 days

Why wrong: Skipping Cool and placing logs into Archive at day 30 means the most frequently used period (the first 30 days) remains Hot, but from day 31 through day 365, when logs are still occasionally queried, you're hit with Archive's rehydration latency and per-GB retrieval charges. Also, once a blob is in Archive it cannot be read directly; you must 'rehydrate' it, adding operational complexity and cost for each access. The correct sequence is Hot→Cool→Archive, so this option misplaces the first-year data and penalizes normal operational workflows.

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.

Availability Set

Why wrong: An Availability Set logically segments VMs within a single Azure datacenter by assigning fault domains (separate racks with independent power and network) and update domains (scheduled reboot groups). This protects against localized hardware failures or patching events, but because all members reside in the same datacenter, a full datacenter outage or zone-scale disaster takes down every VM in the set. Therefore it lacks the cross-zone independence needed for datacenter-failure resilience.

Virtual Machine Scale Set

Why wrong: A Virtual Machine Scale Set automates scaling and load balancing of a fleet of identical VMs, but its default regional configuration distributes instances across fault domains within a region without a hard guarantee of placing them in separate availability zones. Unless you explicitly create a zone-redundant scale set spanning multiple zones, all instances could still land in the same datacenter, leaving them equally vulnerable to a datacenter-level failure. Thus VMSS alone does not provide the required isolation for this scenario.

Proximity Placement Group

Why wrong: A Proximity Placement Group is designed to co-locate VMs in the same Azure datacenter or as close as possible, which reduces network latency for tightly coupled workloads. This actually intensifies the blast radius rather than reducing it: if that single datacenter experiences an outage, all VMs in the group fail together. It also offers no zone-level failure isolation, making it categorically unsuitable for a requirement of datacenter-failure resilience.

Azure Blob Storage with Azure Data Lake Storage Gen2

Why wrong: Blob Storage with ADLS Gen2 is a valid, cost-effective landing zone for raw IoT telemetry, offering massive scale and lifecycle management. However, it is an object store, not a query engine: it has no native time-series indexing, partitioning, or retention-aware query semantics, and no built-in KQL/SQL-style analytics. Any exploration requires an external service such as Azure Data Explorer, Databricks, or Synapse to read the files, adding latency and operational complexity that conflicts with real-time and interactive historical analysis.

Azure SQL Database

Why wrong: Azure SQL Database uses a row-oriented, transactional engine with B-tree indexes that are optimized for OLTP workflows, not the compound-write, append-heavy pattern of IoT telemetry. Sustained ingestion from millions of devices would force heavy DTU/vCore consumption and frequent index maintenance, while lookups by time range become expensive because there is no native time-series partitioning or compression. The required throughput would require massive over-provisioning, making it cost-prohibitive for this workload.

Azure Cosmos DB with SQL API

Why wrong: Cosmos DB is an excellent globally distributed multi-model database, but its SQL API charges request units (RUs) per operation, so the constant high-velocity writes from millions of devices translate into enormous, predictable RU expenditure. Its index is document-centric and does not provide columnar compression or time-series aggregation functions, so typical telemetry queries like 'average temperature per hour over 30 days' require client-side aggregation or expensive scans. Additionally, Cosmos DB struggles with long-range, scan-heavy analytical queries, making it a poor fit for this scenario.

A

Why wrong: An availability set spreads VMs across fault domains and update domains inside a single Azure datacenter, protecting against host- or rack-level hardware failures. However, if the entire datacenter loses power, cooling, or its network fabric, every fault domain in that datacenter can be affected, so an availability set does not survive a whole-datacenter failure. The SLA for two or more instances in an availability set is only 99.95%, which falls below the required 99.99%.

C

Why wrong: Deploying VMs in a single availability zone does not create high availability, because that zone is a single location for power, cooling, and networking; an entire zone outage takes all VMs in that zone offline. Azure Backup only protects data by creating recoverable snapshots with an RPO and RTO, and restoring from backup requires downtime, so it is a recovery or correctness mechanism, not a high-availability mechanism. Consequently, this design neither protects against a datacenter failure nor meets the 99.99% SLA.

D

Why wrong: Using paired Azure regions with Traffic Manager provides disaster recovery for a full regional outage, not high availability inside a single region; Traffic Manager's health probes and DNS failover take minutes to converge, which is too slow for the 99.99% availability target. Azure's 99.99% VM connectivity SLA applies to two or more instances in separate availability zones within the same region, not to geographically replicated deployments, so this option fails the stated requirement.

Azure Site Recovery

Why wrong: Azure Site Recovery is a disaster recovery service that replicates entire Azure VMs to a secondary region for business continuity, not a backup solution. It maintains replication-based recovery points for failover testing and RPO/RTO objectives, but these are not SQL transaction-consistent backups—they cannot restore a database to a specific second or preserve historical versions for long-term archival. Its primary purpose is to recover from a site-wide outage, not to provide granular, point-in-time database restores or retention compliance.

SQL Server managed backup to Azure

Why wrong: SQL Server managed backup to Azure is a T-SQL feature that automates backups to Azure Blob storage, but it is not a centrally managed Azure service—you must configure it individually for each database or instance, setting schedules, retention, and storage accounts manually. It does not integrate with Azure Backup vault, Azure Monitor, or Azure Policy, so you lack centralized visibility and uniform policy enforcement across the enterprise. While it does support transactional log backups for point-in-time restore, the per-instance configuration overhead and lack of managed long-term retention management make it less robust than a dedicated, cloud-native backup solution.

Azure Disk Backup

Why wrong: Azure Disk Backup protects Azure managed disks by taking crash-consistent snapshots at the disk level, not application-consistent SQL database backups. These snapshots do not include transaction log information, so they cannot provide a point-in-time restore to the exact second, and restoring from a snapshot can lead to data loss or corruption of committed transactions. The restore operation replaces the entire disk, which means it cannot recover a single database, and it lacks the ability to schedule log backups or perform granular file-level restores—making it wholly unsuitable for a critical SQL Server workload.

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.