One of the most common challenges in AZ-305 preparation is deciding which Azure compute service fits a scenario when several options appear technically possible.

Azure compute design is the process of matching workload requirements to the right execution model: infrastructure as a service with virtual machines, managed platform hosting with App Service, orchestrated containers with AKS, event-driven serverless execution with Functions, or application-centric containers with Container Apps. The AZ-305 exam expects candidates to reason through those choices in the context of scalability, availability, operations, governance, networking, and security.

Last updated: June 2026. This guidance reflects the current naming used across Azure, including Microsoft Defender for Cloud and Microsoft Entra ID. It also accounts for design-relevant platform capabilities such as Azure Container Apps, Azure Functions Premium plan behavior, zone-aware service designs, private networking patterns, and modern container deployment options.

Why compute selection matters in AZ-305

AZ-305 is less concerned with memorizing service descriptions than with applying constraints to architectural decisions. A scenario may mention regulatory data locality, strict recovery objectives, existing Windows Server licensing, containerized microservices, private connectivity, or a small operations team. Those details are not background noise; they are often the clues that point toward or away from a compute option.

The practical distinction is not simply IaaS versus PaaS versus containers. Team maturity and change velocity often decide the design. A team that ships a conventional web application weekly may gain more from deployment slots and managed scaling in App Service than from operating Kubernetes. By contrast, a platform team with established SRE practices, container security tooling, and multiple microservices may justify AKS because it needs orchestration control and workload portability.

Structured preparation should therefore connect service features to design trade-offs. An AZ-305 training course from Readynez can be useful when learners need guided scenario practice, but the core skill is still architectural reasoning: identifying the constraint that matters most and choosing the service that reduces risk rather than adding unnecessary complexity.

The main Azure compute options

Azure Virtual Machines provide the most control over the operating system, runtime, installed software, patching model, and network placement. They are often appropriate when an application depends on a specific OS configuration, legacy middleware, custom agents, persistent local behavior, or lift-and-shift migration constraints. That control also creates operational responsibility: patching, image management, backup, monitoring, and scaling must be designed rather than assumed.

Azure App Service fits many web applications and APIs where the team wants managed hosting, built-in deployment workflows, scaling without VM administration, and straightforward integration with platform services. It is especially strong for applications that need predictable HTTP hosting rather than full infrastructure control. Deployment slots are a major design advantage because they support safer release patterns without requiring a separate orchestration platform.

Azure Kubernetes Service is suited to containerized applications that need Kubernetes primitives, multi-service orchestration, custom ingress patterns, service mesh integration, workload identity, node pool control, or portability across environments. It is a powerful option, but premature AKS adoption is a common design error. Kubernetes reduces some deployment friction but introduces cluster lifecycle, upgrade, security, networking, and observability responsibilities that simpler services avoid.

Azure Functions is a strong fit for event-driven workloads: queue processing, scheduled jobs, event routing, lightweight APIs, file processing, and automation. The key design question is not whether serverless is convenient, but whether the workload can tolerate the execution model. Cold-start sensitivity, long-running tasks, network isolation, dependency loading, and throughput predictability may push the design toward Premium or dedicated hosting rather than a consumption-only assumption.

Azure Container Apps sits between App Service simplicity and AKS control. It is designed for containerized apps, background workers, and microservices that benefit from managed scaling, revisions, ingress, and event-driven scale behavior without requiring direct cluster management. It is often a practical answer when a team wants containers but does not need to own Kubernetes operations.

A practical compute-selection framework

The cleanest way to choose compute is to start with constraints rather than service preference. AZ-305 scenarios often describe requirements in business language, so the architect has to translate them into platform implications. OS control, stateful workload behavior, networking isolation, operational maturity, release cadence, scaling pattern, and cost model should all shape the decision.

• Choose VMs when the workload requires OS-level control, legacy dependencies, custom agents, specialized migration patterns, or stateful behavior that is not ready for managed platform hosting.
• Choose App Service when the workload is a web app or API that benefits from managed hosting, deployment slots, platform scaling, Private Endpoints, and reduced infrastructure administration.
• Choose AKS when Kubernetes is a requirement because of complex microservices, custom orchestration, node pool needs, platform engineering standards, or portability requirements.
• Choose Functions when execution is event-driven, intermittent, message-based, or scheduled, and when the hosting plan can meet latency, networking, and duration requirements.
• Choose Container Apps when the team wants container packaging, revisions, ingress, and event-driven scaling without taking on full Kubernetes cluster operations.

The decision tree below assumes a general enterprise application rather than specialized high-performance computing, Azure Virtual Desktop, or dedicated SAP sizing. It also assumes the workload can be deployed to a supported Azure region and that data services are evaluated separately.

Start
 |
 |-- Need full OS control, custom agents, or legacy install dependencies?
 |       |-- Yes --> Azure Virtual Machines
 |       |-- No
 |
 |-- Is the workload primarily an HTTP web app or API?
 |       |-- Yes --> App Service, unless container orchestration is required
 |       |-- No
 |
 |-- Is the workload event-triggered, scheduled, or message-driven?
 |       |-- Yes --> Azure Functions; use Premium/dedicated hosting if latency or VNet needs require it
 |       |-- No
 |
 |-- Is Kubernetes itself required by platform, orchestration, or portability needs?
 |       |-- Yes --> AKS
 |       |-- No --> Azure Container Apps for managed container hosting

Availability, cost, and governance trade-offs

Availability design differs across compute services, so it is risky to treat “host it in Azure” as a complete resilience strategy. App Service designs may use zone-redundant plans where supported, while AKS designs can spread node pools across availability zones and require careful handling of pod disruption, ingress, and state. Functions Premium can use pre-warmed instances to reduce latency risk, while VMs may require availability zones, scale sets, load balancers, backup, and recovery planning.

SLA composition is another common exam pitfall. A workload’s availability is shaped by every dependency in the request path: compute, database, identity, networking, DNS, gateway services, storage, and external integrations. Adding an Application Gateway, NAT Gateway, API Management, or private endpoint pattern may be necessary for security and routing, but each dependency still has to be included in the design conversation.

Cost decisions are also more subtle than instance size. VMs and some App Service scenarios may benefit from savings plans, reservations, or Azure Hybrid Benefit when licensing and usage patterns qualify. Functions and Container Apps can reduce idle compute spend when workloads are intermittent, but high event volume, always-on behavior, storage transactions, observability, and network egress can change the economics. Container workloads in particular can accumulate unexpected cost through ingress controllers, gateways, logging volume, image scanning, and cross-zone or outbound traffic.

Governance should be designed early because compute sprawl is easy to create and hard to unwind. Tags, Azure Policy, budgets, management groups, Microsoft Defender for Cloud recommendations, managed identities, and Microsoft Entra ID access controls help keep design choices aligned with security and financial boundaries. In practice, a well-governed App Service or Container Apps deployment can be safer than an under-managed AKS cluster, even if the latter appears more flexible on paper.

Networking and security often decide the answer

Network integration is one of the strongest signals in compute design. App Service and Functions support private access patterns through Private Endpoints and outbound connectivity through VNet Integration, but they do not provide the same low-level network control as VMs or AKS. VMs and AKS can sit fully inside a virtual network with more direct control over subnets, route tables, network security groups, firewall inspection, and outbound paths.

Those choices create practical implementation work. Private Endpoints require DNS planning so applications resolve private addresses correctly. Locked-down outbound traffic requires route and firewall design. Platform services that appear simple in a public networking model can become more complex when the design requires private-only access, hybrid name resolution, ExpressRoute, or centralized inspection.

The following Bicep-style fragment illustrates the kind of design detail that sits behind a simple phrase such as “integrate the web app with a virtual network.” It is not a full deployment template, but it shows that networking capability must be planned alongside the compute service.

resource webApp 'Microsoft.Web/sites@2023-12-01' existing = {
  name: appName
}

resource vnetIntegration 'Microsoft.Web/sites/virtualNetworkConnections@2023-12-01' = {
  name: '${webApp.name}/${vnetName}'
  properties: {
    vnetResourceId: subnetResourceId
    isSwift: true
  }
}

Functions has similar design implications. A queue-triggered function may look simple until the scenario adds private storage access, predictable startup latency, or consistent throughput. In those cases, a Premium plan with pre-warmed capacity may be a better match than a consumption-only design.

az functionapp plan create \
  --name fn-premium-plan \
  --resource-group rg-app \
  --location westeurope \
  --sku EP1 \
  --min-instances 1

Scenario one: modernising a legacy web application

Consider a business-critical web application currently running on Windows Server with a SQL database, scheduled background jobs, and a small operations team. The organisation wants better release control and reduced server administration, but the application still has a few legacy dependencies and must connect privately to data services.

A weak design would move everything into AKS simply because containers are part of the long-term roadmap. That creates cluster operations work before the application is ready to benefit from orchestration. A more balanced design may start with App Service for the web tier, Azure SQL or SQL Managed Instance depending on database compatibility, deployment slots for release safety, Private Endpoints for data access, and a separate Functions or WebJobs pattern for background processing.

Users
  |
  v
Azure Front Door or Application Gateway
  |
  v
App Service Plan (zone-aware where supported)
  |        \
  |         \-- Deployment slot for staged releases
  |
  v
Private Endpoint + Private DNS
  |
  v
Azure SQL / SQL Managed Instance
  |
  v
Microsoft Defender for Cloud recommendations + Azure Monitor logs

This architecture reduces operating-system maintenance while preserving a migration path. If the legacy dependency cannot be removed immediately, a VM can temporarily host that component behind private networking. Once the dependency is eliminated, the team can decide whether the application remains best suited to App Service or whether container packaging through Container Apps provides a better release and scaling model.

Scenario two: event-driven processing

Now consider an order-processing workload that receives events from an application, validates them, enriches data, stores results, and notifies downstream systems. Traffic is bursty, and most processing is independent. The business wants low operational overhead, but some integrations must remain private and latency spikes during peak periods are unacceptable.

Functions is the natural starting point because the workload is event-driven. The design might use Service Bus for durable messaging, Azure Functions Premium for predictable startup and VNet integration, managed identity for access to storage and secrets, and Application Insights for telemetry. If processing later becomes a long-running containerized worker with custom dependencies, Container Apps may become a better fit while preserving event-driven scaling behavior.

Application emits event
  |
  v
Service Bus queue or topic
  |
  v
Azure Functions Premium plan
  |       |
  |       +-- Managed identity to access Key Vault and data services
  |
  v
Private Endpoint to storage/database
  |
  v
Downstream notification or API

The anti-pattern here is treating serverless as automatically cheaper or simpler. A poorly bounded function that retries aggressively, logs excessive payloads, or depends on slow downstream APIs can become unreliable and costly. The better design sets retry policies, poison-message handling, monitoring, idempotency rules, and clear limits on execution duration before the workload reaches production.

Common anti-patterns in Azure compute design

Many weak Azure designs begin with a technology preference rather than a workload constraint. AKS is chosen for a simple web app, VMs are over-provisioned because the team fears scaling events, or Functions are used for long-running workflows that would be better handled by durable orchestration or a worker model. These mistakes often look acceptable in a diagram but create operational problems after deployment.

Another frequent issue is ignoring private networking until late in the design. App Service, Functions, Container Apps, AKS, and VMs can all participate in private architectures, but the implementation details differ. DNS zones, outbound routes, service endpoints or Private Endpoints, firewall rules, and identity flows should be validated early because they can change the compute choice or the hosting plan.

Exam scenarios often reward the same discipline. If the wording emphasizes OS-level control, legacy software, or lift-and-shift speed, VMs may be the intended direction. If it emphasizes managed web hosting and staged releases, App Service is often the cleaner fit. If it emphasizes event triggers and intermittent execution, Functions may be appropriate. If it emphasizes Kubernetes-native operations, multi-container orchestration, and platform engineering standards, AKS becomes more defensible.

Where compute design fits in AZ-305 study

Compute selection is connected to several other AZ-305 design areas. Identity choices affect managed identities and Microsoft Entra ID integration. Networking choices affect private access, name resolution, routing, and inspection. Business continuity choices affect zones, regions, backups, and recovery workflows. Cost governance affects reserved capacity, budgets, scale behavior, and licensing benefits.

The most effective study method is scenario mapping. A candidate should take a workload description and identify the decisive constraints before looking at answer choices. That habit mirrors real design work: the right compute platform is not the one with the most features, but the one that satisfies the requirements with the least unnecessary operational burden.

FAQ

What Azure compute services should AZ-305 candidates understand?

AZ-305 candidates should understand how to design with Azure Virtual Machines, Azure App Service, Azure Kubernetes Service, Azure Functions, and Azure Container Apps. They should also understand when related services such as Azure Virtual Desktop, scale sets, load balancers, private networking, and managed identity affect the compute design.

How should an architect choose between VMs, App Service, AKS, Functions, and Container Apps?

The decision should begin with workload constraints. VMs fit OS control and legacy dependencies, App Service fits managed web apps and APIs, AKS fits Kubernetes-driven orchestration needs, Functions fits event-driven execution, and Container Apps fits managed container workloads that do not require direct cluster ownership.

Is AKS the right default for containerized applications?

No. AKS is appropriate when the organisation needs Kubernetes capabilities and has the operational maturity to manage clusters, node pools, upgrades, security, and observability. For many containerized applications, Container Apps or App Service for containers can provide a simpler operating model.

How important is hands-on practice for AZ-305 compute design?

Hands-on practice is important because compute questions are usually scenario-led. Working through designs that include networking, identity, availability, scaling, and cost constraints helps candidates recognise which service characteristics matter in an exam scenario.

What cost factors are easy to miss in Azure compute design?

Commonly missed factors include idle capacity, reserved capacity or savings plan options, Azure Hybrid Benefit eligibility, logging volume, gateway and ingress costs, private networking dependencies, cross-zone or outbound traffic, and the cost of running supporting services around the compute layer.

Building better compute decisions

Good Azure compute design starts by resisting premature commitment to a platform. VMs, App Service, AKS, Functions, and Container Apps are all valid choices, but each one optimises for a different balance of control, operational effort, scaling behavior, networking integration, and release management.

The key takeaway for AZ-305 is to read scenarios as sets of constraints. Regulatory requirements, RTO and RPO expectations, OS control, team maturity, private connectivity, and release patterns usually narrow the answer before service preference enters the discussion. A practical next step is to compare recent architecture decisions against those constraints and, where structured preparation is needed, use Readynez only as a supplement to hands-on Azure design practice and Microsoft’s official exam guidance.