Auto Scaling practice questions

A startup is building a web application that will be used by a small number of users initially but is expected to grow rapidly. The application runs on Linux and uses a PostgreSQL database. The company wants to minimize operational overhead and costs during the early stages. You need to recommend a platform as a service (PaaS) solution for both the application and the database. What should you recommend?

Trap 1: Deploy the application on Azure Kubernetes Service (AKS) and use…

AKS supplies a resilient Kubernetes control plane, but it imposes ongoing cluster lifecycle duties on the development team: managing node pools, patching the OS and kubelet, configuring ingress controllers, monitoring resource quotas, and upgrading Kubernetes versions. Even though Azure Database for PostgreSQL reduces database admin, the containerized app still must be built, configured, and operated as a workload on the cluster, which substantially exceeds the management overhead of a single App Service instance. This trade-off only pays off for larger microservice teams and custom infrastructure requirements, not for a startup's straightforward web application.

Trap 2: Deploy the application as Azure Functions and use Azure Cosmos DB…

Azure Functions is a serverless compute platform optimized for event-driven triggers and transient execution, with a maximum execution timeout and cold-start latency that make it unsuitable for consistent, stateful web request serving to users. Cosmos DB is a NoSQL, multi-model database, not a relational PostgreSQL source, so any existing SQL schema, joins, transactions, or object-relational mapping would require substantial redesign. The combination fails both the compute model and the relational storage expectations of a typical web application.

Trap 3: Deploy the application on Azure Virtual Machines and use PostgreSQL…

Deploying on Azure Virtual Machines creates an IaaS footprint where the startup is solely responsible for patching the guest OS, installing PostgreSQL, managing backups and high availability, storing database files, and handling scaling via VM resizing or replicated endpoints. Additionally, hosting the web app and database on the same VM couples compute and storage on one hardware boundary, creating a single point of failure and making it impossible to independently scale either tier. This operational burden directly contradicts the requirement to minimize management overhead.

A
Deploy the application on Azure App Service for Linux and use Azure Database for PostgreSQL.
Azure App Service for Linux is an enterprise-grade PaaS that fully manages the application runtime and operating system patching, with built-in load balancing, TLS termination, and autoscaling. Pairing it with Azure Database for PostgreSQL yields a fully managed relational database with automated backups, high availability, and predictable scaling, eliminating both application- and data-tier administrative chores. This combination keeps the startup focused only on business logic and precisely satisfies the requirement to minimize operational overhead.
B
Deploy the application on Azure Kubernetes Service (AKS) and use Azure Database for PostgreSQL.
Why it fails: AKS supplies a resilient Kubernetes control plane, but it imposes ongoing cluster lifecycle duties on the development team: managing node pools, patching the OS and kubelet, configuring ingress controllers, monitoring resource quotas, and upgrading Kubernetes versions. Even though Azure Database for PostgreSQL reduces database admin, the containerized app still must be built, configured, and operated as a workload on the cluster, which substantially exceeds the management overhead of a single App Service instance. This trade-off only pays off for larger microservice teams and custom infrastructure requirements, not for a startup's straightforward web application.
C
Deploy the application as Azure Functions and use Azure Cosmos DB for storage.
Why it fails: Azure Functions is a serverless compute platform optimized for event-driven triggers and transient execution, with a maximum execution timeout and cold-start latency that make it unsuitable for consistent, stateful web request serving to users. Cosmos DB is a NoSQL, multi-model database, not a relational PostgreSQL source, so any existing SQL schema, joins, transactions, or object-relational mapping would require substantial redesign. The combination fails both the compute model and the relational storage expectations of a typical web application.
D
Deploy the application on Azure Virtual Machines and use PostgreSQL on the same VM.
Why it fails: Deploying on Azure Virtual Machines creates an IaaS footprint where the startup is solely responsible for patching the guest OS, installing PostgreSQL, managing backups and high availability, storing database files, and handling scaling via VM resizing or replicated endpoints. Additionally, hosting the web app and database on the same VM couples compute and storage on one hardware boundary, creating a single point of failure and making it impossible to independently scale either tier. This operational burden directly contradicts the requirement to minimize management overhead.

Review the full routing breakdown →

Question 2hardmultiple choice

Your company is designing a new cloud-native application on Azure that consists of multiple microservices running on Azure Kubernetes Service (AKS). The application must be accessible from the internet via a custom domain name (app.contoso.com) and must support SSL/TLS termination. You need to design a secure ingress solution that provides Web Application Firewall (WAF) capabilities, SSL offloading, and automatic scaling. The solution should also support path-based routing to different microservices (e.g., /api, /web). You have the following options: Option A: Deploy an Azure Application Gateway v2 with WAF in front of the AKS cluster. Configure Application Gateway Ingress Controller (AGIC) to route traffic to the services. Option B: Deploy an Azure Load Balancer with a public IP and install an NGINX ingress controller on AKS. Configure SSL termination on NGINX and use a third-party WAF. Option C: Deploy an Azure Front Door with WAF policy in front of the AKS cluster. Use Azure Private Link to connect Front Door to the internal load balancer of AKS. Option D: Deploy an Azure API Management instance with WAF and expose the microservices through API endpoints. Use Azure Application Gateway as a reverse proxy. Which option best meets the requirements for a high-performance, integrated, and managed solution with minimal operational overhead?

Trap 1: Deploy an Azure Front Door with WAF policy in front of the AKS…

Azure Front Door is a global, anycast-based load-balancing service designed to route traffic across multiple regions. For a single-region AKS deployment, sending traffic through Front Door's edge network adds an unnecessary network hop and introduces latency, while Private Link endpoints to the AKS internal load balancer incur extra cost and configuration complexity. Application Gateway v2, by contrast, is a regional L7 solution that keeps traffic within the region and integrates directly with AKS.

Trap 2: Deploy an Azure Load Balancer with a public IP and install an NGINX…

This approach delegates TLS termination, request routing, and web application firewall duties to an NGINX ingress controller and an external third-party WAF running on self-managed infrastructure. The Azure Load Balancer only provides Layer 4 transport rules and does not understand HTTP paths or host headers, so everything above L4 must be manually configured, scaled, and patched by your team. Compared to a managed L7 WAF ingress like Application Gateway, this significantly increases operational overhead and introduces more points of failure for security updates and routing rules.

Trap 3: Deploy an Azure API Management instance with WAF and expose the…

Azure API Management is a full API gateway platform designed for publishing, versioning, securing, and monetizing APIs, which is unrelated to the stated requirement of simply exposing internal microservices behind a WAF. If you add it, you are also forced to route traffic through an extra Application Gateway reverse proxy, creating a multi-hop chain that adds latency and cost without business value. For this scenario, a single Application Gateway v2 configured with AGIC directly fronting the AKS services gives you the needed WAF protection and ingress control with far less complexity.

A
Deploy an Azure Front Door with WAF policy in front of the AKS cluster. Use Azure Private Link to connect Front Door to the internal load balancer of AKS.
Why it fails: Azure Front Door is a global, anycast-based load-balancing service designed to route traffic across multiple regions. For a single-region AKS deployment, sending traffic through Front Door's edge network adds an unnecessary network hop and introduces latency, while Private Link endpoints to the AKS internal load balancer incur extra cost and configuration complexity. Application Gateway v2, by contrast, is a regional L7 solution that keeps traffic within the region and integrates directly with AKS.
B
Deploy an Azure Application Gateway v2 with WAF in front of the AKS cluster. Configure Application Gateway Ingress Controller (AGIC) to route traffic to the services.
Application Gateway v2 is a regional, autoscaling, Layer 7 load balancer with a managed WAF that includes OWASP rule sets, making it a strong fit for exposing AKS-based microservices. By deploying AGIC, the Kubernetes Ingress resources are automatically translated into Application Gateway routing rules, so no separate ingress controller pod is required. It provides SSL termination, path-based routing, and zone redundancy, all while being fully managed by Azure, which reduces operational burden compared to self-managed ingress.
C
Deploy an Azure Load Balancer with a public IP and install an NGINX ingress controller on AKS. Configure SSL termination on NGINX and use a third-party WAF.
Why it fails: This approach delegates TLS termination, request routing, and web application firewall duties to an NGINX ingress controller and an external third-party WAF running on self-managed infrastructure. The Azure Load Balancer only provides Layer 4 transport rules and does not understand HTTP paths or host headers, so everything above L4 must be manually configured, scaled, and patched by your team. Compared to a managed L7 WAF ingress like Application Gateway, this significantly increases operational overhead and introduces more points of failure for security updates and routing rules.
D
Deploy an Azure API Management instance with WAF and expose the microservices through API endpoints. Use Azure Application Gateway as a reverse proxy.
Why it fails: Azure API Management is a full API gateway platform designed for publishing, versioning, securing, and monetizing APIs, which is unrelated to the stated requirement of simply exposing internal microservices behind a WAF. If you add it, you are also forced to route traffic through an extra Application Gateway reverse proxy, creating a multi-hop chain that adds latency and cost without business value. For this scenario, a single Application Gateway v2 configured with AGIC directly fronting the AKS services gives you the needed WAF protection and ingress control with far less complexity.

Question 3hardmulti select

You are designing a microservices architecture on Azure Kubernetes Service (AKS). The solution must handle traffic spikes by automatically scaling pods based on CPU utilization. Additionally, you need to minimize cost by scaling down nodes when not in use. Which two features should you implement? (Choose two.)

Trap 1: Azure Load Balancer

Azure Load Balancer is a Layer 4 load balancer that distributes inbound traffic to healthy backend instances. It does not evaluate resource utilization metrics or make scaling decisions. Autoscaling requires a control loop that reads metrics and adjusts replica counts, which the load balancer does not provide; it merely routes traffic.

Trap 2: Vertical Pod Autoscaler (VPA)

Vertical Pod Autoscaler works by analyzing historical resource usage and then adjusting the CPU and memory requests and limits of the containers within existing pods, after which it may restart those pods. While it optimizes individual pod resource allocation and can improve utilization, it does not increase the number of pod replicas. For scaling out a microservice horizontally, HPA is the appropriate mechanism.

Trap 3: Azure Container Instances (ACI)

Azure Container Instances is a separate serverless container service that runs containers on demand without managing underlying VMs. In an AKS context, virtual nodes can schedule burstable pods to ACI, but this is not a native AKS autoscaling feature; it is an alternative scheduling target. ACI itself does not modify the replica count of a Kubernetes workload, so it cannot serve as the autoscaler for the microservice.

A
Azure Load Balancer
Why it fails: Azure Load Balancer is a Layer 4 load balancer that distributes inbound traffic to healthy backend instances. It does not evaluate resource utilization metrics or make scaling decisions. Autoscaling requires a control loop that reads metrics and adjusts replica counts, which the load balancer does not provide; it merely routes traffic.
B
Horizontal Pod Autoscaler (HPA)
Horizontal Pod Autoscaler is a Kubernetes control loop that queries the Metrics API for CPU, memory, or custom application metrics and automatically updates the replica count of a Deployment or ReplicaSet. This scaling mechanism is fundamental to microservices on AKS because it dynamically matches the number of running pod instances to the observed demand, ensuring high availability and cost efficiency without manual intervention.
C
Vertical Pod Autoscaler (VPA)
Why it fails: Vertical Pod Autoscaler works by analyzing historical resource usage and then adjusting the CPU and memory requests and limits of the containers within existing pods, after which it may restart those pods. While it optimizes individual pod resource allocation and can improve utilization, it does not increase the number of pod replicas. For scaling out a microservice horizontally, HPA is the appropriate mechanism.
D
Azure Container Instances (ACI)
Why it fails: Azure Container Instances is a separate serverless container service that runs containers on demand without managing underlying VMs. In an AKS context, virtual nodes can schedule burstable pods to ACI, but this is not a native AKS autoscaling feature; it is an alternative scheduling target. ACI itself does not modify the replica count of a Kubernetes workload, so it cannot serve as the autoscaler for the microservice.
E
Cluster Autoscaler
Cluster Autoscaler is an AKS component that automatically resizes the node pool by adding or removing nodes based on pending pods that cannot be scheduled due to insufficient cluster capacity. It operates at the infrastructure layer and complements HPA, which handles the pod-level replica count. For a specific microservice, HPA is the primary autoscaler because it directly controls pod replicas, while Cluster Autoscaler addresses cluster-wide resource constraints.

Question 4mediummultiple choice

A gaming company is developing a multiplayer online game that requires a low-latency data store for player profiles, inventory, and session state. The data is accessed globally, and the solution must support millions of concurrent players. The company expects write-heavy workloads with occasional reads. The solution must provide single-digit millisecond latency for reads and writes. The company also needs to run analytics on the data to understand player behavior, but analytics queries can tolerate higher latency (minutes). Which Azure data storage solution should the company recommend for the transactional data?

Trap 1: Azure SQL Database with active geo-replication

Azure SQL Database active geo-replication asynchronously replicates committed transactions to a readable secondary in a paired region, but the primary remains the sole write endpoint. All writes are applied to the primary first, and that single-region commit path cannot deliver the globally distributed, multi-master write performance this game needs. During a regional outage, failover is database-level and takes time, risking session continuity for players, and the synchronous/async replication trade-off does not match the required low-latency global writes.

Trap 2: Azure Redis Cache with persistence

Azure Redis Cache with persistence (RDB or AOF) is fundamentally a durable cache, not a transactional multi-region data store. It has a single primary node that accepts writes; writes are serialized to one region and replication to other regions is not a supported native multi-master topology. Persistence protects against restart data loss but does not provide the multi-region write consistency, conflict resolution, or distributed leader election required for a global multiplayer state store, so it fails the durability and global-write requirements.

Trap 3: Azure Table Storage with geo-redundancy

Azure Table Storage is a schemaless NoSQL key-value store that supports geo-redundant storage (GRS) for durability, but failover to the secondary region is automatic only for the entire storage account and is not a multi-region write capability. Latency is not guaranteed to be single-digit milliseconds globally because Table Storage does not provide a managed multi-master model; writes go to the primary region and the secondary is only a read-only copy after failover. For a game requiring low-latency writes from players worldwide and active-active multi-region writes, Table Storage's eventual consistency and single-writer-region limitation are disqualifying.

A
Azure SQL Database with active geo-replication
Why it fails: Azure SQL Database active geo-replication asynchronously replicates committed transactions to a readable secondary in a paired region, but the primary remains the sole write endpoint. All writes are applied to the primary first, and that single-region commit path cannot deliver the globally distributed, multi-master write performance this game needs. During a regional outage, failover is database-level and takes time, risking session continuity for players, and the synchronous/async replication trade-off does not match the required low-latency global writes.
B
Azure Redis Cache with persistence
Why it fails: Azure Redis Cache with persistence (RDB or AOF) is fundamentally a durable cache, not a transactional multi-region data store. It has a single primary node that accepts writes; writes are serialized to one region and replication to other regions is not a supported native multi-master topology. Persistence protects against restart data loss but does not provide the multi-region write consistency, conflict resolution, or distributed leader election required for a global multiplayer state store, so it fails the durability and global-write requirements.
C
Azure Cosmos DB with multiple write regions
Azure Cosmos DB with multiple write regions (multi-master) enables every region to accept writes, and each write is replicated asynchronously to all other regions with conflict resolution policies (e.g., last-writer-wins, custom). This delivers single-digit-millisecond read and write latencies at the 99th percentile anywhere in the world because the client can target the nearest region for both reads and writes. The service provides 99.999% availability with SLAs, automatic failover, and a choice of consistency levels, making it the correct fit for globally distributed, always-on multiplayer game state.
D
Azure Table Storage with geo-redundancy
Why it fails: Azure Table Storage is a schemaless NoSQL key-value store that supports geo-redundant storage (GRS) for durability, but failover to the secondary region is automatic only for the entire storage account and is not a multi-region write capability. Latency is not guaranteed to be single-digit milliseconds globally because Table Storage does not provide a managed multi-master model; writes go to the primary region and the secondary is only a read-only copy after failover. For a game requiring low-latency writes from players worldwide and active-active multi-region writes, Table Storage's eventual consistency and single-writer-region limitation are disqualifying.

Question 5mediummultiple choice

You are designing a solution to provide high availability for a critical application running on Azure Virtual Machines. The virtual machines must be placed on physically separate hardware and have guaranteed availability during Azure maintenance events. Which option meets these requirements?

Trap 1: Deploy VMs in an Availability Set

An Availability Set spreads VMs across fault domains within a single datacentre, which does not satisfy the physically separate hardware requirement across zones. It is tempting because it is the classic anti-affinity construct, and it would be correct for protecting against rack-level failures within one region.

Trap 2: Deploy VMs in a Proximity Placement Group

A Proximity Placement Group reduces network latency by co-locating VMs within a single datacentre; it does not place them on physically separate hardware, nor does it protect against host maintenance events. It suits tightly coupled, latency-sensitive workloads such as HPC clusters, not the fault-isolation requirement stated here.

Trap 3: Deploy VMs in a Virtual Machine Scale Set

A Virtual Machine Scale Set provides elasticity and autoscaling across identical instances, but its default distribution offers no guarantee of separation across fault domains or protection during host maintenance. It is the right choice for demand-driven horizontal scaling, not for the physical hardware separation this scenario demands.

A
Deploy VMs in an Availability Set
Why it fails: An Availability Set spreads VMs across fault domains within a single datacentre, which does not satisfy the physically separate hardware requirement across zones. It is tempting because it is the classic anti-affinity construct, and it would be correct for protecting against rack-level failures within one region.
B
Deploy VMs in a Proximity Placement Group
Why it fails: A Proximity Placement Group reduces network latency by co-locating VMs within a single datacentre; it does not place them on physically separate hardware, nor does it protect against host maintenance events. It suits tightly coupled, latency-sensitive workloads such as HPC clusters, not the fault-isolation requirement stated here.
C
Deploy VMs in different Availability Zones
Availability Zones are physically separate datacentres within a region, each with independent power, cooling and networking. Distributing VMs across zones satisfies the stem's physically separate hardware constraint and maintains availability during Azure maintenance affecting a single zone.
D
Deploy VMs in a Virtual Machine Scale Set
Why it fails: A Virtual Machine Scale Set provides elasticity and autoscaling across identical instances, but its default distribution offers no guarantee of separation across fault domains or protection during host maintenance. It is the right choice for demand-driven horizontal scaling, not for the physical hardware separation this scenario demands.

Question 6hardmultiple choice

You are a solutions architect for a financial services company. The company is deploying a new critical application on Azure that processes sensitive customer transactions. The application consists of an ASP.NET Core web app (Azure App Service), a REST API (Azure Kubernetes Service), and an Azure SQL Database. The requirements are:

- All data at rest must be encrypted using customer-managed keys (CMK) stored in a managed HSM. - All network traffic between components must be encrypted and traverse the Microsoft backbone network. - The web app must be protected against common web attacks (SQL injection, XSS). - The solution must automatically scale the API based on CPU utilization. - All API calls must be authenticated using OAuth 2.0 with Microsoft Entra ID. - Logs from all components must be sent to a central Log Analytics workspace for analysis. - The solution must have a recovery time objective (RTO) of 1 hour and recovery point objective (RPO) of 5 minutes for the database.

Which combination of Azure services should you recommend to meet ALL requirements?

Trap 1: Azure Front Door with WAF, Azure SQL Database point-in-time…

Point-in-time restore does not guarantee an RPO of 5 minutes or an RTO of 1 hour; it is a backup restore solution, not a high-availability failover. Although it uses private endpoint and HPA, the database requirement is not met.

Trap 2: Azure Front Door with WAF, Azure SQL Database geo-replication,…

This design fails the requirement for customer-managed keys stored in a managed HSM because Azure Key Vault (Standard) only supports software-protected keys, not the FIPS 140-2 Level 3 validated hardware security modules provided by Azure Key Vault Managed HSM. While the option correctly uses AKS with HPA for CPU-based scaling and SQL Database geo-replication, the key vault type is the critical compliance blocker for a financial services workload. Azure Front Door with WAF and private endpoint are acceptable, but the key management deficiency cannot be mitigated by the other components.

Trap 3: Azure Application Gateway with WAF, Azure SQL Database active…

Cluster autoscaler scales the number of node VMs, not pod replicas, and does not respond to CPU utilization of pods, failing the requirement for automatic scaling based on CPU utilization. Although it meets other requirements, the scaling requirement is critical.

A
Azure Front Door with WAF, Azure SQL Database point-in-time restore, Azure Key Vault Managed HSM, Azure App Service with private endpoint, AKS with HPA, Azure Log Analytics agent, Microsoft Entra ID
Why it fails: Point-in-time restore does not guarantee an RPO of 5 minutes or an RTO of 1 hour; it is a backup restore solution, not a high-availability failover. Although it uses private endpoint and HPA, the database requirement is not met.
B
Azure Front Door with WAF, Azure SQL Database geo-replication, Azure Key Vault (Standard), Azure App Service with private endpoint, AKS with HPA, Azure Diagnostics extension, Microsoft Entra ID
Why it fails: This design fails the requirement for customer-managed keys stored in a managed HSM because Azure Key Vault (Standard) only supports software-protected keys, not the FIPS 140-2 Level 3 validated hardware security modules provided by Azure Key Vault Managed HSM. While the option correctly uses AKS with HPA for CPU-based scaling and SQL Database geo-replication, the key vault type is the critical compliance blocker for a financial services workload. Azure Front Door with WAF and private endpoint are acceptable, but the key management deficiency cannot be mitigated by the other components.
C
Azure Application Gateway with WAF, Azure SQL Database active geo-replication, Azure Key Vault Managed HSM, Azure App Service with VNet integration, AKS with cluster autoscaler, Azure Monitor Agent, Microsoft Entra ID
Why it fails: Cluster autoscaler scales the number of node VMs, not pod replicas, and does not respond to CPU utilization of pods, failing the requirement for automatic scaling based on CPU utilization. Although it meets other requirements, the scaling requirement is critical.
D
Azure Application Gateway with WAF, Azure SQL Database failover groups, Azure Key Vault Managed HSM, Azure App Service with service endpoint, AKS with HPA, Azure Monitor Agent, Microsoft Entra ID
Correct. Failover groups meet RPO and RTO, Managed HSM meets key storage, service endpoint keeps traffic on Microsoft backbone, AKS with HPA scales based on CPU, Application Gateway WAF protects against attacks, Azure Monitor Agent collects logs, and Microsoft Entra ID authenticates API calls.

Question 7easymultiple choice

Your company has a web application deployed on Azure App Service that experiences periodic traffic spikes. You need to ensure the application scales out quickly without manual intervention. The solution must minimize cost during low-traffic periods. What should you configure?

Trap 1: Enable pre-warming in the App Service plan

Enabling pre-warming in the App Service plan does not scale the number of running instances; it only initializes application code on a new instance before traffic is routed to it. This feature is typically used with Always On or deployment slots to reduce cold-start latency, but it offers no automatic adjustment of instance counts based on load or metrics. Therefore, it cannot solve a need for dynamic scaling under varying CPU or memory pressure.

Trap 2: Deploy the app to a Virtual Machine Scale Set

Deploying the application to a Virtual Machine Scale Set is incorrect because the application is already hosted on Azure App Service, a PaaS offering. Migrating to a VMSS would require rebuilding the application as a VM image, implementing update/domain management, patching, and configuring a separate load balancer—none of which are necessary for App Service. Moreover, VMSS autoscaling operates at the virtual machine level, not at the App Service level, so it cannot scale the existing App Service plan.

Trap 3: Manually increase the instance count before expected spikes

Manually increasing the instance count before expected spikes requires you to predict traffic and intervene by modifying the scale-out settings in the Azure portal or via CLI/scripts. This approach is error-prone because it doesn't react to actual real-time metrics; if the spike is larger or earlier than expected, the app may still be under-provisioned, and if traffic is lower, you waste resources. Autoscale handles this dynamically, so manual scaling is unnecessary and inferior for demand-driven workloads.

A
Enable pre-warming in the App Service plan
Why it fails: Enabling pre-warming in the App Service plan does not scale the number of running instances; it only initializes application code on a new instance before traffic is routed to it. This feature is typically used with Always On or deployment slots to reduce cold-start latency, but it offers no automatic adjustment of instance counts based on load or metrics. Therefore, it cannot solve a need for dynamic scaling under varying CPU or memory pressure.
B
Configure Autoscale rules based on CPU or memory metrics
Configuring autoscale rules is the proper PaaS-native mechanism for Azure App Service to automatically adjust the instance count of your App Service plan. You define scale conditions based on metrics such as CPU percentage, memory consumption, or request queue length, and Autoscale adds or removes instances in response to those thresholds. This is a fully automated, reactive approach that continuously monitors load and eliminates the need for manual intervention.
C
Deploy the app to a Virtual Machine Scale Set
Why it fails: Deploying the application to a Virtual Machine Scale Set is incorrect because the application is already hosted on Azure App Service, a PaaS offering. Migrating to a VMSS would require rebuilding the application as a VM image, implementing update/domain management, patching, and configuring a separate load balancer—none of which are necessary for App Service. Moreover, VMSS autoscaling operates at the virtual machine level, not at the App Service level, so it cannot scale the existing App Service plan.
D
Manually increase the instance count before expected spikes
Why it fails: Manually increasing the instance count before expected spikes requires you to predict traffic and intervene by modifying the scale-out settings in the Azure portal or via CLI/scripts. This approach is error-prone because it doesn't react to actual real-time metrics; if the spike is larger or earlier than expected, the app may still be under-provisioned, and if traffic is lower, you waste resources. Autoscale handles this dynamically, so manual scaling is unnecessary and inferior for demand-driven workloads.

Question 8mediummultiple choice

Your company is deploying a web application that experiences unpredictable traffic spikes. You need to ensure the application can handle sudden increases in load automatically without manual intervention and minimize costs during low traffic periods. Which Azure service should you use?

Trap 1: Azure App Service with manual scale-out

Azure App Service supports manual scale-out by raising the instance count through the portal, but this is a reactive process requiring an operator to detect a spike and adjust capacity. Because it cannot respond automatically to changing traffic, it risks either over-provisioning (wasteful cost) or under-provisioning (degraded performance). For a workload that needs reliable elasticity, manual scale-out fails to meet the automatic recovery requirement.

Trap 2: Azure Functions with consumption plan

Azure Functions uses a consumption plan that provides event-driven autoscaling, but it is designed for short-running, stateless, event-triggered workloads such as APIs, queue processing, or timer jobs. It is not meant to host a full web application because functions have execution time limits, can suffer cold starts, and lack a persistent server environment for long-running requests. Therefore, while it scales automatically, it is architecturally unsuitable for this scenario.

Trap 3: Azure Container Instances

Azure Container Instances provides fast, serverless container execution but lacks a built-in autoscale mechanism that adjusts instance counts based on load metrics. To scale containers automatically, you must add an orchestrator like Azure Kubernetes Service or deploy a separate service to manage container groups, which adds complexity and latency. For this reason, it cannot autonomously handle traffic spikes for a web application without additional external orchestration.

A
Azure App Service with manual scale-out
Why it fails: Azure App Service supports manual scale-out by raising the instance count through the portal, but this is a reactive process requiring an operator to detect a spike and adjust capacity. Because it cannot respond automatically to changing traffic, it risks either over-provisioning (wasteful cost) or under-provisioning (degraded performance). For a workload that needs reliable elasticity, manual scale-out fails to meet the automatic recovery requirement.
B
Azure Functions with consumption plan
Why it fails: Azure Functions uses a consumption plan that provides event-driven autoscaling, but it is designed for short-running, stateless, event-triggered workloads such as APIs, queue processing, or timer jobs. It is not meant to host a full web application because functions have execution time limits, can suffer cold starts, and lack a persistent server environment for long-running requests. Therefore, while it scales automatically, it is architecturally unsuitable for this scenario.
C
Virtual Machine Scale Set with autoscale
Virtual Machine Scale Sets with autoscale rules are the correct choice because they automatically adjust the number of VM instances based on metrics like CPU percentage, memory, or custom thresholds. This enables horizontal scaling to handle traffic spikes by adding instances and also scaling in during low demand to reduce costs. The approach is ideal for hosting web applications that require full control over the VM image, dependencies, or infrastructure-level configuration.
D
Azure Container Instances
Why it fails: Azure Container Instances provides fast, serverless container execution but lacks a built-in autoscale mechanism that adjusts instance counts based on load metrics. To scale containers automatically, you must add an orchestrator like Azure Kubernetes Service or deploy a separate service to manage container groups, which adds complexity and latency. For this reason, it cannot autonomously handle traffic spikes for a web application without additional external orchestration.

Question 9hardmultiple choice

Your company, Contoso Ltd., operates a global e-commerce platform hosted on Azure. The architecture consists of: (1) A web front-end running on Azure App Service in multiple regions (East US, West Europe, Southeast Asia). (2) A microservices backend running on Azure Kubernetes Service (AKS) in East US. (3) A SQL Database in East US with geo-replication to West Europe and Southeast Asia for read scaling. (4) Azure Redis Cache for session state. (5) Azure Front Door for global load balancing. The platform experiences periodic traffic spikes, and during a recent spike, users reported slow page loads and intermittent errors. The operations team observed that the SQL Database in East US reached 100% DTU consumption, causing timeouts. The geo-replicated databases in other regions were underutilized. The application logic is read-heavy but also writes to a separate write-only table. You need to design a solution to improve scalability and reduce database load. The solution must: minimize latency for users, ensure write consistency, and handle traffic spikes without over-provisioning. What should you do?

Trap 1: Upgrade the SQL Database in East US to a higher DTU tier and enable…

DTU-based service tiers for Azure SQL Database do not offer auto-scaling; you would need to manually raise the DTU count, which increases cost linearly through a broader single-node resource pool. Even if you scale to a Premium tier, you only add capacity to the primary in East US rather than distributing the read workload across the existing geo-replicated readable secondaries, and you still pay for the replicas separately. This approach is a blunt, expensive vertical scale that fails to reduce latency for users in other regions and does not address the architectural imbalance between heavy global reads and one primary.

Trap 2: Implement a second-level cache using Azure Cache for Redis with a…

Implementing Azure Cache for Redis with a local in-memory cache in the web front-ends can reduce repeated SQL reads and lower perceived latency, but it is an application-side mitigation that does not touch the database DTU throughput bottleneck itself. A local cache pattern introduces distributed cache invalidation complexity, requiring TTL tuning and cross-region consistency handling, which can easily serve stale data during flash sales or after product updates. Redis also does nothing to reduce the volume of writes or the load on the primary database connection pool, so it is a valuable optimization but not a solution for the scenario's core database scaling need.

Trap 3: Shard the database by customer region and deploy shards in each…

Sharding the database by customer region and deploying separate shards per region is a substantial data-architecture overhaul that requires rewriting application queries, implementing a shard map, and managing cross-shard joins and transactions. It may even increase the blast radius, because a customer who travels or places orders across regions will force distributed queries that can be slower than the current single database, and you must still handle global writes and consistency. The geo-replication plus read-only routing option provides an immediate, low-risk scale-out of reads without requiring the application to know which region owns which customer, so sharding is disproportionate complexity that is unlikely to solve the immediate DTU bottleneck in a short timeframe.

A
Upgrade the SQL Database in East US to a higher DTU tier and enable auto-scaling.
Why it fails: DTU-based service tiers for Azure SQL Database do not offer auto-scaling; you would need to manually raise the DTU count, which increases cost linearly through a broader single-node resource pool. Even if you scale to a Premium tier, you only add capacity to the primary in East US rather than distributing the read workload across the existing geo-replicated readable secondaries, and you still pay for the replicas separately. This approach is a blunt, expensive vertical scale that fails to reduce latency for users in other regions and does not address the architectural imbalance between heavy global reads and one primary.
B
Configure read-only routing in the application connection string to use the geo-replicated databases for read queries, and keep writes directed to the primary.
For an Azure SQL Database with active geo-replication, you can set the application connection string to include ApplicationIntent=ReadOnly; the gateway then automatically routes incoming read-only queries to the nearest readable secondary, while the login remains pointed at the primary for any write transactions. This offloads the bulk of the SELECT traffic from the primary DTU pool, effectively increasing total system throughput without changing the database tier and saving the primary for writes. Because the geo-replicas already exist, the only change is a connection string property, making this the lowest-complexity, highest-leverage fix for a global read-heavy workload and the reason it is the correct answer.
C
Implement a second-level cache using Azure Cache for Redis with a local cache pattern in the web front-end.
Why it fails: Implementing Azure Cache for Redis with a local in-memory cache in the web front-ends can reduce repeated SQL reads and lower perceived latency, but it is an application-side mitigation that does not touch the database DTU throughput bottleneck itself. A local cache pattern introduces distributed cache invalidation complexity, requiring TTL tuning and cross-region consistency handling, which can easily serve stale data during flash sales or after product updates. Redis also does nothing to reduce the volume of writes or the load on the primary database connection pool, so it is a valuable optimization but not a solution for the scenario's core database scaling need.
D
Shard the database by customer region and deploy shards in each region.
Why it fails: Sharding the database by customer region and deploying separate shards per region is a substantial data-architecture overhaul that requires rewriting application queries, implementing a shard map, and managing cross-shard joins and transactions. It may even increase the blast radius, because a customer who travels or places orders across regions will force distributed queries that can be slower than the current single database, and you must still handle global writes and consistency. The geo-replication plus read-only routing option provides an immediate, low-risk scale-out of reads without requiring the application to know which region owns which customer, so sharding is disproportionate complexity that is unlikely to solve the immediate DTU bottleneck in a short timeframe.

Question 10easymultiple choice

A company runs a web application on Azure VMs in a single region. The application must scale out automatically based on CPU utilization. The VMs are behind an Azure Load Balancer. Which Azure service should they use to automatically add or remove VMs based on demand?

Trap 1: Azure App Service

Azure App Service is incorrect because it is a fully managed Platform-as-a-Service (PaaS) offering for hosting web apps, REST APIs, and mobile backends, not a service for managing or scaling a fleet of VMs. With App Service, you deploy your code to a managed runtime environment and scale via App Service plans, which adjust the number and size of worker nodes behind the scenes—you never control or access the underlying VMs. Since the company in the question is already running on Azure VMs, App Service would require rearchitecting the application to a PaaS model, rather than providing VM-level scaling.

Trap 2: Azure Functions

Azure Functions is incorrect because it is a serverless compute service designed for event-driven, short-lived functions that scale automatically based on incoming triggers such as HTTP requests, queue messages, or timers, not for orchestrating or scaling a set of virtual machines. It abstracts away all infrastructure, including VMs, and executes stateless code with scale controlled by the Functions runtime, not by VM scale rules. For a web application already deployed on VMs, Functions cannot scale or manage those VMs; it is a completely different execution model.

Trap 3: Azure Batch

Azure Batch is incorrect because it is a service for planning, scheduling, and running large-scale parallel and high-performance computing (HPC) batch workloads, not for autoscaling web application VMs. Batch allocates and manages a pool of compute nodes to process many jobs in a queue, with scaling based on the number of pending tasks, and those nodes are typically isolated from public-facing traffic. Unlike VMSS, which integrates with load balancers for serving web requests, Batch is designed for offline processing and does not provide the health probes, rolling upgrades, or load balancing features needed to operate a web frontend.

A
Azure Virtual Machine Scale Sets
Azure Virtual Machine Scale Sets (VMSS) is the correct choice because it directly manages a group of identical VMs as a single pool, providing automatic horizontal scaling based on performance metrics like CPU or memory utilization, custom metrics, or scheduled times. It integrates natively with Azure Load Balancer and Application Gateway to distribute incoming web traffic across the VM instances, making it ideal for a web application hosted on Azure VMs. VMSS also supports manual scaling, automatic scale rules, and health monitoring to replace unhealthy instances, ensuring high availability and elastic capacity for fluctuating web workloads.
B
Azure App Service
Why it fails: Azure App Service is incorrect because it is a fully managed Platform-as-a-Service (PaaS) offering for hosting web apps, REST APIs, and mobile backends, not a service for managing or scaling a fleet of VMs. With App Service, you deploy your code to a managed runtime environment and scale via App Service plans, which adjust the number and size of worker nodes behind the scenes—you never control or access the underlying VMs. Since the company in the question is already running on Azure VMs, App Service would require rearchitecting the application to a PaaS model, rather than providing VM-level scaling.
C
Azure Functions
Why it fails: Azure Functions is incorrect because it is a serverless compute service designed for event-driven, short-lived functions that scale automatically based on incoming triggers such as HTTP requests, queue messages, or timers, not for orchestrating or scaling a set of virtual machines. It abstracts away all infrastructure, including VMs, and executes stateless code with scale controlled by the Functions runtime, not by VM scale rules. For a web application already deployed on VMs, Functions cannot scale or manage those VMs; it is a completely different execution model.
D
Azure Batch
Why it fails: Azure Batch is incorrect because it is a service for planning, scheduling, and running large-scale parallel and high-performance computing (HPC) batch workloads, not for autoscaling web application VMs. Batch allocates and manages a pool of compute nodes to process many jobs in a queue, with scaling based on the number of pending tasks, and those nodes are typically isolated from public-facing traffic. Unlike VMSS, which integrates with load balancers for serving web requests, Batch is designed for offline processing and does not provide the health probes, rolling upgrades, or load balancing features needed to operate a web frontend.

Question 11mediummultiple choice

You are designing a containerized microservices application on Azure Kubernetes Service (AKS). The application must scale automatically based on HTTP traffic. You need to minimize cost by scaling down to zero pods when there is no traffic. Which scaling solution should you use?

Trap 1: Horizontal Pod Autoscaler (HPA)

Horizontal Pod Autoscaler (HPA) is the built-in Kubernetes controller that adjusts the number of pod replicas based on observed CPU, memory, or custom metrics, but it cannot scale a workload down to zero pods because the Deployment or StatefulSet must maintain a minimum replica count (typically minReplicas ≥ 1). HPA also relies on a continuous stream of metrics and lacks event-driven triggers, so during idle periods or while waiting for a burst of HTTP traffic it will keep at least one pod running, incurring unnecessary cost and resource usage. For a microservices application that may need true zero-idle scaling, HPA alone is insufficient.

Trap 2: Cluster Autoscaler

Cluster Autoscaler works at the infrastructure layer, not the application layer, by adding or removing worker nodes in the Kubernetes cluster based on pending pod scheduling conditions. It does not make decisions about individual pod replica counts; instead it reacts to pods that are unschedulable due to insufficient node capacity and scales the node pool accordingly. While Cluster Autoscaler can help reduce waste when combined with other autoscalers, it cannot itself reduce a microservice's pod count to zero based on HTTP traffic, so it does not satisfy the stated requirement.

Trap 3: Vertical Pod Autoscaler (VPA)

Vertical Pod Autoscaler (VPA) adjusts CPU and memory requests/limits for existing pods, either restarting them or recommending new values, but it never changes the number of pod replicas. VPA is designed to ensure each pod is sized appropriately for its workload, not to handle fluctuations in request volume or to set replica counts to zero. Even if VPA frees resources on a node, it cannot provide the requested scale-to-zero behavior for HTTP-driven microservices, so it is fundamentally misaligned with the requirement.

A
Horizontal Pod Autoscaler (HPA)
Why it fails: Horizontal Pod Autoscaler (HPA) is the built-in Kubernetes controller that adjusts the number of pod replicas based on observed CPU, memory, or custom metrics, but it cannot scale a workload down to zero pods because the Deployment or StatefulSet must maintain a minimum replica count (typically minReplicas ≥ 1). HPA also relies on a continuous stream of metrics and lacks event-driven triggers, so during idle periods or while waiting for a burst of HTTP traffic it will keep at least one pod running, incurring unnecessary cost and resource usage. For a microservices application that may need true zero-idle scaling, HPA alone is insufficient.
B
Cluster Autoscaler
Why it fails: Cluster Autoscaler works at the infrastructure layer, not the application layer, by adding or removing worker nodes in the Kubernetes cluster based on pending pod scheduling conditions. It does not make decisions about individual pod replica counts; instead it reacts to pods that are unschedulable due to insufficient node capacity and scales the node pool accordingly. While Cluster Autoscaler can help reduce waste when combined with other autoscalers, it cannot itself reduce a microservice's pod count to zero based on HTTP traffic, so it does not satisfy the stated requirement.
C
Kubernetes Event-driven Autoscaler (KEDA)
Kubernetes Event-driven Autoscaler (KEDA) is the correct choice because it extends the Horizontal Pod Autoscaler (HPA) with event-driven triggers from HTTP requests, message queues, databases, or other external sources, allowing a microservice to scale from zero to N replicas and back down to zero when idle. KEDA installs a custom metrics API server that reports the current event stream length or request rate to the HPA, enabling fine-grained scaling that reacts to actual demand rather than only steady-state server metrics. This makes it ideal for containerized microservices that experience intermittent traffic and require cost-efficient running with no idle pods.
D
Vertical Pod Autoscaler (VPA)
Why it fails: Vertical Pod Autoscaler (VPA) adjusts CPU and memory requests/limits for existing pods, either restarting them or recommending new values, but it never changes the number of pod replicas. VPA is designed to ensure each pod is sized appropriately for its workload, not to handle fluctuations in request volume or to set replica counts to zero. Even if VPA frees resources on a node, it cannot provide the requested scale-to-zero behavior for HTTP-driven microservices, so it is fundamentally misaligned with the requirement.

Question 12hardmultiple choice

A company is designing a solution for a global e-commerce platform that requires low-latency access to product catalog data from multiple regions. The data is read-heavy with occasional updates. The solution must support automatic scaling and provide high availability. Which Azure service should you recommend?

Trap 1: Azure SQL Database with active geo-replication

Azure SQL Database's active geo-replication creates readable secondary replicas in other regions, but writes remain pinned to a single primary region, and read traffic to secondaries can experience replication lag, making it unsuitable for a global e-commerce platform that demands instant, consistent reads at scale. The relational engine also struggles with the elastic, multi-region write distribution and dynamic throughput requirements of a high-volume, globally distributed store, whereas a purpose-built globally distributed database is needed.

Trap 2: Azure Table Storage

Azure Table Storage is a NoSQL key-value store but it lacks built-in global distribution capabilities such as multi-region writes, automatic multi-region reads, or consistency controls that are essential for a globally distributed e-commerce platform. Its storage is tied to a single region (or a secondary read-only region via RA-GRS) and does not provide the sub-second, automatic routing and low-latency reads across many regions that a global application requires, so it cannot match the performance and global replication promises of a dedicated globally distributed database.

Trap 3: Azure Cache for Redis

Azure Cache for Redis is an in-memory caching service, not a durable primary data store; it requires a separate backing database to persist transactional and order data, and it does not natively support multi-region writes or global distribution across geographies. While it can cache frequently read data to reduce latency, it cannot serve as the authoritative data platform for a global e-commerce system, because data loss on restart is unacceptable for orders and inventory, and its multi-region replication capabilities are limited compared with a true globally distributed database.

A
Azure SQL Database with active geo-replication
Why it fails: Azure SQL Database's active geo-replication creates readable secondary replicas in other regions, but writes remain pinned to a single primary region, and read traffic to secondaries can experience replication lag, making it unsuitable for a global e-commerce platform that demands instant, consistent reads at scale. The relational engine also struggles with the elastic, multi-region write distribution and dynamic throughput requirements of a high-volume, globally distributed store, whereas a purpose-built globally distributed database is needed.
B
Azure Cosmos DB with multi-region writes
Azure Cosmos DB with multi-region writes is purpose-built for global distribution, offering turnkey active-active replication across any number of Azure regions. It provides single-digit-millisecond read and write latencies at the 99th percentile, automatic and elastic scaling of throughput and storage, and multiple well-defined consistency models, so a global e-commerce platform can serve users from their nearest region with low latency and high availability, while also supporting multi-region write concurrency for true active-active operation.
C
Azure Table Storage
Why it fails: Azure Table Storage is a NoSQL key-value store but it lacks built-in global distribution capabilities such as multi-region writes, automatic multi-region reads, or consistency controls that are essential for a globally distributed e-commerce platform. Its storage is tied to a single region (or a secondary read-only region via RA-GRS) and does not provide the sub-second, automatic routing and low-latency reads across many regions that a global application requires, so it cannot match the performance and global replication promises of a dedicated globally distributed database.
D
Azure Cache for Redis
Why it fails: Azure Cache for Redis is an in-memory caching service, not a durable primary data store; it requires a separate backing database to persist transactional and order data, and it does not natively support multi-region writes or global distribution across geographies. While it can cache frequently read data to reduce latency, it cannot serve as the authoritative data platform for a global e-commerce system, because data loss on restart is unacceptable for orders and inventory, and its multi-region replication capabilities are limited compared with a true globally distributed database.

Question 13easymultiple choice

A company wants to run a containerized application on Azure without managing virtual machines. They need automatic scaling, load balancing, and rolling updates. Which Azure compute service should they choose?

Trap 1: Azure Virtual Machine Scale Sets

Azure Virtual Machine Scale Sets (VMSS) operate at the IaaS layer to autoscale identical VM instances, but they do not provide any container orchestration capabilities. Even if you install a container runtime on each VM, you are still responsible for scheduling containers, managing service discovery, and performing rolling updates manually or by integrating external tooling such as a self-managed Kubernetes cluster. VMSS autoscaling is based on VM-level metrics like CPU, not container health, so it cannot natively scale or repair individual containerized workloads, making it a poor fit for a fully managed container platform.

Trap 2: Azure App Service

Azure App Service is a PaaS offering that can run containerized web apps, but its container support is best suited for a single container or a simple Docker Compose definition, not for orchestrating distributed microservices. It does not expose Kubernetes primitives like Pods, Services, or Ingress controllers, and its autoscaling is based on web app metrics or a scheduled profile, not application-level container scheduling. While it reduces management overhead by providing built-in web server integration and HTTPS, it lacks the granular deployment strategies and cluster-level service discovery that AKS offers, so it would be limiting for large-scale container-centric architectures.

Trap 3: Azure Container Instances

Azure Container Instances (ACI) provides a serverless environment to start an individual container or a small container group on demand, but it has no built-in orchestrator to manage multiple containers across virtual nodes. It cannot automatically scale the number of container replicas based on traffic, nor does it support rolling updates or advanced placement policies—you would have to manually tear down and recreate containers to change an application version. ACI is ideal for a simply scheduled job or an event-driven burst workload, but it leaves all lifecycle and multi-container orchestration decisions to the developer, so it does not satisfy the requirement of running a containerized application without managing orchestration.

A
Azure Virtual Machine Scale Sets
Why it fails: Azure Virtual Machine Scale Sets (VMSS) operate at the IaaS layer to autoscale identical VM instances, but they do not provide any container orchestration capabilities. Even if you install a container runtime on each VM, you are still responsible for scheduling containers, managing service discovery, and performing rolling updates manually or by integrating external tooling such as a self-managed Kubernetes cluster. VMSS autoscaling is based on VM-level metrics like CPU, not container health, so it cannot natively scale or repair individual containerized workloads, making it a poor fit for a fully managed container platform.
B
Azure Kubernetes Service (AKS)
Azure Kubernetes Service (AKS) is a fully managed container orchestration platform that abstracts the Kubernetes control plane—including etcd and the API server—so you never have to manage those components. It provides managed node pools, cluster autoscaler, seamless integration with Azure Load Balancer and Application Gateway, and declarative rolling updates through Kubernetes Deployments and ReplicaSets. AKS handles scheduling, self-healing, service discovery, and secret management natively, making it the appropriate choice when you need robust, production-grade orchestration for containerized applications without managing the underlying orchestration infrastructure.
C
Azure App Service
Why it fails: Azure App Service is a PaaS offering that can run containerized web apps, but its container support is best suited for a single container or a simple Docker Compose definition, not for orchestrating distributed microservices. It does not expose Kubernetes primitives like Pods, Services, or Ingress controllers, and its autoscaling is based on web app metrics or a scheduled profile, not application-level container scheduling. While it reduces management overhead by providing built-in web server integration and HTTPS, it lacks the granular deployment strategies and cluster-level service discovery that AKS offers, so it would be limiting for large-scale container-centric architectures.
D
Azure Container Instances
Why it fails: Azure Container Instances (ACI) provides a serverless environment to start an individual container or a small container group on demand, but it has no built-in orchestrator to manage multiple containers across virtual nodes. It cannot automatically scale the number of container replicas based on traffic, nor does it support rolling updates or advanced placement policies—you would have to manually tear down and recreate containers to change an application version. ACI is ideal for a simply scheduled job or an event-driven burst workload, but it leaves all lifecycle and multi-container orchestration decisions to the developer, so it does not satisfy the requirement of running a containerized application without managing orchestration.

Question 14hardmultiple choice

Contoso Ltd. is a global e-commerce company running its online store on Azure. The application consists of: - Frontend: Azure App Service (Windows) in West US. - Backend: Azure Kubernetes Service (AKS) cluster in West US. - Database: Azure SQL Database (General Purpose, S2) in West US. - Cache: Azure Cache for Redis (Standard C1) in West US. - Storage: Azure Blob Storage (LRS) for product images.

Business continuity requirements: - RPO: 5 minutes for the database. - RTO: 1 hour for the entire application. - The solution must survive a complete West US region outage. - Budget is limited; minimize additional costs.

What should you recommend as the primary DR strategy?

Trap 1: Use Azure Backup for the database with 5-minute log backup…

Azure Backup restores data after an outage; it does not provide the automated regional failover and traffic redirection the 1-hour RTO demands, since recovery is manual and rebuild times exceed it. It is tempting because backup is the cheapest data-protection mechanism, and it would suit scenarios where only data durability matters and downtime is tolerable.

Trap 2: Deploy the entire application across two Azure Availability Zones…

Availability Zones protect against datacentre failure within West US, but a complete regional outage takes down every zone, so the RTO and survival requirement are unmet. It is tempting because zone redundancy is the low-cost, low-overhead resilience pattern, and would be correct when the requirement is zonal rather than regional failure.

Trap 3: Use Azure Site Recovery to replicate all VMs (including AKS nodes)…

Azure Site Recovery replicates VMs, but AKS nodes are managed and unsupported for ASR, and the limited budget cannot absorb a full standby region plus Redis geo-replication. It is tempting because ASR is the standard VM-level DR tool, and would be correct for IaaS workloads rather than managed PaaS services.

A
Deploy a secondary region (East US) with a passive AKS cluster (minimal node count), a standby App Service plan (same tier), and a secondary Azure SQL Database in an auto-failover group. Use Azure Traffic Manager for frontend and configure Azure Cache for Redis with geo-replication. For Blob Storage, enable geo-redundant storage (GRS).
A passive secondary region with auto-failover groups meets the 5-minute database RPO and 1-hour RTO, while Traffic Manager, Redis geo-replication and GRS cover the remaining tiers. Minimal AKS nodes and a standby plan keep costs low, satisfying the limited-budget constraint.
B
Use Azure Backup for the database with 5-minute log backup frequency. For the app, use Azure App Service backup with frequency to a secondary region. For AKS, back up persistent volumes using Azure Backup. Restore everything in a secondary region during disaster.
Why it fails: Azure Backup restores data after an outage; it does not provide the automated regional failover and traffic redirection the 1-hour RTO demands, since recovery is manual and rebuild times exceed it. It is tempting because backup is the cheapest data-protection mechanism, and it would suit scenarios where only data durability matters and downtime is tolerable.
C
Deploy the entire application across two Azure Availability Zones within West US. Use zone-redundant storage for blobs, zone-redundant App Service plan, and zone-redundant AKS. For SQL Database, use a zone-redundant configuration. For Redis, use Enterprise tier with zone redundancy.
Why it fails: Availability Zones protect against datacentre failure within West US, but a complete regional outage takes down every zone, so the RTO and survival requirement are unmet. It is tempting because zone redundancy is the low-cost, low-overhead resilience pattern, and would be correct when the requirement is zonal rather than regional failure.
D
Use Azure Site Recovery to replicate all VMs (including AKS nodes) to a secondary region. For the database, use Azure SQL Database active geo-replication. For Azure Cache for Redis, replicate data via geo-replication. Use Azure Traffic Manager for frontend traffic routing.
Why it fails: Azure Site Recovery replicates VMs, but AKS nodes are managed and unsupported for ASR, and the limited budget cannot absorb a full standby region plus Redis geo-replication. It is tempting because ASR is the standard VM-level DR tool, and would be correct for IaaS workloads rather than managed PaaS services.