High Availability practice questions

A media company is designing a storage solution for its large video files (average 50 GB each) that are edited by multiple users simultaneously. The solution must support SMB protocol for compatibility with existing editing software and provide low-latency access. The files must be stored in a highly available configuration across multiple availability zones in a single region. Which Azure storage solution should the company recommend?

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

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.

Trap 2: Azure Disk Storage with shared disks

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.

Trap 3: Azure NetApp Files Premium tier with cross-zone replication

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.

A
Azure Files Premium tier with zone-redundant storage (ZRS)
Azure Files Premium tier provides fully managed SMB and NFS file shares backed by SSD storage, delivering the low-latency I/O required for media workloads. Zone-redundant storage (ZRS) synchronously replicates data across three Azure availability zones within a region, ensuring high availability and resilience to zone failures without the cost of geo-replication. This combination offers native file sharing, strong performance, and simple integration, making it the most appropriate choice for a media company's scalable, low-latency storage.
B
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.
C
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.
D
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.

Question 2mediummulti select

Your company is designing a hybrid network architecture that connects multiple on-premises sites to Azure. You need to ensure high availability and redundancy for the connection. Which TWO solutions should you recommend? (Choose two.)

Trap 1: Implement Azure DNS Private Resolver for resolution

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.

Trap 2: Use a single VPN gateway with active-standby mode

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.

Trap 3: Use a single ExpressRoute circuit with a VPN gateway as failover

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.

A
Deploy two ExpressRoute circuits in active-passive mode
Deploying two ExpressRoute circuits in active-passive mode is correct because each circuit represents a physically distinct path, ideally from different providers and peering locations, to Microsoft's edge, eliminating a single point of failure in the private network. BGP determines the primary path through route preference mechanisms such as local preference or AS path prepend, and on failure the secondary circuit automatically takes over without any configuration change. This architecture satisfies a high-availability hybrid networking requirement and enables the ExpressRoute service-level agreement.
B
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.
C
Use Azure VPN Gateway in active-active mode
Using an Azure VPN Gateway in active-active mode is also a valid redundancy design because Azure deploys two gateway instances, each with its own public IP and a separate IPsec tunnel to the on-premises VPN device, with BGP load-balancing or failing over between the tunnels. This protects against an instance-level failure and can be paired with ExpressRoute as a failover path. However, it uses internet-based VPN connectivity, so it cannot match the dedicated throughput and 99.95% SLA of two ExpressRoute circuits.
D
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.
E
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.

Question 3mediummultiple choice

A company wants to deploy a web application on Azure virtual machines (VMs). The application experiences variable traffic patterns, so the company needs to automatically add or remove VM instances based on CPU utilization. They also want the application to remain highly available even if an Azure datacenter fails. Which combination of Azure services should they use?

Trap 1: Azure App Service with autoscale rules and deployment slots

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.

Trap 2: Azure Load Balancer with a backend pool of VMs and autoscale rules…

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.

Trap 3: Azure Traffic Manager with endpoints in separate regions and Manual…

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.

A
Virtual Machine Scale Sets configured with autoscale rules based on CPU and distributed across availability zones
Virtual Machine Scale Sets are the only compute option listed that runs your workload on IaaS VMs while natively supporting horizontal autoscale: you define a scale condition (e.g., scale out by one instance when CPU percentage exceeds 75%, scale in when below 25%) and Azure applies it to the entire set. Deploying the VMSS across multiple availability zones places instance replicas in physically separate datacenters within the region, so a zone outage does not take down the entire web tier. This combination directly satisfies both the CPU-based automatic scaling and the zone-failure protection requirement.
B
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.
C
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.
D
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.

Question 4mediummultiple choice

A media company stores large video files that are accessed once a month for audits. When needed, they must be available for download immediately (within seconds). The company wants to minimize storage costs. Which Azure Blob Storage access tier should they use?

Trap 1: Hot tier

Hot tier is designed for frequently accessed data and carries the highest per-GB storage price, with no early-deletion penalty but premium capacity costs. Since the video files are touched only once each month, you would be provisioning high-cost storage for long idle periods, making it economically unjustified. The access latency is identical to Cool tier, so you gain no operational benefit that compensates for the extra storage expense.

Trap 2: Cold tier

Cold tier lowers the base storage cost but imposes a higher per-GB retrieval fee and a mandatory 90-day retention period, which does not match a 30-day access cadence. Over the course of a year, the cumulative retrieval charges for twelve monthly reads can quickly erase the storage savings relative to Cool tier. Additionally, the 90-day minimum means you would either pay early-deletion fees or keep data longer than the business needs, further increasing cost.

Trap 3: Archive tier

Archive tier is the least expensive for static data, but it stores blobs in an offline state that requires manual rehydration to a readable tier, a process that can take up to 15 hours. For a media company that must access a video every month, this delay is operationally unacceptable, and rehydration also incurs additional read and write costs. Even if you schedule the rehydration in advance, the complexity and unpredictability make Archive unsuitable for a predictable 30-day access pattern.

A
Hot tier
Why wrong: Hot tier is designed for frequently accessed data and carries the highest per-GB storage price, with no early-deletion penalty but premium capacity costs. Since the video files are touched only once each month, you would be provisioning high-cost storage for long idle periods, making it economically unjustified. The access latency is identical to Cool tier, so you gain no operational benefit that compensates for the extra storage expense.
B
Cool tier
Cool tier offers a low per-GB storage price with a modest per-GB retrieval fee and a 30-day minimum retention period, which aligns perfectly with monthly access. Retrieval is immediate because objects remain in the online tier, so the media company can read or stream the video without waiting for rehydration. For large files read once per month, Cool delivers the lowest total cost among tiers that still provide on-demand access, making it the correct choice.
C
Cold tier
Why wrong: Cold tier lowers the base storage cost but imposes a higher per-GB retrieval fee and a mandatory 90-day retention period, which does not match a 30-day access cadence. Over the course of a year, the cumulative retrieval charges for twelve monthly reads can quickly erase the storage savings relative to Cool tier. Additionally, the 90-day minimum means you would either pay early-deletion fees or keep data longer than the business needs, further increasing cost.
D
Archive tier
Why wrong: Archive tier is the least expensive for static data, but it stores blobs in an offline state that requires manual rehydration to a readable tier, a process that can take up to 15 hours. For a media company that must access a video every month, this delay is operationally unacceptable, and rehydration also incurs additional read and write costs. Even if you schedule the rehydration in advance, the complexity and unpredictability make Archive unsuitable for a predictable 30-day access pattern.

Review the full routing breakdown →

Question 5hardmultiple choice

A global e-commerce company deploys its web application on Azure Kubernetes Service (AKS) clusters in multiple Azure regions. They need a single global endpoint for users, with SSL offloading, web application firewall (WAF) protection, and URL path-based routing to the nearest healthy AKS cluster. Which Azure service should they use?

Trap 1: Azure Traffic Manager

Traffic Manager is a DNS-based traffic router that only resolves domain names to endpoint IPs at the DNS level. It cannot terminate SSL, inspect HTTP content, or apply WAF rules, and it lacks URL path-based routing because it never sees the actual traffic. While it can route users globally, it cannot make application-layer decisions or protect the application, so it does not meet the full requirements.

Trap 2: Azure Application Gateway

Application Gateway is a regional Layer 7 load balancer that provides SSL offloading, WAF, and URL path-based routing, but its scope is limited to a single Azure region. It can route traffic among backends within that region but cannot distribute or intelligently route users across multiple geographic regions. For global e-commerce scale and redundancy, you need a multi-region front-end, which Application Gateway alone cannot provide.

Trap 3: Azure Load Balancer

Azure Load Balancer is a Layer 4 network load balancer that forwards TCP/UDP traffic without any awareness of HTTP content. It does not perform SSL termination, cannot inspect URLs for path-based routing, and does not integrate a WAF. Additionally, it is a regional service, so it lacks the global anycast-based edge routing that Front Door offers for worldwide traffic distribution.

A
Azure Front Door
Azure Front Door is correct because it operates at Layer 7 as a global entry point using Microsoft's edge network. It supports SSL offloading, web application firewall (WAF), and URL path-based routing, and it uses anycast to route users to the nearest healthy backend based on global health probes. This uniquely combines global distribution with HTTP-layer intelligence and security, making it ideal for a globally distributed e-commerce web application.
B
Azure Traffic Manager
Why wrong: Traffic Manager is a DNS-based traffic router that only resolves domain names to endpoint IPs at the DNS level. It cannot terminate SSL, inspect HTTP content, or apply WAF rules, and it lacks URL path-based routing because it never sees the actual traffic. While it can route users globally, it cannot make application-layer decisions or protect the application, so it does not meet the full requirements.
C
Azure Application Gateway
Why wrong: Application Gateway is a regional Layer 7 load balancer that provides SSL offloading, WAF, and URL path-based routing, but its scope is limited to a single Azure region. It can route traffic among backends within that region but cannot distribute or intelligently route users across multiple geographic regions. For global e-commerce scale and redundancy, you need a multi-region front-end, which Application Gateway alone cannot provide.
D
Azure Load Balancer
Why wrong: Azure Load Balancer is a Layer 4 network load balancer that forwards TCP/UDP traffic without any awareness of HTTP content. It does not perform SSL termination, cannot inspect URLs for path-based routing, and does not integrate a WAF. Additionally, it is a regional service, so it lacks the global anycast-based edge routing that Front Door offers for worldwide traffic distribution.

Review the full routing breakdown →

Question 6mediummultiple choice

A global e-commerce company runs a web application in multiple Azure regions. They need to distribute incoming HTTPS traffic across regional deployments to provide low latency and high availability. The solution must support SSL offloading, Web Application Firewall (WAF) policies, and content caching to reduce backend load. They also need to route users to the nearest healthy backend region. Which Azure service should they use?

Trap 1: Azure Traffic Manager

Azure Traffic Manager operates strictly at the DNS layer, resolving public domain names to endpoints and directing clients based on routing methods such as performance, priority, or geographic proximity. Because it never sees the actual HTTP/S traffic, it cannot provide TLS termination, web application firewall (WAF) inspection, path-based routing, or content caching at the edge. For a web application that requires SSL offloading and WAF protection, Traffic Manager is only a DNS-level traffic distribution mechanism and lacks the layer 7 security and acceleration features needed.

Trap 2: Azure Application Gateway

Azure Application Gateway is a regional-only layer 7 load balancer, meaning it can handle TLS termination, WAF rules, and path/URL routing, but only for backends within a single Azure region or availability zone. It is not a global service, so a multi-region deployment would need one Application Gateway per region and still require a separate DNS-level mechanism or another global router to steer users to the correct regional gateway. While it offers similar security features to Front Door, it lacks the built-in global edge caching, anycast networking, and cross-region health-based routing that a worldwide e-commerce platform demands.

Trap 3: Azure Content Delivery Network (CDN)

Azure CDN is optimized primarily for caching and delivering static content from edge locations to reduce latency and origin load, but it does not function as a layer 7 load balancer with real-time backend health awareness. A standard Azure CDN profile does not natively provide web application firewall (WAF) inspection for every request, nor does it perform per-request routing decisions to the nearest healthy origin based on continuous health probes in the way Front Door does. Although it can improve delivery of images and video, it cannot address the need for SSL offloading to origins, WAF protection, and intelligent failover routing across multiple regions.

A
Azure Traffic Manager
Why wrong: Azure Traffic Manager operates strictly at the DNS layer, resolving public domain names to endpoints and directing clients based on routing methods such as performance, priority, or geographic proximity. Because it never sees the actual HTTP/S traffic, it cannot provide TLS termination, web application firewall (WAF) inspection, path-based routing, or content caching at the edge. For a web application that requires SSL offloading and WAF protection, Traffic Manager is only a DNS-level traffic distribution mechanism and lacks the layer 7 security and acceleration features needed.
B
Azure Front Door
Azure Front Door is the correct choice because it is a true global layer 7 load balancer that terminates TLS at its edge points of presence, offloading encryption processing from the origin web servers. It includes an integrated web application firewall (WAF) capable of inspecting requests before they reach backend applications, and it offers edge caching for static and dynamic content. Additionally, Front Door uses Anycast and intelligent routing to direct each user's request to the nearest available and healthy regional backend, providing automatic global failover and path-based routing that satisfy all requirements of a multi-region e-commerce deployment.
C
Azure Application Gateway
Why wrong: Azure Application Gateway is a regional-only layer 7 load balancer, meaning it can handle TLS termination, WAF rules, and path/URL routing, but only for backends within a single Azure region or availability zone. It is not a global service, so a multi-region deployment would need one Application Gateway per region and still require a separate DNS-level mechanism or another global router to steer users to the correct regional gateway. While it offers similar security features to Front Door, it lacks the built-in global edge caching, anycast networking, and cross-region health-based routing that a worldwide e-commerce platform demands.
D
Azure Content Delivery Network (CDN)
Why wrong: Azure CDN is optimized primarily for caching and delivering static content from edge locations to reduce latency and origin load, but it does not function as a layer 7 load balancer with real-time backend health awareness. A standard Azure CDN profile does not natively provide web application firewall (WAF) inspection for every request, nor does it perform per-request routing decisions to the nearest healthy origin based on continuous health probes in the way Front Door does. Although it can improve delivery of images and video, it cannot address the need for SSL offloading to origins, WAF protection, and intelligent failover routing across multiple regions.

Question 7mediummulti select

Which TWO of the following are valid strategies for achieving high availability for Azure SQL Database?

Trap 1: Enable read scale-out to distribute read queries to a secondary…

Read scale-out improves performance, not availability.

Trap 2: Use Azure Backup to copy database backups to another region.

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

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

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

A
Deploy Azure SQL Database in a zone-redundant configuration within a single region.
Zone-redundant configuration replicates across availability zones for HA.
B
Enable read scale-out to distribute read queries to a secondary replica.
Why wrong: Read scale-out improves performance, not availability.
C
Enable active geo-replication with a readable secondary in the same region.
Active geo-replication within the same region provides HA with synchronous replication.
D
Use Azure Backup to copy database backups to another region.
Why wrong: Backup is for point-in-time restore, not HA.
E
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.

Question 8hardmultiple choice

You are designing a high-availability solution for a stateful application that uses Azure NetApp Files (ANF) for persistent storage. The application must withstand a zonal failure within a region. What should you do?

Trap 1: Use Azure Files with zone-redundant storage (ZRS) and SMB…

Azure Files is a distinct managed file offering, not a substitute for Azure NetApp Files (ANF). While ZRS on Azure Files replicates data synchronously across availability zones, SMB multi-channel is only a performance feature that improves throughput by using multiple SMB connections, it does nothing for availability. This option fails the stated requirement to use ANF and ignores that ANF itself does not support zone-redundant storage; it would require re-architecting to a different file protocol and feature set.

Trap 2: Use Azure Backup for ANF with daily snapshots stored in a different…

Azure Backup for ANF takes point-in-time snapshots and stores recovery points, but a backup is not an active replica: it has to be restored to a new volume before application traffic can resume, which yields a high RTO. Daily snapshots also create a maximum data loss window of up to 24 hours, which is generally unacceptable for high availability. Storing the backup in a different zone only protects the backup artifacts themselves; it never provides automatic failover, continuous replication, or instant read access from a secondary zone.

Trap 3: Deploy the application in an Availability Set and use ANF volumes…

An Availability Set spreads VMs across fault domains and update domains within a single availability zone, so it protects only against rack-level or maintenance events, not a full availability zone outage. Additionally, Azure NetApp Files does not support zone-redundant storage (ZRS); ANF volumes are provisioned in a single availability zone and use locally redundant storage (LRS) by default. Pairing an Availability Set with an unbacked ANF volume still leaves the file data vulnerable, so this combination does not deliver zonal high availability.

A
Use Azure Files with zone-redundant storage (ZRS) and SMB multi-channel.
Why wrong: Azure Files is a distinct managed file offering, not a substitute for Azure NetApp Files (ANF). While ZRS on Azure Files replicates data synchronously across availability zones, SMB multi-channel is only a performance feature that improves throughput by using multiple SMB connections, it does nothing for availability. This option fails the stated requirement to use ANF and ignores that ANF itself does not support zone-redundant storage; it would require re-architecting to a different file protocol and feature set.
B
Use Azure NetApp Files cross-zone replication to replicate data between availability zones.
Azure NetApp Files cross-zone replication continuously asynchronously replicates volume data from a primary ANF volume in one availability zone to a secondary volume in another zone, using NetApp SnapMirror technology. If the primary zone fails, you can mount the destination volume in the secondary zone, providing a much lower RTO than backup and true zonal resilience. This directly meets the high-availability requirement while staying within the ANF service, and the RPO is typically in the range of a few minutes.
C
Use Azure Backup for ANF with daily snapshots stored in a different zone.
Why wrong: Azure Backup for ANF takes point-in-time snapshots and stores recovery points, but a backup is not an active replica: it has to be restored to a new volume before application traffic can resume, which yields a high RTO. Daily snapshots also create a maximum data loss window of up to 24 hours, which is generally unacceptable for high availability. Storing the backup in a different zone only protects the backup artifacts themselves; it never provides automatic failover, continuous replication, or instant read access from a secondary zone.
D
Deploy the application in an Availability Set and use ANF volumes with zone-redundant storage (ZRS).
Why wrong: An Availability Set spreads VMs across fault domains and update domains within a single availability zone, so it protects only against rack-level or maintenance events, not a full availability zone outage. Additionally, Azure NetApp Files does not support zone-redundant storage (ZRS); ANF volumes are provisioned in a single availability zone and use locally redundant storage (LRS) by default. Pairing an Availability Set with an unbacked ANF volume still leaves the file data vulnerable, so this combination does not deliver zonal high availability.

Question 9hardmulti select

You are designing a business continuity solution for a global SaaS application that runs on Azure Kubernetes Service (AKS) with Azure Cosmos DB as the database. The solution must support multi-region writes and automatic failover with zero data loss. Which THREE components should you include in your design? (Choose three.)

Trap 1: Use Azure Traffic Manager to route traffic to the primary region.

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.

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

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.

A
Deploy Azure Cache for Redis Enterprise with active geo-replication.
Azure Cache for Redis Enterprise uses active geo-replication to create a global cache cluster spanning two or more regions, where every participating cache accepts both reads and writes and synchronizes asynchronously with built-in conflict resolution. If a regional data center fails, the remaining cache automatically continues serving traffic without a manual failover step, preserving cache availability and reducing impact to application sessions. This makes it a true active-active cache tier rather than a passive replica, which is why it is correct for a global business continuity design.
B
Deploy Azure Front Door with origin groups for the AKS clusters.
Azure Front Door with origin groups places each AKS cluster behind a single global HTTP(S) endpoint and uses layer-7 health probes to detect whether a regional ingress or backend is healthy. When a primary AKS cluster degrades or fails, Front Door automatically shifts client traffic to the next healthy origin in the group, usually within seconds and without relying on DNS TTL propagation. Because it understands application-level signals and supports features such as host/path routing and session affinity, it is the appropriate traffic-routing layer for AKS-based global deployments.
C
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.
D
Configure Azure Cosmos DB with multiple write regions.
Configuring Azure Cosmos DB for multiple write regions creates an active-active database where every regional replica can accept insert, update, and delete operations, and changes propagate to other regions using the chosen consistency and conflict resolution policies. Because the application can continue writing to any remaining region without a database endpoint promotion, it achieves effectively zero data loss and near-zero recovery time at the data tier for committed writes. This directly supports the need for global write availability, though you must configure conflict resolution (like LWW) to reconcile concurrent changes.
E
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.

Question 10easymultiple choice

A company deploys a stateless web application on Azure VMs in a single region. They need to distribute incoming HTTP traffic across multiple VMs and perform health checks. The solution should be highly available within the region. Which Azure load balancing solution should they use?

Trap 1: Azure Application Gateway v2.

Azure Application Gateway v2 is a Layer 7 load balancer featuring SSL termination, URL path-based routing, and cookie-based session affinity. Those capabilities are extraneous for a stateless HTTP workload that simply needs to distribute raw TCP connections across VMs. It also adds operational complexity and higher per-hour cost than a Standard Load Balancer because it runs a dedicated gateway tier. Therefore it is not the recommended regional HA solution here.

Trap 2: Azure Traffic Manager.

Azure Traffic Manager is a DNS-based traffic router that maps domain names to endpoints across different Azure regions, such as scale sets or regional load balancers. It decides which endpoint receives traffic based on DNS resolution using routing methods like priority or performance, but it does not load-balance individual TCP/HTTP connections within a region. Its health checks are coarse endpoint-level probes, not VM-level or port-level monitoring, and it cannot replace a regional load balancer to keep VMs available within one region.

Trap 3: Azure Front Door.

Azure Front Door is a global HTTP(S) delivery and protection service that accelerates requests through Microsoft's edge network by routing to the closest healthy origin. It operates at the DNS/anycast level with features like caching, SSL offload, and WAF policies, all of which are excessive for a single-region stateless web app. Equally important, it does not perform L4 load balancing inside a region; it expects an origin load balancer to handle that. For a deployment that only needs regional high availability, Front Door adds extra latency and cost without tangible benefit.

A
Azure Load Balancer (Standard) with HTTP health probe.
The Standard Load Balancer is a regional Layer 4 load balancer that distributes TCP/UDP traffic across backend VM instances. Its HTTP health probe periodically sends HTTP GET requests to the configured path and removes any VM that does not return a 2xx status, enabling automatic failover. Being zone-redundant, it provides high availability within a region, and because the app is stateless, no session persistence or Layer 7 routing is needed. This makes it the simplest, most cost-effective choice.
B
Azure Application Gateway v2.
Why wrong: Azure Application Gateway v2 is a Layer 7 load balancer featuring SSL termination, URL path-based routing, and cookie-based session affinity. Those capabilities are extraneous for a stateless HTTP workload that simply needs to distribute raw TCP connections across VMs. It also adds operational complexity and higher per-hour cost than a Standard Load Balancer because it runs a dedicated gateway tier. Therefore it is not the recommended regional HA solution here.
C
Azure Traffic Manager.
Why wrong: Azure Traffic Manager is a DNS-based traffic router that maps domain names to endpoints across different Azure regions, such as scale sets or regional load balancers. It decides which endpoint receives traffic based on DNS resolution using routing methods like priority or performance, but it does not load-balance individual TCP/HTTP connections within a region. Its health checks are coarse endpoint-level probes, not VM-level or port-level monitoring, and it cannot replace a regional load balancer to keep VMs available within one region.
D
Azure Front Door.
Why wrong: Azure Front Door is a global HTTP(S) delivery and protection service that accelerates requests through Microsoft's edge network by routing to the closest healthy origin. It operates at the DNS/anycast level with features like caching, SSL offload, and WAF policies, all of which are excessive for a single-region stateless web app. Equally important, it does not perform L4 load balancing inside a region; it expects an origin load balancer to handle that. For a deployment that only needs regional high availability, Front Door adds extra latency and cost without tangible benefit.

Review the full routing breakdown →

Question 11mediummultiple choice

A company is designing a hybrid network solution connecting an on-premises data center to Azure. They require high availability with active-active routing and need to support up to 10 Gbps throughput. Which Azure service should they include in the design?

Trap 1: Site-to-Site VPN Gateway

Site-to-Site VPN Gateway establishes IPsec tunnels over the public internet, and the commonly deployed SKUs (e.g., VpnGw3) offer only up to 1.25 Gbps aggregate throughput. Additionally, the standard configuration is active-passive, meaning only one tunnel carries traffic at a time; while active-active is possible, the solution still depends on internet-based connectivity and does not provide the dedicated 10 Gbps private bandwidth required.

Trap 2: Azure Virtual WAN

Incorrect. Azure Virtual WAN aggregates multiple connection types but does not itself provide dedicated 10 Gbps throughput; it is a networking service that can use ExpressRoute or VPN, but not a standalone solution for the specified requirements.

Trap 3: ExpressRoute FastPath

Incorrect. ExpressRoute FastPath is a feature that improves performance by bypassing the gateway, but it is not a standalone service. It requires an ExpressRoute circuit and does not inherently provide active-active routing or guarantee 10 Gbps throughput. The question asks for a service, not a feature.

A
Site-to-Site VPN Gateway
Why wrong: Site-to-Site VPN Gateway establishes IPsec tunnels over the public internet, and the commonly deployed SKUs (e.g., VpnGw3) offer only up to 1.25 Gbps aggregate throughput. Additionally, the standard configuration is active-passive, meaning only one tunnel carries traffic at a time; while active-active is possible, the solution still depends on internet-based connectivity and does not provide the dedicated 10 Gbps private bandwidth required.
B
Azure Virtual WAN
Why wrong: Incorrect. Azure Virtual WAN aggregates multiple connection types but does not itself provide dedicated 10 Gbps throughput; it is a networking service that can use ExpressRoute or VPN, but not a standalone solution for the specified requirements.
C
ExpressRoute FastPath
Why wrong: Incorrect. ExpressRoute FastPath is a feature that improves performance by bypassing the gateway, but it is not a standalone service. It requires an ExpressRoute circuit and does not inherently provide active-active routing or guarantee 10 Gbps throughput. The question asks for a service, not a feature.
D
ExpressRoute Direct
ExpressRoute Direct provides a dedicated, private Layer-2 connection between your on-premises network and Microsoft's edge at a peering location, with port pairs available at 10 Gbps, 40 Gbps, or 100 Gbps. Since it delivers physical port-level bandwidth rather than a VPN gateway's aggregate limit, it easily satisfies the 10 Gbps throughput requirement. It also supports active-active routing by default through dual routers and BGP sessions, giving the required high availability with an SLA-backed redundant path.

Read the full DNS explanation →

Question 12mediummultiple choice

A company plans to deploy multiple virtual machines (VMs) across two Azure regions for high availability. The VMs will host a stateless web application that must be accessible via a single DNS endpoint. The solution must automatically route traffic to the nearest region with available capacity and provide failover if a region becomes unhealthy. Which Azure service should they use to meet these requirements?

Trap 1: Azure Front Door

Azure Front Door is tempting as it provides a single global DNS endpoint, automatically routes traffic to the nearest healthy region based on latency, and offers failover for high availability, which aligns with several requirements for a global web application. However, it fails to meet the specific requirement for routing traffic based on "available capacity". Front Door primarily uses latency-based routing and health probes, not dynamic load-based distribution across regions to account for current capacity constraints, which is a key distinction for this scenario.

Trap 2: Azure Load Balancer

Azure Load Balancer is a regional, layer-4 network load balancer that distributes traffic within a single Azure region and a single virtual network. It cannot route or redirect traffic across multiple regions because it has no DNS-based or global endpoint capability, and its health probes only monitor VMs in its own backend pool. Therefore, it fails to provide the cross-region capacity-based routing required for a multi-region VM deployment.

Trap 3: Azure Application Gateway

Azure Application Gateway operates at Layer 7 (HTTP/HTTPS) and is deployed within one region, providing SSL termination, path-based routing, and WAF capabilities for regional web traffic. While it can perform sophisticated request routing based on URL and host headers, it lacks a global DNS-based traffic management layer and cannot direct users to the nearest or most available regional deployment. Its backend pools are confined to a single region, so it cannot satisfy the requirement for routing across multiple regional VM deployments based on available capacity.

A
Azure Traffic Manager
Azure Traffic Manager is a DNS-based global load balancer that routes incoming DNS requests to the most appropriate regional endpoint based on routing methods such as performance, geographic, weighted, or priority. It continuously monitors endpoint health and can automatically redirect traffic away from failed or overloaded regions, ensuring high availability and capacity-aware distribution across multiple VMs in different regions.
B
Azure Front Door
Why wrong: Azure Front Door is tempting as it provides a single global DNS endpoint, automatically routes traffic to the nearest healthy region based on latency, and offers failover for high availability, which aligns with several requirements for a global web application. However, it fails to meet the specific requirement for routing traffic based on "available capacity". Front Door primarily uses latency-based routing and health probes, not dynamic load-based distribution across regions to account for current capacity constraints, which is a key distinction for this scenario.
C
Azure Load Balancer
Why wrong: Azure Load Balancer is a regional, layer-4 network load balancer that distributes traffic within a single Azure region and a single virtual network. It cannot route or redirect traffic across multiple regions because it has no DNS-based or global endpoint capability, and its health probes only monitor VMs in its own backend pool. Therefore, it fails to provide the cross-region capacity-based routing required for a multi-region VM deployment.
D
Azure Application Gateway
Why wrong: Azure Application Gateway operates at Layer 7 (HTTP/HTTPS) and is deployed within one region, providing SSL termination, path-based routing, and WAF capabilities for regional web traffic. While it can perform sophisticated request routing based on URL and host headers, it lacks a global DNS-based traffic management layer and cannot direct users to the nearest or most available regional deployment. Its backend pools are confined to a single region, so it cannot satisfy the requirement for routing across multiple regional VM deployments based on available capacity.

Question 13easymultiple choice

A startup is building a new mobile app backend. They need a fully managed relational database service with built-in high availability, automatic backups, and built-in intelligence to optimize performance. They want to minimize administrative overhead for tasks like patching and scaling. Which Azure service should they use?

Trap 1: SQL Server on Azure Virtual Machines

SQL Server on Azure Virtual Machines is a Infrastructure-as-a-Service offering where you retain full administrative control over the OS and SQL Server instance. This means you are responsible for installing SQL Server, applying monthly Windows and SQL Server patches, managing backups, configuring high availability through Always On Availability Groups, and monitoring performance. Because the scenario demands a fully managed service, the patching, backup, and HA management overhead on VMs directly violates that requirement and adds significant operational burden.

Trap 2: Azure Database for MySQL

Azure Database for MySQL is fully managed but is a different relational database engine, not SQL Server; the question does not specify engine but for a new mobile app backend, Azure SQL Database is commonly chosen.

Trap 3: Azure Cosmos DB

Azure Cosmos DB is a globally distributed, multi-model NoSQL database that supports document, key-value, graph, and column-family APIs. It is schema-agnostic and lacks true relational features such as SQL Server-style T-SQL, foreign key constraints, and expressive relational joins, which are typically required for a structured mobile app backend. The scenario implies a need for a fully managed relational database service rather than a NoSQL store, so Cosmos DB's non-relational data model makes it an incorrect fit.

A
Azure SQL Database
Azure SQL Database is the correct choice because it is a fully managed Platform-as-a-Service relational database that eliminates patching, backups, and high-availability configuration. Its built-in intelligent query optimization, automatic tuning, and geo-replication capabilities align directly with the requirement for a fully managed backend. You simply provision the logical server and database, and Azure handles infrastructure redundancy, automated backups with point-in-time restore, and a 99.99% SLA, freeing your team to focus on application development.
B
SQL Server on Azure Virtual Machines
Why wrong: SQL Server on Azure Virtual Machines is a Infrastructure-as-a-Service offering where you retain full administrative control over the OS and SQL Server instance. This means you are responsible for installing SQL Server, applying monthly Windows and SQL Server patches, managing backups, configuring high availability through Always On Availability Groups, and monitoring performance. Because the scenario demands a fully managed service, the patching, backup, and HA management overhead on VMs directly violates that requirement and adds significant operational burden.
C
Azure Database for MySQL
Why wrong: Azure Database for MySQL is fully managed but is a different relational database engine, not SQL Server; the question does not specify engine but for a new mobile app backend, Azure SQL Database is commonly chosen.
D
Azure Cosmos DB
Why wrong: Azure Cosmos DB is a globally distributed, multi-model NoSQL database that supports document, key-value, graph, and column-family APIs. It is schema-agnostic and lacks true relational features such as SQL Server-style T-SQL, foreign key constraints, and expressive relational joins, which are typically required for a structured mobile app backend. The scenario implies a need for a fully managed relational database service rather than a NoSQL store, so Cosmos DB's non-relational data model makes it an incorrect fit.

Question 14mediummultiple choice

A company needs a fully managed NoSQL database for a JSON document-oriented application that requires low latency (single-digit milliseconds) for reads and writes at any scale. The application will run globally and needs multi-region writes with automatic failover. Which Azure data store should they use?

Trap 1: Azure Table Storage

Azure Table Storage is a fully managed NoSQL key-value store, but it is not designed for native JSON documents or multi-region global distribution with automatic failover. Its data model is a flat collection of entities with typed properties, and although you can serialize JSON into a string property, you cannot natively index or query inside that JSON object. Additionally, scaling and replication require manual management, and failover is not automatic, making it unsuitable for a mission-critical global JSON database.

Trap 2: Azure SQL Database

Azure SQL Database is a relational database engine that stores data in normalized tables with enforced schemas, not as native, schema-free JSON documents. While it provides JSON functions and can store JSON in NVARCHAR columns, the JSON is not a first-class data type and any querying or indexing requires conversion or manual JSON paths. Because it is fundamentally relational and does not offer a document-native store with multi-region writes, it does not meet the NoSQL fully managed JSON database requirement.

Trap 3: Azure Cache for Redis

Azure Cache for Redis is an in-memory data store used primarily for caching, session state, and high-throughput temporary data, not a durable NoSQL database for primary JSON persistence. Although Redis can store JSON via modules or serialization, data in the cache is volatile by default and can be lost on node failures unless you implement complex persistence and replication, which still do not provide automatic database failover or elastic multi-region write support. Its core purpose is to reduce latency for read-heavy workloads, not to serve as a globally replicated, fully managed JSON database.

A
Azure Cosmos DB
Azure Cosmos DB is the correct choice because it is a fully managed, multi-model NoSQL database with native JSON document support, schema-agnostic indexing, and an SQL-like query engine. It uniquely delivers multi-region writes with automatic failover, elastic horizontal partitioning and tunable consistency, backed by an industry-leading SLA of 99.999% availability and single-digit millisecond read/write latency at the 99th percentile. These capabilities are purpose-built for globally distributed JSON workloads requiring both durability and low-latency access.
B
Azure Table Storage
Why wrong: Azure Table Storage is a fully managed NoSQL key-value store, but it is not designed for native JSON documents or multi-region global distribution with automatic failover. Its data model is a flat collection of entities with typed properties, and although you can serialize JSON into a string property, you cannot natively index or query inside that JSON object. Additionally, scaling and replication require manual management, and failover is not automatic, making it unsuitable for a mission-critical global JSON database.
C
Azure SQL Database
Why wrong: Azure SQL Database is a relational database engine that stores data in normalized tables with enforced schemas, not as native, schema-free JSON documents. While it provides JSON functions and can store JSON in NVARCHAR columns, the JSON is not a first-class data type and any querying or indexing requires conversion or manual JSON paths. Because it is fundamentally relational and does not offer a document-native store with multi-region writes, it does not meet the NoSQL fully managed JSON database requirement.
D
Azure Cache for Redis
Why wrong: Azure Cache for Redis is an in-memory data store used primarily for caching, session state, and high-throughput temporary data, not a durable NoSQL database for primary JSON persistence. Although Redis can store JSON via modules or serialization, data in the cache is volatile by default and can be lost on node failures unless you implement complex persistence and replication, which still do not provide automatic database failover or elastic multi-region write support. Its core purpose is to reduce latency for read-heavy workloads, not to serve as a globally replicated, fully managed JSON database.