RDS Multi AZ practice questions

Azure Service Health

Why wrong: Azure Service Health tracks the global status of Azure platform services, including service incidents, planned maintenance, and health advisories that affect Azure as a whole. It does not provide any visibility into the health of your own AKS cluster, such as node status, pod density, or container resource usage. The correct tool for cluster-level telemetry is Azure Monitor Container Insights, which sends an agent into your cluster to collect node and workload metrics.

Azure Monitor for VMs

Why wrong: Azure Monitor for VMs is designed specifically for Azure virtual machines, using a Log Analytics agent and Dependency agent to capture VM guest OS performance, processes, and dependency maps. While your AKS nodes are VMs, this solution does not understand Kubernetes primitives like replicasets, services, or pods, nor does it collect kubelet or container-level metrics. Container Insights is the solution that speaks the Kubernetes language, giving you controller, node, pod, and container views that VM-specific monitoring cannot offer.

Azure Application Insights

Why wrong: Azure Application Insights is an application performance management (APM) service that focuses on application code behavior—HTTP requests, dependencies, exceptions, traces, and user sessions sent via SDKs. Although an app instrumented with Application Insights can run inside AKS, it does not monitor the AKS infrastructure itself, such as node health, scheduled pods, or container CPU/memory metrics. Container Insights, by contrast, uses an out-of-band agent to collect infrastructure and container logs, independent of whether each individual application is code-instrumented.

Create an Azure Blueprint that includes a policy initiative

Why wrong: An Azure Blueprint packages templates, policies, and roles for orchestrated deployment, but assigning a blueprint does not retroactively fix resources that already exist. Its policy initiative would only be evaluated on new deployments or when a resource is updated, so non-compliant storage accounts created before the blueprint assignment remain unchanged. Blueprints lack the remediation engine that Azure Policy's DeployIfNotExists effect provides, making it ineffective for this governance scenario.

Assign a custom RBAC role that denies creation of storage accounts without HTTPS

Why wrong: Azure RBAC is an identity-based authorization system that determines who can perform actions like creating or deleting resources, not the configuration state of those resources. A custom role that denies creation of storage accounts without HTTPS would block future non-compliant creation but cannot inspect or modify existing storage accounts to enforce HTTPS-only traffic. Because the goal is to remediate already-deployed resources, RBAC is a prevention mechanism, not a remediation mechanism.

Configure Azure Monitor alerts to notify the security team

Why wrong: Azure Monitor alerts are designed to detect and notify, not to act; they can signal the security team that a storage account is non-compliant, but they cannot change the account's configuration. Even if an alert triggers a runbook or an Azure Function, that would be a separate, custom automation workflow, not an intrinsic governance capability. For an automated governance strategy, relying solely on alerts leaves a gap where non-compliant resources remain until a human or external process responds.

Azure Cosmos DB

Why wrong: Cosmos DB is a multi-model NoSQL service built for globally distributed document, key-value, column-family, and graph workloads. It exposes SQL/MongoDB/Cassandra-compatible APIs and stores data in partitions, but it has no concept of static files, no web server endpoint, and cannot serve HTML/JS/CSS to browsers as a hosted website.

Azure NetApp Files

Why wrong: Azure NetApp Files is an enterprise-grade file service backed by NetApp ONTAP, providing high-performance NFS and SMB shares for HPC, SAP, and VDI workloads. It operates at the file-system protocol layer over the network and has no HTTP-based content serving, no `$web` container, and no static website hosting capability.

Azure Files

Why wrong: Azure Files provides managed SMB and NFS file shares for lift-and-shift migrations, shared application data, and Azure File Sync scenarios. It presents a standard file share path (e.g., UNC or mount point) and has no HTTP/S static content engine, so it cannot translate a directory of HTML files into a browsable, publicly accessible website.

Azure Firewall

Why wrong: Azure Firewall is a managed, stateful network security service that filters both inbound and outbound traffic based on allowed/denied rules, but it is not a logging or analytics platform. Even though it emits application and network rule logs, those logs are raw diagnostic artifacts that require a separate service like Azure Log Analytics to collect, query, and analyze. Therefore, it cannot directly fulfill the requirement to monitor and analyze security events across your environment.

Azure Policy

Why wrong: Azure Policy is an Azure governance service that applies and enforces compliance rules across resources, such as evaluating whether deployments are in the right region or have required tags. It can help maintain a security baseline by flagging non-compliant resources, but it does not collect, store, or analyze log data for security-related monitoring. An Azure Policy evaluation is a point-in-time configuration check rather than a continuous analysis of security signals.

Azure Network Watcher

Why wrong: Azure Network Watcher is a network-level monitoring and diagnostic service that includes tools like packet capture, connection monitor, and IP flow verify to help troubleshoot connectivity and performance issues. It can be enabled to send NSG flow logs to a storage account or a Log Analytics workspace, but the service itself does not analyze those logs or detect security threats. As a platform, it is oriented toward network diagnosis rather than broad security event monitoring and analysis.

Azure Blueprints

Why wrong: Azure Blueprints were a packaging service that bundled templates, policies, and RBAC assignments into a single deployable artifact, but they are deprecated and no longer recommended. Blueprints do not provide a persistent governance hierarchy; they simply orchestrate deployment, whereas management groups offer ongoing, inherited governance. Azure now recommends using management groups combined with policy assignments and deployment stacks as a modern replacement.

Resource tags

Why wrong: Resource tags are key-value pairs attached to resources for metadata, cost allocation, and filtering, but they are not a governance mechanism. Tags do not enforce compliance, provide hierarchical inheritance, or manage access across subscriptions. While policies can require or generate tags, tags themselves cannot organize resources for cross-subscription policy or cost management.

Resource groups

Why wrong: Resource groups are logical containers that group related resources within a single subscription, offering management and lifecycle operations like templates and access control. However, they cannot span multiple subscriptions, do not inherit policies across subscriptions, and lack the organizational hierarchy needed for enterprise-wide governance. Resource groups are operational scopes, not governance structures for the entire Azure environment.

Azure Disk Storage

Why wrong: Azure Disk Storage provides block-level storage volumes for Azure VMs, offering persistent, high-performance disks that are attached to a single VM. It does not provide a shared file system accessible over SMB or NFS; to share files across multiple users you would need to build and manage your own file server on the VM. Unlike Azure Files, it lacks built-in Microsoft Entra ID integration for file-level permissions and pre-configured snapshots, making it a poor fit for a fully managed file share migration.

Azure NetApp Files

Why wrong: Azure NetApp Files is a high-performance, enterprise-grade file storage service built on NetApp ONTAP, offering sub-millisecond latency and advanced capabilities like instant snapshots, cloning, and cross-region replication. While it does support SMB and NFS, it is intended for specialized workloads such as HPC, SAP HANA, or VDI environments, and its cost model requires provisioning capacity pools and careful performance tuning. For a straightforward file server migration, it is overengineered and more complex than Azure Files, which delivers the same core SMB sharing with far less operational overhead.

Azure Blob Storage

Why wrong: Azure Blob Storage is an object storage service designed for massive scale, accessing data via REST APIs, SDKs, and data movement tools, rather than through a traditional file-system interface. It does not natively support SMB file sharing or provide file locking and Microsoft Entra ID integration for user-level file permissions; while BlobFuse can simulate a file system, it is not a true SMB mount for interactive user access. Thus, it is not a suitable replacement for file servers where users expect mapped drives and NTFS-style ACLs.

Manage access control for resources

Why wrong: Azure Policy does not manage access control because it lacks the capability to assign roles or grant user permissions; that is the responsibility of Azure RBAC, which authenticates and authorizes identities via role assignments. Azure Policy only evaluates and enforces resource configuration properties, meaning a user's ability to read, write, or delete a resource remains entirely governed by RBAC, not by policy definitions.

Create new Azure resources based on a template

Why wrong: Azure Policy is an evaluation and enforcement service, not a resource provisioning engine; it does not create virtual machines, storage accounts, or any other Azure resources. Resource creation is performed by Azure Resource Manager through templates, Bicep files, or other deployment tools, while Azure Policy only inspects resources after (or during) deployment to decide whether they comply, possibly denying the operation but never instantiating anything itself.

Automatically remediate non-compliant resources without manual intervention

Why wrong: While Azure Policy can remediate non-compliant resources using the 'modify' effect or via deployment tasks, this is not automatic for all policies; many policies rely on 'audit' or 'deny' effects, which either log non-compliance or block creation but never correct existing resources. When remediation does occur, it requires an explicit remediation task to be created, which uses a managed identity and is executed as an asynchronous operation, not a transparent and universal automatic process.

Azure Site Recovery

Why wrong: Azure Site Recovery replicates Azure VMs to a secondary region for disaster recovery, enabling failover and failback to meet recovery time objectives (RTO) and recovery point objectives (RPO). It continuously replicates ongoing changes and maintains a running replica, but it does not keep multiple point-in-time snapshots or allow granular file-level recovery from an arbitrary past date. Consequently, ASR is not a backup service; it is designed to keep the workload available during a regional outage, not to restore corrupted or accidentally deleted data.

Azure Policy

Why wrong: Azure Policy is a governance and compliance service that enforces rules using effects like Deny, Audit, or DeployIfNotExists to evaluate resource properties. It cannot create recovery points, copy data, or store backups; it only ensures resources comply with organizational standards, such as requiring a backup policy to be configured. Therefore, it is not a backup strategy, though it may be used to audit or automate the deployment of actual backup solutions.

Create a manual inventory of all servers and use Azure Pricing Calculator to estimate costs.

Why wrong: A manual inventory relies on spreadsheets and human data entry, which is error-prone and quickly outdated. More importantly, it captures only static specifications (vCPU, RAM, disk size) and omits utilization rates, performance counters, and application dependencies that determine appropriate Azure VM sizing. The Azure Pricing Calculator can price a manually specified VM, but it cannot discover or right-size the workload, so the resulting estimate is often inaccurate for a migration at scale.

Use Azure Advisor to analyze on-premises server usage and recommend Azure VM sizes.

Why wrong: Azure Advisor is a personalized cloud consultant that analyzes existing Azure subscriptions and resources to provide recommendations on high availability, security, performance, and cost. It cannot connect to or scan on-premises infrastructure, so it cannot discover server workloads or collect utilization metrics needed for migration sizing. At best, Advisor would only help after migration, not for assessing the source environment.

Use Azure Cost Management to estimate costs based on manual input of server specifications.

Why wrong: Azure Cost Management is a monitoring and governance tool for tracking spend on resources already running in Azure, offering budgets, alerts, and cost analysis. It has no discovery capability and no assessment logic to identify on-premises servers or infer their Azure VM equivalents. Manually entering specifications into Cost Management is not a supported workflow; that function belongs to Azure Migrate or the Azure Pricing Calculator, so this approach misses dependency mapping and rightsizing.

Azure Blob Storage Premium tier with geo-redundant storage (GRS)

Why wrong: Azure Blob Storage Premium is object-based storage, not a file share; it does not expose SMB protocol, which is typically needed for concurrent file-level access by media production applications. While geo-redundant storage (GRS) provides asynchronous replication to a secondary region for disaster recovery, it does not compensate for the lack of SMB support or the NFS limitations that preclude use as a drop-in share for legacy workflows. For industrial media creation, users expect access to drive-letter-mapped or UNC paths, which Blob Storage cannot natively deliver.

Azure Disk Storage with shared disks

Why wrong: Azure managed disks are block-level volumes attached to a single virtual machine; shared disks allow a modest number of VMs to attach the same disk using SCSI persistent reservations, but offer none of the file-level operations (SMB/NFS, directory enumeration, opportunistic locking) that a real file share requires. This design supports clustered applications like SQL Server failover cluster installations, not multi-user media editing where hundreds of users need a common namespace and per-file locking. As a storage solution for large media files, shared disks impose tight VM coupling and fail to provide a dedicated, network-accessible shared file system.

Azure NetApp Files Premium tier with cross-zone replication

Why wrong: Azure NetApp Files Premium tier is a powerful, enterprise-grade, multi-protocol file service with cross-zone replication, giving excellent performance and disaster resilience, but it is significantly more expensive and operationally complex than Azure Files Premium for this scenario. NetApp Files introduces capacity pools with a minimum 4 TiB commitment, professional administration of throughput, and more moving parts, while cross-zone replication adds continuous replication overhead. For a media company that simply needs a low-latency, SMB-accessible share with zone-level redundancy, Azure Files Premium ZRS delivers the same essential capabilities at a fraction of the cost and complexity.

The deployment succeeds with a warning logged.

Why wrong: When the Deny effect is triggered, Azure Policy injects a conflict error into the deployment response, so the result is a failed deployment, not a successful one with a warning. Azure Resource Manager doesn't have a 'succeeded with policy warning' outcome for a deny; any policy that blocks a required property is a hard failure. A warning could only appear in compliance reports or activity logs, never as the deployment status.

The VM is created but the SKU is changed to a different series.

Why wrong: Deny effect never alters the requested resource; it only rejects the request if the SKU doesn't match the allowed condition. The resource provider receives the original SKU value, and since the request is denied, there is no VM to resize or change. To automatically replace a denied SKU, you would need a separate Modify or DeployIfNotExists policy with a remediation task, which is not part of the Deny effect.

The deployment succeeds because the policy only audits.

Why wrong: The effect in the policy is Deny, not Audit, so the deployment is blocked, not merely flagged. AuditEffect records the resource as non-compliant after (or while) it is created, but DenyEffect prevents the resource from being created in the first place. The behavior the answer describes would only happen if the assignment had been built with the audit effect.

Use Azure Site Recovery to replicate the instance to another region

Why wrong: Azure Site Recovery orchestrates disaster recovery by replicating IaaS virtual machines, not Platform-as-a-Service data services. SQL Managed Instance is a PaaS offering with its own native high availability and geo-failover mechanisms, so ASR cannot capture its transaction logs or state. Attempting to use ASR would miss the instance's internal replica topology and would not provide a consistent, point-in-time recoverable copy.

Configure a readable secondary replica in the same region

Why wrong: A readable secondary replica in the same region addresses read-scale scenarios inside the same availability zone, but it does not protect against region-wide outages. For SQL Managed Instance, readable secondaries are not a manually configured DR construct; geo failover is provided instead through a failover group with a secondary instance in another region. Placing the secondary in the same region violates the cross-region requirement for business continuity.

Enable long-term retention (LTR) for backups

Why wrong: Long-term retention (LTR) extends backup retention beyond the automated backup period (up to 10 years) to support regulatory or archival compliance, not failover or recovery-point objectives. While LTR backups can be restored, the restore process is not designed for fast, frequent recovery and does not provide automatic or manual failover. Using LTR in place of a failover group or automated PITR backups would actually increase RTO and cannot protect against the loss of recent transactions.

Configure long-term retention (LTR) backups with a retention of 35 days

Why wrong: Long-term retention (LTR) backups are intended to archive full backups for years (up to 10 years) to satisfy compliance or regulatory requirements, not to provide granular point-in-time restores. LTR stores separate weekly/monthly/yearly full backups that can only restore to the exact time each backup was taken, so a 35-day LTR policy would still not let you roll back to an arbitrary minute within the last 35 days—that is PITR's job.

Create a secondary database in the same region

Why wrong: Creating a secondary database in the same region is an availability and read-scaling mechanism: it maintains a live, transactionally consistent replica of the primary database through continuous replication. A secondary does not contain historical snapshots or log replay from 35 days ago; it only reflects the current state of the primary, so it cannot restore data to a prior point in time and does not extend or replace the PITR retention period.

Enable geo-replication with a readable secondary

Why wrong: Geo-replication with a readable secondary provides a continuously updated copy of the database in another region, primarily for disaster recovery and to offload read workloads. Because the secondary is updated asynchronously and represents the database's near-current state, it cannot be rewound to an arbitrary timestamp within the last 35 days; point-in-time recovery is only accomplished by PITR, which uses backup metadata and log files independent of any secondary's current data.

X.509 certificate-based authentication

Why wrong: X.509 certificate-based authentication is not natively supported by Azure Cosmos DB. The Cosmos DB REST API and SDKs do not accept client certificates as a credential for authenticating data-plane requests. Although Azure AD can use an X.509 certificate for a service principal in some scenarios, Cosmos DB itself does not offer a native certificate-authentication flow, so this is not a valid method for securing access.

Azure Storage account keys

Why wrong: Azure Storage account keys are designed specifically for Azure Storage services such as Blob, Queue, Table, and File storage. They are not usable for authentication against Azure Cosmos DB because Cosmos DB maintains its own account keys and supports Azure AD RBAC instead. Supplying a Storage account key to the Cosmos DB endpoint would be rejected because the two services use entirely different authentication mechanisms.

Shared access signatures (SAS)

Why wrong: Shared access signatures (SAS) are not supported for Azure Cosmos DB. SAS tokens are a delegated authorization mechanism specific to Azure Storage services such as blobs, files, queues, and tables. Cosmos DB does not accept SAS tokens; it only authenticates requests through its account keys or Azure AD RBAC tokens, so using a SAS is not a valid way to secure Cosmos DB access.

Assess, then Install DMA, then Fix issues, then Migrate and Monitor

Why wrong: This ordering fails because the Data Migration Assistant (DMA) must be installed on the source or a jump host before any assessment can execute; DMA is the engine that inventories the SQL Server, scans object metadata, and detects compatibility and feature-parity issues. Skipping directly to 'Assess' without installing the tool leaves no mechanism to actually run the scan, so the sequence cannot begin. While 'Fix issues' after 'Assess' is logically correct, the installation step must precede assessment, not follow it.

Install DMA, then Migrate and Monitor, then Assess, then Fix issues

Why wrong: Jumping straight from tool installation to 'Migrate and Monitor' bypasses the assessment phase, which is essential to surface breaking changes, deprecated features, and object-level incompatibilities that DMA would flag before any data movement. Attempting a migration without remediating those findings can cause schema-transfer failures, data loss, or invalid target objects, and monitoring a blind migration gives no opportunity to correct issues before they impact the cutover. Additionally, running 'Assess' and 'Fix issues' after the migration is operationally contradictory because the source has already been moved and any needed fixes would have to be applied to the live target under pressure.

Fix issues, then Install DMA, then Assess, then Migrate and Monitor

Why wrong: This sequence starts with 'Fix issues' before an assessment has been performed, which is logically impossible because no inventory of blockers has been generated to tell you what to fix. DMA's assessment is the sanctioned way to enumerate compatibility and feature-parity problems; attempting fixes without that baseline is guesswork and could unnecessarily alter the source database. Moreover, installing DMA after the fix step means you would still need to re-run the assessment to confirm your changes were sufficient, making the entire order redundant and unsafe.

Automation runbook

Why wrong: While an action group can include an Automation runbook as a notification/action to remediate issues, the runbook is not a component of the alerting pipeline itself. The alert rule fires and references the action group, which may invoke the runbook, but the runbook is optional and not required for alert generation or email notifications. Its absence does not prevent the metric alert from being created or firing.

Log Analytics workspace

Why wrong: Metrics collected by Azure Monitor are stored in the Azure Monitor Metrics database (a time-series store), not in Log Analytics (which stores log data). Metric alerts can query these metrics directly without any Log Analytics dependency. Log Analytics is used for log-based alerts or for queries against log data, so it's not relevant for a standard metric alert rule.

Diagnostic setting

Why wrong: Diagnostic settings control the export of platform metrics and logs to destinations like storage, Event Hubs, or Log Analytics. They are not required for a metric alert rule to evaluate metrics already collected by Azure Monitor's platform metric collection. The alert rule reads from the platform metric store; diagnostic settings are only needed if you want to route those metrics elsewhere for retention or additional analytics.

The storage account uses GRS, which replicates data only to a secondary region within the same geography, not to a different region

Why wrong: This statement is incorrect because GRS does replicate to a different Azure region—specifically the paired secondary region within the same geography (e.g., East US to West US, or North Europe to West Europe). The option confuses 'same geography' with 'same region'; GRS always copies data asynchronously to a separate secondary region, not just to another datacenter within the primary region. So the claimed flaw (only replicating within the same geography, not another region) is false, as the paired secondary is a distinctly different region. Therefore this is not a valid reason to fail the failover requirement.

The storage account only supports HTTPS traffic, which blocks replication

Why wrong: This is wrong because the 'HTTPS only' setting (secure transfer required) on a storage account governs client-facing API calls over the public endpoint; it has no impact on Azure's internal replication plane. Replication between the primary and secondary region is performed by Azure's storage backend over its own private, secure network, independent of the account's secure-transfer configuration. Even with HTTPS enforced, data is still asynchronously replicated to the secondary region for GRS/RA-GRS. Therefore, the secure transfer setting cannot block or prevent replication, so this option does not explain the RTO issue.

The storage account is configured with the Hot access tier, which prevents failover

Why wrong: This is incorrect because the Hot access tier is a blob-level or account-level pricing/performance tier (Hot/Cool/Cold) that affects storage costs and access latency, not the replication or failover capability of the storage account. Account failover is governed by the replication type (GRS/RA-GRS or GZRS/RA-GZRS) and account kind, not by which access tier is configured. Hot-tier storage accounts with GRS still support the same manual failover behavior and same RTO constraints as Cool-tier accounts. Consequently, the access tier has no effect on whether failover is possible or how long it takes, making this option invalid.

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.