AZ-104 · Deploy and manage Azure compute resources · Updated August 7, 2026
Azure Container Instances vs Container Apps vs AKS: Choosing the Right Container Compute
Azure gives you three distinct ways to run a container, and they sit on a deliberate spectrum of control versus convenience. Azure Container Instances (ACI) runs one or more containers as a single unit with almost no platform on top of them. Azure Container Apps adds a managed application layer, built on Kubernetes primitives under the hood, with event-driven autoscaling and microservice features baked in. Azure Kubernetes Service (AKS) hands you the Kubernetes control plane itself. AZ-104 tests this domain lightly compared to AZ-104’s VM and networking objectives, but it expects you to know which of the three a scenario is describing and, for ACI specifically, several details Microsoft has changed recently.
Azure Container Instances: a container group, nothing more
ACI’s core unit is the container group: containers scheduled onto the same host that share a lifecycle, network namespace, and storage volumes, similar in spirit to a Kubernetes pod but without a cluster or control plane behind it. You define CPU, memory, and OS type, and Azure runs it. There’s no built-in load balancer, no autoscaling, and no orchestration layer: to run five instances of a container, you deploy five separate container groups yourself.
That simplicity is the point. ACI fits workloads that are short-lived, bursty, or don’t justify an application platform: a CI/CD build agent spun up on demand, a batch job triggered by an event, or a task container that starts fast and disappears when done. Microsoft describes ACI as a lower-level “building block” compared to Container Apps, and other services, including AKS through virtual nodes, sometimes use ACI underneath rather than as a general application runtime.
Two ACI specifics changed recently enough that older study material gets them wrong, and both matter for AZ-104:
GPU support in ACI was retired on July 14, 2025. ACI previously offered a preview GPU resource type (V100-based), but that capability is no longer available. If a scenario needs GPU-backed containers, ACI is not the answer regardless of how the question is phrased. AKS node pools or dedicated VM-based GPU compute are the current paths for that requirement.
Deploying a container group into a virtual network now requires a NAT gateway for outbound connectivity. This is the only supported configuration for outbound traffic from a VNet-integrated container group; there’s no default outbound path the way there is for some other Azure compute options. If a scenario describes an ACI container group in a VNet that needs to reach the internet, the missing piece to add is a NAT gateway, not a public IP on the container group or a route table trick. Subnets used for container groups must also be delegated to ACI before deployment, and only container groups can live in that delegated subnet.
Azure Container Apps: managed microservices with KEDA and Dapr
Azure Container Apps is a serverless application platform for running containers without managing a cluster. It’s built on Kubernetes and open-source projects, most notably KEDA for event-driven autoscaling and Dapr for microservice building blocks, but it deliberately doesn’t expose the Kubernetes API or control plane to you. That’s the core tradeoff versus AKS: Container Apps gives you application-level concepts (revisions, traffic splitting, service discovery, environments, ingress with automatic HTTPS) as managed features, in exchange for giving up direct Kubernetes API access.
Autoscaling is triggered by HTTP traffic, CPU or memory load, or any KEDA-supported scaler, which covers a large catalog of event sources such as queue depth. Most applications can scale to zero when idle, meaning you pay nothing for compute during quiet periods; the exception is apps scaled purely on CPU or memory load, which can’t scale to zero since there’s no idle-load signal to trigger it. That scale-to-zero behavior differentiates it from ACI, where every container group you deploy runs, and bills, until you explicitly stop it.
Dapr integration is the other headline feature: enabling it on a Container Apps environment gives microservices access to Dapr’s building blocks for service invocation, state management, and pub/sub messaging without standing up that infrastructure yourself. Combined with revisions (multiple app versions running side by side) and traffic splitting, Container Apps supports blue/green deployments and A/B testing that neither ACI nor a bare VM easily handles. It also runs Azure Functions and scheduled or event-driven jobs, making it a broader “run containers as an application” platform than ACI’s “run containers as a unit” model.
AKS in AZ-104 scope: full Kubernetes control, lightly tested
Azure Kubernetes Service provides a fully managed Kubernetes control plane, with direct access to the Kubernetes API and the ability to run any Kubernetes workload, including custom controllers, operators, and Helm charts that assume a real cluster underneath. AKS ships in two experience models: AKS Standard, where the cluster resource lives in your subscription and you manage its configuration directly, and AKS Automatic, where Azure preconfigures and manages node provisioning, scaling, security defaults, and upgrades for a more hands-off, production-ready starting point.
AZ-104’s compute domain treats AKS lightly: expect it as one option among several in a “which compute service fits this scenario” question, not a deep dive into cluster networking or pod scheduling. The signal to watch for is any requirement for direct Kubernetes API access, custom resource definitions, or Kubernetes-native tooling. If a scenario states that requirement explicitly, AKS is the answer even if Container Apps could technically host similar containers, since Container Apps intentionally doesn’t expose that control plane.
ACI vs Container Apps vs AKS
| Azure Container Instances | Azure Container Apps | Azure Kubernetes Service | |
|---|---|---|---|
| Management unit | Container group | Managed app/environment | Full Kubernetes cluster |
| Autoscaling | None (deploy more groups manually) | Built in, KEDA-based, scale to zero for most triggers | Yes, cluster autoscaler and pod autoscaling, you configure it |
| Kubernetes API access | No | No | Yes, direct access |
| Microservice features (Dapr, revisions, traffic split) | No | Yes | Available via add-ons/manual setup |
| GPU support | Retired July 14, 2025 | Limited via specialized hardware plans | Yes, via GPU-enabled node pools |
| VNet outbound connectivity | Requires a NAT gateway | Supported via environment VNet integration | Standard AKS networking models |
| Best fit | Short-lived, single-unit, or burst workloads | Event-driven microservices without cluster management | Workloads needing direct Kubernetes control |
How the AZ-104 exam tests this
- A scenario describes a single, short-lived container task, like a build step or an on-demand batch job, with no need for scaling or load balancing: ACI is the answer.
- A scenario mentions GPU-accelerated containers: rule out ACI, since GPU support there was retired in July 2025; look toward AKS GPU node pools instead.
- A scenario describes a container group deployed into a virtual network that also needs outbound internet access: the missing component is a NAT gateway, since that’s the only supported outbound path for VNet-integrated ACI.
- A scenario describes microservices that need to scale based on queue depth or HTTP load, scale to zero when idle, and use service-to-service communication without standing up custom infrastructure: Container Apps, specifically its KEDA autoscaling and Dapr integration.
- A scenario explicitly requires direct access to the Kubernetes API, custom controllers, or Helm-based deployments: AKS, not Container Apps, since Container Apps deliberately doesn’t expose the Kubernetes control plane.
- A scenario asks for blue/green deployment or A/B testing of container versions with traffic splitting: Container Apps’ revisions feature, not a manual ACI deployment.
Quick reference
- ACI runs container groups directly with no orchestration, autoscaling, or load balancing layered on top; you scale by deploying more groups.
- ACI GPU support (V100-based, preview) was retired on July 14, 2025; it’s not a current option for GPU workloads.
- ACI container groups deployed into a VNet require a NAT gateway for outbound connectivity; it’s the only supported outbound path, and the subnet must be delegated to ACI first.
- Container Apps is a managed, Kubernetes-powered application platform with KEDA-based autoscaling (including scale to zero for most trigger types) and optional Dapr integration for microservices, without exposing the Kubernetes API.
- AKS provides direct Kubernetes API access and full cluster control, available as AKS Standard (you manage it) or AKS Automatic (Azure manages more of it); pick AKS when a scenario explicitly needs Kubernetes-native tooling.
For the infrastructure-as-code side of deploying any of these compute options consistently, see ARM templates vs Bicep. For the networking layer ACI’s VNet deployment model builds on, see Azure VNet peering explained. For the full map of AZ-104’s compute, networking, storage, and identity domains, start with the AZ-104 study guide.