The compute design domain in the AZ-305 Solutions Architect Expert exam is packed with questions you cannot answer by memorizing services alone. The correct answer shifts based on combinations of requirements: "migrate without code changes," "eliminate Kubernetes management overhead," or "process events without any servers." This guide distills patterns from 49 real AZ-305 exam questions to map each service's selection criteria and expose the most common wrong-answer traps.
---
VM and Virtual Machine Scale Sets (VMSS)
The decisive signal for choosing a VM is legacy dependency. When Windows OS runtime-level components appear — COM components, COM+, or ActiveX — migration to PaaS is not possible. When high-availability requirements come alongside, you choose between Availability Sets and Availability Zones.
Availability Sets: Distributes VMs across fault domains (up to 3) and update domains (up to 20) within the same datacenter. 99.95% SLA, no extra cost. Availability Zones: Deploys VMs across physically separate datacenters within a region. 99.99% SLA, protects against complete datacenter failure.
VM series selection also appears on the exam. For dev/test environments with irregular peaks, Bsv2 (burstable) — the CPU credit accumulation model keeps costs significantly lower. For workloads that need a high memory ratio, such as SQL Server, Ev5 (memory-optimized) — includes SR-IOV accelerated networking by default and also reduces SQL Server licensing costs. When compliance-grade hardware isolation is required, combine Azure Dedicated Host with VMSS and Availability Zones.
VMSS automatically scales identical VMs up and down based on metrics such as CPU utilization, supporting up to 1,000 instances on the standard plan.
---
App Service and Web Workloads
There are three selection signals for App Service: migrate without code changes, delegate OS management to Azure, and need for automatic scaling. When all three keywords appear together, the answer is almost always App Service. It natively supports Java, Python, .NET, and Node.js runtimes and provides local temporary storage ( on Windows, on Linux), so even on-premises apps that use temp files can be migrated without code modifications.
For multi-region deployments, remember that an App Service Plan is bound to a specific Azure region. To deploy independently across Europe, North America, and APAC, separate Plans per region are required. For regulated environments that need full isolation with a dedicated VNet subnet, consider App Service Environment (ASE v3) — but note that even an empty environment incurs a base fee of over $1,000 per month.
Deployment Slots swap is all about zero-downtime instant switchover. After validating a staging slot in an environment identical to production, swapping it brings warmed-up instances online to receive traffic within seconds. This feature is available only on the Standard tier and above. For progressive canary deployments, adjust the slot traffic percentage or use Traffic Manager.
---
Serverless: Functions and Logic Apps
Choosing an Azure Functions hosting plan is a recurring AZ-305 topic.
Consumption plan: Billing per execution count times duration, with 1 million free executions per month. No cost during idle periods. However, maximum execution time is 10 minutes, cold starts occur, and VNet integration is not supported. Premium plan: Pre-warmed instances eliminate cold starts. Execution time can be set to unlimited. Supports VNet integration. When you see all three — no cold starts, executions over 10 minutes, VNet integration — the answer is Premium. Dedicated plan: Runs on top of an App Service Plan. Server management overhead exists, but existing Plan resources can be shared.
HTTP trigger authorization levels are also tested. allows anyone to call without a key, making it suitable for public data APIs. requires a function key, and requires the master key. The array restricts which HTTP methods are allowed; methods not listed automatically receive a 405 response.
---
Container Workloads: Container Apps and AKS
Container Apps vs AKS
The key criterion is the level of Kubernetes control needed. If the requirement is "run containers without managing Kubernetes and minimize operational overhead," choose Azure Container Apps. If direct Kubernetes control is required, choose AKS.
Container Apps provides KEDA-based autoscaling and Dapr integration out of the box, with node pools, kubectl, and cluster upgrades fully abstracted away. AKS is used for advanced scenarios that require an Istio service mesh, network policies, or custom runtimes.
Several AKS advanced topics appear frequently on the exam.
KEDA: A Kubernetes-native autoscaling tool supporting over 50 scalers including Azure Queue Storage, Event Hubs, and Service Bus. The key capability is scale to zero — when there are no messages in a queue, pods scale down to zero. HPA alone requires at least one pod, but KEDA enables zero. Virtual Node + ACI: Used when AKS needs to burst instantly without provisioning VMs. Connecting ACI as a virtual node starts containers within tens of seconds. Supports Linux containers only. Istio service mesh: The right choice when you need canary deployment (traffic weighting), header-based routing, and mTLS inter-service encryption all at once. Dapr: The State Management API provides a unified interface to Redis, Cosmos DB, and Azure Table Storage. The Pub/Sub API abstracts message brokers. Swapping a YAML config file lets you change storage or broker without touching code. ACR Geo-replication: Supported only on Premium-tier ACR. Automates image replication for multi-region AKS clusters and ensures each region pulls images from its nearest replica.
!Container Apps versus AKS
Service Comparison Table
| Service | Cost Model | Scaling | Operational Complexity | Key Selection Signal | |---------|-----------|---------|----------------------|---------------------| | VM | Instance hours | Manual or VMSS | High | COM/ActiveX legacy, hardware isolation | | VMSS | Instance hours | Automatic (metrics) | Medium | Auto scale identical VMs | | App Service | Plan hours | Automatic (instance count) | Low | Lift-and-shift web apps without code changes | | Container Apps | Execution time + requests | KEDA automatic (incl. 0) | Low | Run containers without K8s management | | AKS | Node VM hours | HPA/KEDA/Cluster Autoscaler | High | Direct K8s control, service mesh | | Functions (Consumption) | Executions x duration | Automatic (serverless) | Very Low | Irregular events, short executions | | Functions (Premium) | Min instances + usage | Automatic (pre-warmed) | Low | No cold starts, VNet integration |
---
Selection Criteria That Trip People Up on the Exam
Large-Scale Parallel Processing
For workloads that process thousands of independent tasks in parallel — 3D rendering, genomics analysis, financial simulation — Azure Batch is the answer. It has built-in task queuing, scheduling, and VM pool autoscaling, and scales back to zero when work is done. If you need to integrate with third-party HPC job schedulers (PBS Pro, Slurm, LSF), choose Azure CycleCloud. For Batch node types, use Spot VMs for interruption-tolerant dev workloads (up to 90% savings) and Dedicated VMs for long-running production.
Migration Tools
Azure Migrate: An integrated platform for discovering, assessing, and migrating on-premises workloads to Azure. A VMware appliance collects VM performance data agentlessly and calculates the right-sized SKU and estimated cost. Azure Resource Mover: Used to move existing resources between subscriptions or regions within Azure. Do not confuse this with on-premises migration. Azure DMS (online mode): Continuously synchronizes SQL Server to Azure SQL Managed Instance via CDC, limiting cutover downtime to minutes. DMA + DMS combination: Pre-assess SQL schema compatibility with DMA, then perform the actual data migration with DMS. Azure Data Factory: Used for migrations between heterogeneous data sources, such as SQL Server to Cosmos DB (NoSQL). DMS is for relational-to-relational migrations only.
Hybrid Microservices
When the requirement is a microservices platform running on-premises and in Azure simultaneously with ultra-low latency, Azure Service Fabric is the answer. You can deploy the same cluster across on-premises datacenters and Azure cloud, processing millions of instances at millisecond latency.
---
Practical Tips for Real-World Application
Classifying by workload pattern is the fastest approach. Need OS-level access → VM. PaaS web app → App Service. Containers but want to avoid K8s management → Container Apps. Full K8s control → AKS. Short, irregular events → Functions.
Keep cost optimization patterns in mind too. Low average CPU with irregular peaks → Bsv2 burstable. Interruption-tolerant batch → Spot VM (up to 90% savings). Irregular HPC → Azure Batch. Zero cost when no events → Functions Consumption.
High availability cannot be solved by a single service. Hardware isolation → Dedicated Host. Datacenter-level fault tolerance → Availability Zones. Distribution within the same datacenter → Availability Sets. These three are not mutually exclusive and can be combined.
---
Summary
Here are the key selection keywords for the AZ-305 compute design domain.
COM/ActiveX, legacy dependency → IaaS VM required No code changes + delegate OS management + autoscaling → App Service Zero-downtime instant deployment switch → Deployment Slots swap Public API + access without a key → Functions HTTP Trigger, authLevel: anonymous No cold starts + over 10 minutes + VNet integration → Functions Premium plan Containers without K8s management → Container Apps Direct K8s control, service mesh → AKS Queue-based autoscaling + scale to zero → KEDA Instant burst on AKS → Virtual Node + ACI Large-scale parallel independent tasks → Azure Batch Third-party HPC scheduler integration → A