Auto Scaling practice questions

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 wrong: 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 wrong: 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 wrong: 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 2mediummultiple 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 wrong: 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 wrong: 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 wrong: 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 3hardmultiple 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 wrong: 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 wrong: 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 wrong: 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 4hardmultiple 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…

Backup cannot meet 1-hour RTO because restore takes time.

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

Availability Zones do not protect against a regional outage.

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

ASR for AKS is not supported; also potentially more expensive.

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).
This meets the RPO/RTO with minimal cost by using a passive standby.
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 wrong: Backup cannot meet 1-hour RTO because restore takes time.
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 wrong: Availability Zones do not protect against a regional outage.
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 wrong: ASR for AKS is not supported; also potentially more expensive.

Question 5easymultiple 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 6mediummultiple choice

A company wants to deploy containerized microservices on Azure without managing virtual machines. The solution must support automatic scaling based on demand, built-in load balancing, rolling updates for zero-downtime deployments, and a fully managed platform. Which Azure compute service should they choose?

Trap 1: Azure Container Instances

Azure Container Instances (ACI) launches a single container or a small container group in seconds, but it lacks the managed orchestration services of a microservices platform: no built-in HTTP-based autoscaling, no service discovery, no load balancing across replicas, and no revision-based rolling updates. It is better suited for isolated tasks or ephemeral burst workloads than for a multi-service application that must scale each service independently and update safely.

Trap 2: Azure Batch

Azure Batch is a job-scheduling and pool-management service designed for large-scale parallel and high-performance computing, where tasks are queued and executed across a configurable pool of virtual machines. It has no native concepts for serving long-running microservices such as per-service ingress, rolling update strategies, or automatic horizontal scaling driven by HTTP traffic, so it forces an architecture of separate batch queues and worker pools instead of continuous service-to-service communication.

Trap 3: Azure Functions

Azure Functions is a serverless execution environment driven by discrete triggers such as HTTP requests, queue messages, and timers, and it is optimized for short-running, single-purpose compute rather than for hosting containerized microservices with traffic forwarding, sidecars, and revision-level rollout control. Even when custom containers are used, the underlying model remains event-driven and stateless, which means adopting it for a microservice workload requires refactoring to a function-per-operation style and losing the container-native lifecycle automation that Container Apps offers.

A
Azure Container Apps
Azure Container Apps is a serverless platform for running containers. It provides automatic scaling based on HTTP traffic or events, built-in load balancing, and supports rolling updates via revisions. It abstracts away underlying infrastructure, so no VMs to manage.
B
Azure Container Instances
Why wrong: Azure Container Instances (ACI) launches a single container or a small container group in seconds, but it lacks the managed orchestration services of a microservices platform: no built-in HTTP-based autoscaling, no service discovery, no load balancing across replicas, and no revision-based rolling updates. It is better suited for isolated tasks or ephemeral burst workloads than for a multi-service application that must scale each service independently and update safely.
C
Azure Batch
Why wrong: Azure Batch is a job-scheduling and pool-management service designed for large-scale parallel and high-performance computing, where tasks are queued and executed across a configurable pool of virtual machines. It has no native concepts for serving long-running microservices such as per-service ingress, rolling update strategies, or automatic horizontal scaling driven by HTTP traffic, so it forces an architecture of separate batch queues and worker pools instead of continuous service-to-service communication.
D
Azure Functions
Why wrong: Azure Functions is a serverless execution environment driven by discrete triggers such as HTTP requests, queue messages, and timers, and it is optimized for short-running, single-purpose compute rather than for hosting containerized microservices with traffic forwarding, sidecars, and revision-level rollout control. Even when custom containers are used, the underlying model remains event-driven and stateless, which means adopting it for a microservice workload requires refactoring to a function-per-operation style and losing the container-native lifecycle automation that Container Apps offers.