AZ-305 App Service vs Functions vs Container Apps vs AKS: Compute Hosting Guide

For AZ-305 compute-hosting questions, choose the service from the workload shape. Use Azure App Service for managed web apps and APIs. Use Azure Functions for event-driven code and trigger-based work. Use Azure Container Apps for serverless containers, microservices, jobs, revisions, and scale-to-zero patterns without Kubernetes API control. Use AKS when the requirement is direct Kubernetes control, custom orchestration, or a platform team that can operate Kubernetes. Use Azure VMs when the workload needs OS-level control, legacy software, custom agents, or lift-and-shift constraints.

That scope is current: Microsoft says the English AZ-305 exam was updated on April 17, 2026, and Design infrastructure solutions is weighted 30-35% (AZ-305 exam page). The study guide includes compute objectives for VM-based, container-based, serverless-based, and batch-processing solutions (AZ-305 study guide).

Compact Decision Shortcut

Use this first pass before reading the answer choices:

• Web app, REST API, mobile back end, or simple web container: App Service.
• Queue, timer, blob, HTTP trigger, or small event workflow: Azure Functions.
• Containerized microservices, event-driven containers, revisions, jobs, traffic splitting, or scale to zero: Container Apps.
• Kubernetes APIs, custom controllers, cluster-level networking, or direct control plane needs: AKS.
• OS agent, unsupported runtime, domain-joined server dependency, or rehosted legacy app: VMs.
• Large parallel job, rendering, simulation, image processing, ETL, or HPC batch: Azure Batch.
• Single container group, fast startup, no full orchestration, and no app-platform features: Azure Container Instances.

The official Azure compute decision guide makes the same larger point: Azure has many ways to host application code, and distinct components in one solution can use different compute services (Choose an Azure compute service).

Decision Cards

Azure App Service

Reach for App Service when the scenario describes a managed web application, REST API, mobile back end, or straightforward web container. Microsoft describes App Service as a platform for web apps, mobile back ends, and RESTful APIs without managing the underlying infrastructure (App Service overview).

Boundary: do not pick App Service just because the workload has HTTP. If the scenario emphasizes many independently scaled containers, event-driven scale-to-zero behavior, Dapr/KEDA-style patterns, or Kubernetes control, compare Container Apps and AKS.

Azure Functions

Reach for Functions when the scenario is event-driven code: queue messages, file uploads, timers, HTTP triggers, glue logic, cleanup jobs, or short automation. Microsoft describes Functions as serverless compute with event-driven triggers and bindings (Azure Functions overview).

Boundary: Functions is not the default for every small app. If the requirement is a long-running web application, a full web API with predictable traffic, or coordinated containerized services, another host may fit better.

Azure Container Apps

Reach for Container Apps when the app is containerized and the scenario asks for serverless microservices, event-driven containers, jobs, revisions, traffic splitting, service discovery, or scale to zero. Microsoft says Container Apps supports Kubernetes-style apps and microservices, event-driven scaling, and scheduled or event-driven jobs, but does not provide direct Kubernetes API access (Container Apps comparison).

Boundary: Container Apps is not "AKS without tradeoffs." If the design depends on native Kubernetes APIs, custom controllers, cluster-level service mesh control, or direct control-plane access, AKS is the stronger answer.

Azure Kubernetes Service

Reach for AKS when the workload is containerized and the scenario requires Kubernetes APIs, custom orchestration, advanced platform control, portability across Kubernetes environments, or a team prepared to operate Kubernetes. Microsoft describes AKS as a managed Kubernetes service for deploying and managing containerized applications, with Azure managing the control plane while you run workloads on nodes (AKS overview).

Boundary: AKS is easy to over-select. If the question only asks for a managed web app, a simple API, or a few event-driven containers, AKS may add operational weight that the scenario did not justify.

Azure Virtual Machines

Reach for VMs when the scenario needs operating-system control, custom software installation, legacy services, migration without refactoring, unsupported runtimes, custom agents, or infrastructure-level configuration. Microsoft says VMs are typically chosen when you need more control over the computing environment, but you still maintain the VM by configuring, patching, and installing software (Azure VMs overview).

Boundary: VMs are not automatically wrong on AZ-305. They are wrong when the requirements fit a managed service and no OS-level control is needed.

Azure Batch

Reach for Azure Batch when the workload is job orchestration, not interactive hosting: large-scale parallel jobs, HPC, simulations, rendering, image processing, media transcoding, ETL, or many independent tasks. Microsoft says Batch creates and manages pools of compute nodes, installs applications, schedules jobs, and works well for intrinsically parallel workloads (Azure Batch overview).

Boundary: Batch is not a replacement for App Service, Functions, or Container Apps for request/response application hosting. Use it when the dominant requirement is scheduled or high-scale job execution.

Azure Container Instances

ACI matters because Microsoft includes it in the Azure compute decision guide and Container Apps comparison. Use it as a lower-level container building block when you need to run a single container group quickly without managing VMs or adopting a higher-level service (ACI overview). Microsoft’s Container Apps comparison says ACI lacks app-platform concepts such as scale, load balancing, certificates, revisions, and environments (Container Apps comparison).

Boundary: if the scenario needs application lifecycle management, event-driven scaling, certificates, revisions, or multiple service components, Container Apps is usually the better serverless container answer.

Worked Scenario: Claims Platform Modernization

An insurer is modernizing a claims platform:

• A public customer portal and internal adjuster API should run with minimal infrastructure management.
• Uploaded photos should trigger image validation and metadata extraction.
• Fraud scoring is packaged as a Linux container and receives bursty queue traffic.
• Several small containerized services need service discovery and independent revisions, but the team does not want Kubernetes operations.
• A legacy Windows service requires a vendor agent installed on the OS.
• Archived claims may later run through millions of overnight OCR and enrichment tasks.

Split the architecture before choosing services. The portal and adjuster API are managed web/API workloads, so App Service is the first candidate. Photo validation starts from storage or queue events, so Functions fits the trigger model. Fraud scoring and the small microservices are containerized, bursty, and need revision/service features without Kubernetes control, so Container Apps fits better than AKS. The vendor Windows agent is a real OS-control requirement, so use VMs for that legacy component. The future archive processing is a batch-processing problem; evaluate Azure Batch when the requirement becomes large-scale job scheduling, especially if the tasks are independent and parallel.

Exam-ready answer: App Service for the portal/API, Functions for photo-triggered validation, Container Apps for bursty containerized services, VMs for the vendor-agent dependency, and Azure Batch for the future high-scale OCR job. Do not force one platform across the whole application.

What Wrong Answers Reveal

Wrong compute choices are useful diagnostic signals:

• Choosing AKS for a simple web app means you over-weighted scalability or containers and missed operational simplicity.
• Choosing App Service for queue-triggered glue logic means you treated every component as web hosting.
• Choosing Functions for a long-running API means you confused serverless with "always best."
• Choosing Container Apps when Kubernetes APIs are explicit means you missed the control-plane boundary.
• Rejecting VMs when an OS agent is required means you treated PaaS as a rule instead of a preference.
• Ignoring Batch or ACI means you may be flattening every compute option into "app host" instead of separating jobs and container building blocks.

For each miss, write one sentence: "I picked the wrong host because I missed ____." That turns a vague compute weakness into a concrete remediation target.

How To Study This Without Memorizing A Matrix

Practice with five prompts:

• Is this web/API hosting, event-triggered execution, containerized microservices, full Kubernetes, OS-control IaaS, batch processing, or a one-off container group?
• What part of the stack must the team control?
• Is the workload always on, bursty, scheduled, or event-driven?
• Does the scenario ask for Kubernetes APIs, or only Kubernetes-style app features?
• Would a mixed architecture be simpler than forcing one platform?

Then change one requirement at a time. Add a vendor OS agent and see whether VMs become valid. Add direct Kubernetes API access and see whether AKS beats Container Apps. Replace an HTTP API with a queue-triggered task and see whether Functions becomes stronger. Add millions of independent overnight tasks and see whether Batch deserves its own boundary.

Where CramHQ Fits

CramHQ is not a Microsoft product and does not guarantee a pass. For this topic, CramHQ can help turn wrong hosting choices into a learning loop: identify whether the miss came from workload shape, trigger model, container orchestration, Kubernetes control, OS requirements, job scheduling, or over-engineering, then route practice and remediation around that boundary instead of rereading every compute page.

When you are ready, take the AZ-305 assessment. After each missed compute question, label the missed decision boundary, fix that one concept, and retest with nearby scenarios before moving to the next domain.

Quick Recap

Use App Service for managed web/API hosting, Functions for event-triggered code, Container Apps for serverless containerized apps and jobs without Kubernetes API control, AKS for Kubernetes-native requirements, VMs for OS-control constraints, Batch for large job orchestration, and ACI for simple container groups without full app-platform needs. AZ-305 rewards the simplest compute service that satisfies the requirement without hiding a real control constraint.