Select Two (Multi-Select) Questions

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.

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.

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.

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.

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.

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 Application Gateway with WAF

Why wrong: Application Gateway is for L7, not for encrypting VM-to-VM traffic.

Use Azure Front Door

Why wrong: Azure Front Door is for global web delivery.

Use VNet peering to connect the tiers

Why wrong: VNet peering does not provide encryption.

Azure App Service

Why wrong: Azure App Service is a fully managed platform-as-a-service (PaaS) offering designed for hosting web applications, REST APIs, and mobile backends. It cannot discover, assess, or replicate on-premises virtual machines, nor does it perform any physical or logical data transfer for VM migration. Attempting to use it would require re-architecting each workload into a web app, which is a code-level modernization effort, not a migration path. Therefore, it does not satisfy the requirement to migrate on-premises VMs to Azure.

Azure Import/Export Service

Why wrong: Azure Import/Export Service transfers data via physical hard drives shipped to an Azure datacenter, which introduces days of latency and requires manual intervention, making it incapable of meeting the minimal-downtime requirement for live virtual machine migration. It is tempting because it efficiently handles large offline datasets, such as archival backups or bulk file uploads, where network bandwidth is limited and downtime is acceptable.

Microsoft Purview

Why wrong: Microsoft Purview is a data governance, risk, and compliance solution that focuses on data classification, sensitivity labels, data loss prevention, and audit, not on analyzing authentication risk or enforcing risk-based access decisions. Although it can ingest Entra ID audit logs and support eDiscovery or compliance investigations, it does not evaluate user risk or sign-in risk in real time, and it cannot block a compromised session based on identity risk signals.

Microsoft Defender XDR

Why wrong: Microsoft Defender XDR is an enterprise threat protection suite that ingests and correlates security telemetry across endpoints, email, cloud apps, and identity to help security operations teams detect, investigate, and respond to active incidents. While it can surface identity alerts for incident review, it does not perform the real-time risk score calculation or risk-level categorization that Entra ID Protection performs, and it is not designed to enforce access policies at the moment of sign-in. Its focus is on post-compromise detection and response, not on proactive risk-based access control.

Microsoft Intune

Why wrong: Microsoft Intune is a cloud-based mobile device management (MDM) and mobile application management (MAM) service that enforces device compliance, configuration profiles, and app protection policies, but it does not analyze identity-specific risk signals. Intune's device compliance status can be used as a condition in a Conditional Access policy, but Intune itself does not determine whether a user's account or sign-in is risky, nor does it generate user-risk scores. Therefore, it is not the tool for detecting risky users or sign-ins.

Enable read scale-out to distribute read queries to a secondary replica.

Why wrong: Read scale-out improves performance, not availability.

Use Azure Backup to copy database backups to another region.

Why wrong: Backup is for point-in-time restore, not HA.

Configure auto-failover groups with a secondary in another region.

Why wrong: This is a disaster recovery strategy, not high availability (HA). HA typically refers to within-region.

Azure DNS

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

Azure CDN

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

Azure Application Gateway

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

Block-level deduplication

Why wrong: Block-level deduplication is not natively supported by Azure Files. While Windows Server allows you to enable the Deduplication feature on a file server, Azure Files itself does not deduplicate identical blocks across files stored in a share. If you need deduplication, you must deploy a separate solution or use Windows Server's Data Deduplication on an on-premises server, not rely on Azure Files.

Support for iSCSI protocol

Why wrong: Azure Files does not support the iSCSI protocol; it offers file-level access exclusively through SMB and NFS. iSCSI is a block-level storage protocol typically used for raw volumes and not supported by Azure file share endpoints. Consequently, applications that require iSCSI targets cannot be directly migrated to native Azure Files and would need Azure Managed Disks or other block-storage options instead.

Automatic tiering of data to archive storage

Why wrong: Automatic tiering to archive storage is a feature of Azure Blob Storage lifecycle management, not Azure Files. Azure Files provides hot and cool access tiers, but there is no native archive tier for file shares; archiving to slow, infrequent-access storage is not available within the Azure Files service. Azure File Sync's cloud tiering does move files asynchronously to Azure, but it does not place them in Blob's Archive tier.

VMs must use unmanaged disks

Why wrong: Azure Site Recovery for Azure VMs only replicates VMs that use Azure managed disks. Unmanaged disks, which rely on storage account page blobs, are a legacy configuration and unsupported for ASR replication. If your VM uses unmanaged disks, you would need to migrate it to managed disks before enabling replication.

VMs must be connected to a virtual network that has a VPN gateway to the target region

Why wrong: Azure-to-Azure replication does not require a VPN gateway, ExpressRoute, or any site-to-site connectivity between source and target regions. Replication traffic flows securely over the Azure backbone from the source VM's regional endpoint to the target recovery region. You only need network connectivity to Azure public endpoints for the Mobility extension, and outbound access rules are usually sufficient.

VMs must be at least Standard_D2s_v3 size

Why wrong: There is no minimum VM size, such as Standard_D2s_v3, for Azure Site Recovery to protect an Azure VM. ASR supports any VM size that runs a supported operating system and uses managed disks, down to smaller tiers like Standard_B1s or Standard_A1_v2. Size constraints only appear on the target side if you choose a lower-tier instance than the source.

Azure Service Health

Why wrong: Azure Service Health is a global service that reports on the status of Azure infrastructure and services, including regional outages, planned maintenance, and health advisories. It is designed to help you track Azure platform health, not the health or performance of your own application. For application-level metrics, logs, and anomaly detection, you need a telemetry solution like Application Insights, which instruments your code rather than the Azure platform.

Azure Security Center

Why wrong: Azure Security Center (now Microsoft Defender for Cloud) is a security management and threat-protection service that assesses vulnerabilities, enforces security policies, and generates security recommendations across hybrid cloud workloads. It monitors for security misconfigurations and suspicious activity, but it does not provide application performance metrics, custom telemetry, or operational analytics. Therefore, it is not appropriate for monitoring application health and performance.

Azure Log Analytics

Why wrong: Azure Log Analytics is not a standalone service but rather the workspace and query environment within Azure Monitor where log data is stored and searched using the Kusto Query Language (KQL). It allows you to aggregate, correlate, and visualize logs from multiple sources, but it requires you to send data to an Application Insights or Azure Monitor resource first. It cannot independently collect application telemetry or perform anomaly detection, so it is not a complete monitoring solution by itself.

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

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

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

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

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

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

DNS

Why wrong: The DNS connector is specifically designed to ingest DNS query and response logs from Windows DNS servers, not generic firewall traffic or security logs. Firewalls typically generate connection, policy, and threat logs that have no DNS-specific schema, so this connector would not capture or parse the relevant data for security monitoring.

Azure Activity Log

Why wrong: The Azure Activity Log captures subscription-level events known as the control plane, such as creating or deleting Azure resources through Azure Resource Manager. It does not integrate with on-premises infrastructure or network firewalls, and it cannot receive logs from non-Azure devices, so it is entirely unsuitable for third-party firewall log ingestion.

Windows Security Events via AMA

Why wrong: The Windows Security Events connector via Azure Monitor Agent (AMA) collects security audit events from the Windows Event Log on Windows servers and clients, such as logon attempts and process creation. It does not gather network traffic or firewall log data, and network firewalls are separate appliances that do not emit Windows event logs, so this connector cannot be used for that purpose.

Azure Backup

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

Azure Front Door

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

Use Azure Traffic Manager to route traffic to the primary region.

Why wrong: Azure Traffic Manager routes traffic by publishing DNS responses that resolve to the IP addresses of the primary region’s AKS endpoint; when it detects a failure, it changes DNS responses, but the actual failover time is governed by DNS TTLs and client DNS caching, which can take minutes and is not guaranteed. It also performs endpoint health checks only at the level of a monitored endpoint (typically the domain/IP), not by probing application-specific HTTP behavior or AKS ingress health. This makes it less suitable than Azure Front Door for fast, application-aware failover of Kubernetes workloads.

Use Azure SQL Database with failover groups for the database tier.

Why wrong: Azure SQL Database failover groups use an active-passive model in which only the primary database accepts writes, while the secondary database is a readable but non-writable replica located in another region. In an unplanned outage, the failover group must promote the secondary, and because replication is asynchronous, any transactions committed to the old primary but not yet replicated can be lost, violating strict RPO or zero-data-loss goals. This is why a failover group cannot replace an active-active database like Cosmos DB with multiple write regions in a global multi-region write scenario.