What is the difference between AKS and Azure Container Apps?

AKS gives you a managed Kubernetes cluster with full API access, node pool control, and the ability to install any Kubernetes tooling. Container Apps is a serverless platform built on Kubernetes that hides the cluster entirely: you deploy a container and Azure manages nodes, upgrades, and scaling, including scaling to zero.

Can Azure Container Apps scale to zero?

Yes. Setting minReplicas to zero allows the app to scale down completely when idle, which eliminates compute cost during quiet periods at the cost of a cold start of roughly two to five seconds on the next request. AKS cannot scale a deployment to zero without additional components such as KEDA installed on the cluster.

Does Container Apps support GPUs?

Container Apps offers serverless GPU support in a limited set of regions with specific GPU types. If a scenario requires a particular GPU SKU, multi-GPU nodes, or fine-grained scheduling control, AKS with a GPU node pool is the expected answer.

Is Container Apps cheaper than AKS?

For intermittent or bursty workloads, yes, because you pay only for consumed resources and can scale to zero. For sustained high-utilisation workloads running continuously, AKS with reserved instances is typically cheaper because you are not paying a serverless premium on always-on compute.

Which does the AI-200 exam favour?

Neither by default. The exam presents a constraint and expects you to choose accordingly. Scale to zero, minimal operational overhead, and built-in Dapr point to Container Apps. GPU node pools, custom CNI, Kubernetes operators, and node-level control point to AKS.

AKS vs Azure Container Apps: Choosing Correctly for AI-200

The underlying relationship

Azure Container Apps is built on Kubernetes, but the cluster is not exposed to you. There is no kubectl, no node access, and no Kubernetes API. Azure manages the control plane, the nodes, the upgrades, and the certificates.

AKS exposes the Kubernetes API in full. You manage node pools, choose the network plugin, install operators and CRDs, and control upgrade timing.

The trade is control against operational burden. Container Apps removes the burden by removing the control.

Comparison

Attribute	Azure Container Apps	Azure Kubernetes Service
Kubernetes API access	None	Full
Node management	Managed by Azure	You manage node pools
Scale to zero	Built in via minReplicas 0	Requires KEDA installed on the cluster
Autoscaling	KEDA built in: HTTP, CPU, memory, custom scalers	HPA, VPA, cluster autoscaler, KEDA optional
Networking	Environment-level VNet injection	kubenet, Azure CNI, CNI Overlay
Ingress	Built in, external or internal	Ingress controller you install and manage
Service mesh	Dapr built in	Istio add-on or self-managed
GPU	Serverless GPU, limited regions and SKUs	Full GPU node pool control
Traffic splitting	Built in via revision weights	Ingress controller or service mesh configuration
Upgrades	Automatic	You schedule and manage
Cost model	Per vCPU-second and GiB-second consumed	Per node hour; control plane free on the free tier
Operational overhead	Minimal	Significant

Container Apps — the exam-critical details

Revisions and revision modes

A revision is an immutable snapshot of the app configuration and image. In single revision mode only one revision is active at a time. In multiple mode several revisions run concurrently and you assign traffic weights across them.

Traffic splitting requires multiple mode. A scenario asking for a canary release or a percentage-based rollout is testing whether you know this prerequisite.

Scaling rules

HTTP — scales on concurrent requests per replica
CPU and memory — scales on resource utilisation; note that these cannot scale to zero
Custom KEDA scalers — Service Bus queue length, Event Hubs lag, Kafka, Redis, and many others

The queue-depth scaler is the canonical answer for a worker that should be idle and free when there is nothing to process.

Environments

A Container Apps environment is a shared security and networking boundary. Apps in the same environment share a VNet and a Log Analytics workspace, and can address each other by name over the internal network.

Ingress

External ingress produces a public FQDN. Internal ingress restricts access to the environment VNet. A scenario describing a backend service that must not be publicly reachable is testing this setting.

Dapr

Dapr is available as a first-class feature, enabled per app with a component configuration. It provides service invocation, state management, pub/sub, and secret access without embedding SDKs. On AKS, Dapr must be installed and maintained as an extension.

AKS — the exam-critical details

Network plugins

Plugin	Pod IP source	Use when
kubenet	Overlay, NAT to node IP	Limited VNet address space; pods need no direct VNet reachability
Azure CNI	Directly from the VNet subnet	Pods must be reachable from the VNet; requires large address space
Azure CNI Overlay	Separate overlay CIDR	Want CNI performance without consuming VNet IPs at scale

IP exhaustion under Azure CNI at scale is a recurring scenario. The expected answer is CNI Overlay.

Workload Identity

Workload Identity federates a Kubernetes service account with an Entra ID managed identity through an OIDC issuer. The pod receives a projected service account token which is exchanged for an Azure access token. No secret is stored anywhere in the cluster. It supersedes the deprecated pod-managed identity.

Enabling it requires both --enable-oidc-issuer and --enable-workload-identity on the cluster.

Node pools

The system node pool runs cluster-critical components and must use Linux. User node pools run workloads and can be Windows, GPU-enabled, or spot instances. Node pool taints and tolerations control scheduling — the usual answer for pinning GPU workloads to GPU nodes.

Troubleshooting sequence

kubectl get pods — identify the failing pod and its state
kubectl describe pod <name> — read the events, which explain scheduling and image pull failures
kubectl logs <name> --previous — read the logs of the crashed container instance
Container Insights and KQL against KubePodInventory for cluster-wide patterns

For CrashLoopBackOff specifically, --previous is essential because the current container has already restarted and its logs are empty.

Scenario phrase to answer mapping

Phrase in the scenario	Expected answer
"scale to zero when idle"	Container Apps
"minimise operational overhead"	Container Apps
"team has no Kubernetes experience"	Container Apps
"split traffic between versions"	Container Apps multiple revision mode
"scale on Service Bus queue depth"	Container Apps with the KEDA Service Bus scaler
"service invocation and pub/sub without SDKs"	Container Apps with Dapr
"specific GPU SKU for model inference"	AKS with a GPU node pool
"install a Kubernetes operator or CRD"	AKS
"pods must have VNet-routable IPs"	AKS with Azure CNI
"IP exhaustion in a large cluster"	AKS with Azure CNI Overlay
"pod must access Key Vault with no stored secret"	AKS Workload Identity
"control the maintenance and upgrade window"	AKS
"enforce approved container registries"	Azure Policy for Kubernetes on AKS

Cost intuition

Container Apps charges per vCPU-second and GiB-second actually consumed, with a monthly free grant. AKS charges per node hour regardless of pod utilisation, with the control plane free on the free tier.

Bursty or intermittent traffic — Container Apps, often by a wide margin, because idle time costs nothing
Sustained high utilisation — AKS, because reserved or spot node pricing beats the serverless rate on always-on compute
Many small services — Container Apps, since bin-packing is handled for you
Few large services at steady load — AKS, since you can size nodes precisely

Summary

Container Apps is the default answer unless the scenario names something only Kubernetes can provide: a specific GPU SKU, a custom CNI requirement, an operator or CRD, or node-level scheduling control. Read the scenario for that signal rather than choosing on general preference.

Practise this on the Domain 1 questions and review the full decision matrix.