Lesson 12 — Containers: ACI, Container Apps & AKS

Domain 3 — Compute AZ-104: 20–25% ~35 min Prereq: Lesson 11

Four Ways to Run a Container in Azure

Azure has multiple container services because no single product is optimal for every workload. The AZ-104 exam tests your ability to select the right service for a given scenario — not deep Kubernetes internals. What you need to understand is the operational characteristics, scale behaviour, networking model, and the decision criteria that distinguish each service.

The four container-capable services you need to know are: Azure Container Registry (the image store), Azure Container Instances (simplest possible container execution), Azure Container Apps (serverless microservices platform), and Azure Kubernetes Service (full managed Kubernetes). You will also encounter App Service as a fifth option when PaaS features like deployment slots and Easy Auth are priorities.

Azure Container Registry (ACR)

Azure Container Registry is Azure's managed private container image registry. It stores and serves Docker images, OCI artifacts, and Helm charts. Every container deployment in Azure should pull from ACR rather than public registries in production — it gives you control over what images are deployed, enables vulnerability scanning, and keeps image pulls on the Azure backbone (faster, no egress charges).

ACR SKUs

SKUStorageGeo-ReplicationPrivate LinkContent TrustUse Case
Basic 10 GiB No No No Development and testing
Standard 100 GiB No No No Most production workloads
Premium 500 GiB Yes Yes Yes Enterprise, multi-region, compliance

Authentication methods

  • Admin account: a username/password credential for the registry. Simple but not recommended — shared credentials, not tied to identity, no per-user audit trail.
  • Entra ID service principal: assign the AcrPull or AcrPush role to a service principal. Recommended for CI/CD pipelines.
  • Managed identity: assign AcrPull to the managed identity of an AKS cluster, ACI container group, or App Service app. No credential management — the preferred method for Azure-to-ACR pulls.
  • ACR token: repository-scoped token with configurable expiry. Useful for giving a vendor pull-only access to a specific repository without exposing the full registry.
Disable the admin account in production The ACR admin account is a single shared credential with no expiry and no user binding. If it leaks, anyone can push or pull any image. Use managed identities or service principals with Entra ID RBAC instead. Most security baselines require the admin account to be disabled.

Geo-replication (Premium only)

Geo-replication creates replica registries in additional Azure regions. Image layers are replicated automatically. Clients pulling from the closest replica get faster pulls and don't cross region boundaries. From the client's perspective, the registry URL stays the same — Azure routes pulls to the nearest replica. This also provides registry redundancy if one region goes down.

ACR Tasks

ACR Tasks is a built-in CI capability: build, test, and patch container images in the cloud without a local Docker daemon or a separate build server. You can trigger builds on git push (source code commit), on base image updates (keep your images patched when the base image updates), or on a schedule. ACR Tasks run inside ACR's own compute infrastructure.

Image vulnerability scanning

When Microsoft Defender for Containers is enabled, it integrates with ACR to scan images for known CVEs on push and on schedule. Findings appear in Microsoft Defender for Cloud. This is the recommended approach for supply chain security — catch vulnerabilities before images reach production clusters.

Azure Container Instances (ACI)

Azure Container Instances is the simplest way to run a container in Azure. You provide an image, specify vCPU and memory, and Azure starts the container in seconds — no cluster, no node provisioning, no orchestrator to manage. You are billed per second for the vCPU and memory you requested while the container is running.

Container groups

The deployment unit in ACI is the container group — equivalent to a Kubernetes Pod. A container group is a collection of containers that share the same network namespace (same IP address, same port space) and the same storage volumes. All containers in a group are scheduled on the same host machine and can reach each other over localhost.

Restart policies

PolicyBehaviourBest For
Always Container is always restarted if it exits, regardless of exit code Long-running services that should stay up
Never Container is not restarted after it exits — group is terminated One-shot batch jobs that run once and stop
OnFailure Container is restarted only if it exits with a non-zero exit code Batch jobs that should retry on error but stop cleanly on success

Persistent storage

ACI containers are stateless by default — any data written to the container filesystem is lost when the container exits. For persistent storage, mount an Azure Files share as a volume into the container group. Azure Files provides SMB-based shared storage that persists independently of the container lifecycle.

Networking options

  • Public IP: ACI assigns a public IP to the container group. Expose specific ports to the internet. Simple, no VNet required.
  • VNet injection: deploy the container group into a dedicated subnet in your VNet. The container group gets a private IP and can reach other VNet resources without public exposure. Required for containers that need to access private databases or internal services.
ACI use cases and limitations ACI is ideal for: one-off batch jobs, CI/CD pipeline steps, event-triggered workloads, dev/test, and simple microservices that don't need orchestration. Its key limitations are: no built-in autoscaling (you must create/delete container groups yourself), no health-based restart of individual containers within a group, no service discovery, and no persistent state without external storage. For anything that needs scale-to-zero or event-driven scaling, Azure Container Apps is the better choice.

Azure Container Apps

Azure Container Apps is a serverless container platform built on Kubernetes (AKS), KEDA (Kubernetes Event-Driven Autoscaling), and Dapr (Distributed Application Runtime). It provides the power of Kubernetes without any Kubernetes knowledge requirements — Azure manages the control plane, cluster upgrades, and node pools entirely. You interact with Container Apps through a higher-level abstraction.

Container Apps Environment

The Container Apps Environment is the isolation boundary — a shared VNet, a shared Log Analytics workspace, and a shared managed Kubernetes cluster. All Container Apps in the same environment can communicate with each other using internal service discovery (DNS). Environments are billed for their dedicated workload profile or consumption-based resources.

Scaling: the key differentiator

Container Apps supports true scale to zero — when there is no traffic or no queue messages, the app scales to zero instances and costs nothing. This is the fundamental difference from AKS (minimum node count applies) and ACI (you must stop containers manually).

  • HTTP scaling: scales based on concurrent HTTP requests. Scales to zero when no requests arrive.
  • CPU/memory scaling: scales based on resource utilisation.
  • KEDA event sources: scales based on external event sources — Azure Service Bus queue depth, Azure Storage Queue message count, Kafka topic lag, and many more. This is what makes Container Apps ideal for event-driven workers.

Revisions

When you update a Container App (new image, new environment variables, new resource limits), Container Apps creates a new revision — an immutable snapshot of the full application configuration. Previous revisions remain available. You can route traffic between revisions using percentage splits:

  • Blue/green deployment: shift 100% traffic from the old revision to the new revision atomically.
  • Canary deployment: route 10% to the new revision, monitor, then increase if healthy.
  • Old revisions can be deactivated (zero instances) while remaining available for instant rollback by re-activating them.

Ingress

Container Apps supports two ingress modes:

  • External ingress: the app is reachable from the public internet via an automatically provisioned HTTPS endpoint with a managed TLS certificate. Azure handles certificate provisioning and renewal.
  • Internal ingress: the app is only reachable from within the same Container Apps Environment (or connected networks). No public endpoint is created.

Dapr integration

Dapr (Distributed Application Runtime) is an optional sidecar that Container Apps can attach to each app. Dapr provides portable building blocks for microservice patterns: service-to-service calls with retries, pub/sub messaging, state management, secret access, and distributed tracing — all via a standardised API regardless of the underlying infrastructure. Enable Dapr with a checkbox in the Container App configuration; no code changes are required to activate the sidecar.

Container Apps is the sweet spot Container Apps occupies the ideal middle ground: simpler than AKS (no cluster management, no YAML manifests for cluster components, no upgrade coordination), more powerful than ACI (event-driven scaling, service discovery, traffic splitting, Dapr). For most new microservice and event-driven workloads, Container Apps is the right starting point.

Azure Kubernetes Service (AKS) — AZ-104 Essentials

AKS is Azure's managed Kubernetes service. Azure manages the Kubernetes control plane (API server, scheduler, etcd) at no charge — you pay only for the agent (worker) nodes. AZ-104 does not test deep Kubernetes internals, but you need to understand the AKS architecture, node pools, networking models, and the integration touchpoints with other Azure services.

Node pools

AKS clusters are composed of one or more node pools. Each node pool is a set of VMs with the same size and configuration:

  • System node pool: required in every AKS cluster. Runs AKS system components: CoreDNS, kube-proxy, metrics-server, and other critical add-ons. Must have at least one node. Best practice: taint the system pool with CriticalAddonsOnly=true:NoSchedule to prevent user application pods from being scheduled there.
  • User node pools: optional additional pools for application workloads. You can have multiple user pools with different VM sizes (e.g. a GPU pool for ML workloads, a high-memory pool for data processing).
Why taint the system node pool? If your application pods land on system nodes and consume all resources, AKS system components starve and the cluster becomes unstable — this is a production incident waiting to happen. Tainting the system pool forces application pods onto dedicated user nodes, providing resource isolation between cluster infrastructure and your workloads.

Cluster autoscaler

The cluster autoscaler monitors pods that cannot be scheduled due to insufficient node capacity. When unschedulable pods are detected, it adds nodes to the pool (up to the configured maximum). When nodes are underutilised and their pods can be evicted, it removes nodes (down to the minimum). This is different from Horizontal Pod Autoscaler (HPA), which scales pod replicas, not nodes.

Cluster and node upgrades

  • Cluster upgrade: upgrades the Kubernetes version. Control plane is upgraded first, then each node pool is cordoned and drained, upgraded, and uncordoned. Plan for brief disruption during node upgrades.
  • Node image upgrade: upgrades the OS image on nodes without changing the Kubernetes version. This is how you apply OS security patches. Can be automated via maintenance windows.

Networking models

ModelPod IP SourceNetwork PolicyMax Nodes/ClusterUse Case
Kubenet Pod-only overlay (NATed via node IP) Calico only 400 nodes Small clusters, simplified networking
Azure CNI Real VNet IPs — pods are first-class VNet citizens Azure or Calico Large-scale Production, VNet integration, private link
Azure CNI Overlay Pod overlay IPs (no VNet IP exhaustion) Azure or Calico Large-scale Large clusters where VNet IP space is limited

Key AKS integrations for AZ-104

  • ACR integration: attach an ACR to an AKS cluster with one command. AKS nodes get the AcrPull role on the registry automatically — no imagePullSecrets needed. Images pull without credential configuration.
  • Entra ID integration: enable AKS Entra integration to map Entra groups to Kubernetes RBAC roles. Cluster operators log in with their Entra credentials; access is controlled through standard Azure group membership management.
  • Azure Monitor / Container Insights: enable Container Insights to collect node and pod metrics, logs, and container stdout/stderr into a Log Analytics workspace. Standard monitoring for production AKS clusters.

Decision Matrix: Choosing the Right Container Service

Use this table when a scenario describes a container workload and asks which Azure service to use. The decision depends on complexity, scaling requirements, operational overhead tolerance, and feature needs.

Scenario Best Choice Why
Run a one-off batch job on a schedule, no persistent state needed ACI Simplest option — spin up, run, terminate. Pay only for execution time. OnFailure restart policy for retries.
Background worker that processes Azure Service Bus messages and should scale to zero when idle Container Apps KEDA Service Bus scaler provides native queue-depth-based scaling including scale-to-zero.
Microservices architecture with HTTP APIs, event-driven communication, and Dapr patterns Container Apps Dapr integration, HTTP ingress, revision traffic splitting, and scale-to-zero are built in. No Kubernetes expertise needed.
Web app that needs deployment slots, Easy Auth, and managed TLS certificates for a custom domain App Service (containers) PaaS features like slots, Easy Auth, and managed certs are App Service features, not available natively in ACI/Container Apps.
Large-scale production platform with custom CRDs, Kubernetes operators, GPU workloads, or complex networking policies AKS Full Kubernetes control surface — operators, CRDs, advanced networking (CNI), node pool customisation.
CI/CD pipeline step that needs to compile code in a clean container environment ACI Cheap, fast, isolated — ideal for ephemeral build/test steps. No cluster management overhead.
Compliance requirement for fully isolated Kubernetes cluster in your own VNet AKS (private cluster) AKS private cluster with private API server endpoint. Container Apps environments offer VNet integration but not full Kubernetes cluster isolation.
The escalation ladder Think of the container services as an escalation ladder from simple to complex: ACI (no orchestration) → Container Apps (managed Kubernetes, event-driven) → AKS (full Kubernetes control). Start at ACI for disposable workloads, Container Apps for microservices, and only escalate to AKS when you need full control of the Kubernetes API surface.

Check Your Understanding

Click any option to see immediate feedback. Answers represent correct behaviour in a real Azure environment.

1. Your organisation's security policy requires container images to be replicated across three Azure regions for redundancy and to minimise pull latency. Which ACR SKU is required?

ACR geo-replication is exclusive to the Premium SKU. It automatically replicates image layers to configured replica regions so pulls are served from the nearest replica. Basic and Standard SKUs are single-region only. ACR Tasks can build images but is not a replication mechanism.

2. Which of the following is a key scaling capability of Azure Container Apps that distinguishes it from Azure Container Instances?

Scale to zero is the defining Container Apps capability for cost optimisation. When HTTP-based scaling is configured and no requests are incoming, Container Apps reduces the replica count to zero — you pay nothing. ACI container groups run continuously until you delete or stop them; there is no automatic scale-to-zero. KEDA event-based scaling in Container Apps also supports scale-to-zero for queue-based triggers.

3. You are running a data migration job in ACI. The job processes a file and exits with code 0 on success, or code 1 on failure (and should retry). Which restart policy should you configure?

OnFailure is the correct policy for batch jobs that should retry on error but stop cleanly on success. "Always" would restart the container even after a successful completion, causing it to loop indefinitely. "Never" would not retry failures. "Scheduled" is not an ACI restart policy.

4. When configuring an AKS cluster, what is the purpose of the system node pool and why is it recommended to taint it?

The system node pool runs critical AKS components: CoreDNS, kube-proxy, metrics-server, and other cluster add-ons. It must have at least one node. Tainting it with CriticalAddonsOnly=true:NoSchedule forces application pods to schedule on user node pools, preventing resource contention between cluster infrastructure and user workloads — a common production stability practice.

5. You update a Container App with a new image version. A colleague asks how to roll back if the new version has a bug. What is the correct approach?

Container App revisions are immutable snapshots of the full application configuration (image, environment variables, scale rules, etc.). When you deploy a new version, a new revision is created and old revisions remain available. To roll back, activate the previous revision and shift traffic allocation to 100% on it. This is instant — no redeployment needed. This is one of the key advantages of the revision model.

6. You need to deploy a background worker that consumes messages from an Azure Service Bus queue and should automatically scale to zero when the queue is empty. Which Azure service is the best fit?

Azure Container Apps with KEDA is the optimal choice. KEDA has a native Azure Service Bus scaler that reads queue message counts directly and scales Container App replicas accordingly — including scaling to zero when the queue is empty. ACI does not autoscale. AKS HPA does not scale to zero by default (requires KEDA separately). WebJobs scale with the App Service Plan but do not natively scale to zero based on queue depth.
Primary source for this lesson Azure Container Apps overview — Microsoft Learn

Also read the ACI overview and the AKS concepts documentation. The decision matrix for container service selection is covered in the "Choose an Azure container service" guidance on Microsoft Learn.

Questions for your teacher (the AI agent)
This lesson covered the breadth of Azure container services. Go deeper on these topics:
  • Walk me through setting up ACR geo-replication and attaching it to an AKS cluster using managed identity authentication.
  • How does Dapr state management work in Container Apps, and what state store backends does it support?
  • What is the difference between AKS cluster autoscaler and Horizontal Pod Autoscaler — when do you need both?
  • How does Container Apps Environment VNet integration differ from AKS private cluster networking?
Coming up: Lesson 13 — Infrastructure as Code: ARM Templates & Bicep Deploying containers and App Services manually through the portal does not scale. Lesson 13 covers Azure Resource Manager templates and Bicep — the native IaC languages for Azure. You will learn the ARM template structure, Bicep syntax, deployment modes (incremental vs. complete), what-if previews, and how to manage infrastructure as versioned, repeatable code.