AZ-104
Deep Dive
Container services in Azure: ACI for simple containers, ACR for private registries, AKS for orchestration with Kubernetes. The AZ-104 tests the difference between services and basic AKS configuration.
Contents
| Dimension | Virtual Machine | Container |
|---|---|---|
| Isolation | Own kernel, virtualized hardware | Shares the host kernel — lighter |
| Image size | GB (includes full OS) | MB (only app + dependencies) |
| Boot time | Minutes | Seconds or less |
| Density | Tens per host | Hundreds or thousands per host |
| OS management | You manage it (patches, config) | No OS to manage — just the image |
| Portability | Less portable (driver/OS deps) | Highly portable: "runs anywhere Docker runs" |
| Isolation security | Higher (separate kernel) | Lower (shared kernel) — but sufficient for most cases |
Container services in Azure — when to use each one
ACI
A single container, no orchestration, fast. Dev/test, batch jobs.
ACR
Private registry to store and distribute Docker images. Always needed if you have your own images.
AKS
Managed Kubernetes for production apps that need orchestration, HA, scaling.
Container Apps
Serverless PaaS on top of Kubernetes. No clusters to manage. For microservices and event-driven apps.
The fastest way to run a container in Azure. No Kubernetes, no clusters, no infrastructure. Ideal for simple, short-lived tasks.
Key features
• Boots in seconds — no provisioning of VMs or clusters
• Per-second billing: CPU and memory consumed while the container is active
• Supports Linux and Windows images
• Can be mounted to Azure Files for persistent storage
• Container Groups: multiple containers on the same host with shared network and storage (similar to a Kubernetes Pod)
• VNet Integration: deploy containers inside a VNet (no public IP)
• Restart policy: Always, OnFailure, Never
When NOT to use ACI
Use ACI for:
CI/CD jobs, one-off data processing, image development and testing, batch tasks scheduled with Logic Apps or ADF.
Private registry for Docker container images and OCI artifacts. Natively integrated with AKS, ACI, App Service, and Azure DevOps/GitHub Actions.
Basic
Dev/test. No geo-replication or webhooks.
Standard
General production. No geo-replication.
Premium
Geo-replication, Private Link, Content Trust, granular tokens.
Access control for ACR
ACR Tasks — build in the cloud
Lets you run docker build directly in Azure without needing Docker locally. Useful for CI/CD from machines without a Docker daemon.
→ az acr build -t my-image:v1 . — build + push in a single operation
→ Scheduled tasks: automatic rebuild when the base image changes
→ Multi-step tasks: build, test, push in a YAML pipeline
Managed Kubernetes on Azure. Azure manages the control plane (API server, etcd, scheduler) at no cost. You only pay for the cluster's worker nodes (VMs).
AKS architecture
Control Plane (managed by Azure)
Node Pools (your VMs)
AKS cluster tier
Free
Free control plane. API server uptime SLA: 99.5% (best effort). For dev/test.
Standard
Financially backed SLA of 99.9% on the API server. For production.
Premium
99.95% SLA. Long Term Support (LTS) for Kubernetes versions. For mission-critical apps.
Kubernetes versions in AKS
• AKS supports N-2 minor Kubernetes versions (e.g.: 1.29, 1.28, 1.27)
• Auto-upgrade channels: none, patch, stable, rapid, node-image
• Version upgrades are disruption-controlled (one node at a time)
• LTS (Premium): extended version support for 2 years
System vs User Node Pools
System Node Pool
Mandatory. Runs Kubernetes system components (CoreDNS, tunnel-front, metrics-server). Minimum 1 node. Cannot be deleted.
User Node Pool
Optional. For application workloads. Can scale to zero (if apps can tolerate it). Multiple pools with different VM SKUs (e.g.: a GPU pool for ML).
Cluster Autoscaler
Performs horizontal scaling of the number of nodes in a node pool. Adds nodes when Pods are Pending due to lack of resources. Removes nodes when they are underutilized.
• Configurable per node pool: min and max nodes
• Scale-down delay: time it waits before removing a node (default 10 min)
• Works together with the Horizontal Pod Autoscaler (HPA)
• When a node is removed: its Pods are rescheduled onto other nodes
Pod scaling — HPA and KEDA
HPA (Horizontal Pod Autoscaler)
Scales the number of replicas of a Deployment based on metrics (CPU, memory). Native to Kubernetes. Reacts to resource demand within the Pod.
KEDA (Kubernetes Event-Driven Autoscaler)
Scales Pods based on external events: queue length (Service Bus, Storage Queue), HTTP requests, Prometheus metrics, etc. Can scale down to 0 replicas.
| CNI Plugin | Pod IPs | Access to Pods from VNet | When to use |
|---|---|---|---|
| Kubenet (basic) | Private IP NAT-ed behind the node | Not direct (requires kubectl port-forward or a Service) | Small clusters, conserving VNet IP space |
| Azure CNI | VNet subnet IP directly on each Pod | Yes — Pods are first-class citizens in the VNet | Production, direct access to Pods from on-prem or other VNets |
| Azure CNI Overlay | Private IPs in overlay space (not the VNet) | Access through VNet gateway | Large clusters where VNet IPs are limited |
| Cilium | Azure CNI with an eBPF dataplane | Yes | When you need advanced Network Policy and eBPF observability |
ClusterIP Service
Only accessible within the cluster. Internal virtual IP. For communication between microservices.
LoadBalancer Service
Automatically creates a public (or internal) Azure Load Balancer. Exposes the app externally. An Azure public IP is assigned.
Ingress Controller
A single public LB routes to multiple services by host/path. NGINX Ingress or Application Gateway Ingress Controller (AGIC). More efficient than multiple LoadBalancers.
Cluster identity
System-assigned Managed Identity
The cluster has its own identity. Azure manages it. Used so AKS can create resources in Azure (LBs, disks, IPs).
Service Principal (legacy)
Predates Managed Identity support. Requires manually managing and rotating credentials. Not recommended for new clusters.
Workload Identity
Apps within the cluster can assume an Azure Managed Identity via an OIDC token. Lets a Pod access Key Vault, Storage, SQL, etc. without credentials.
RBAC in AKS — two levels
Azure RBAC (control plane)
Controls who can access and manage the cluster from Azure. Roles: AKS Cluster Admin, AKS Cluster User, etc. Managed with az aks get-credentials.
Kubernetes RBAC (data plane)
Controls what a user can do to resources within the cluster (Pods, Deployments, Services). ClusterRoles + ClusterRoleBindings. Integrable with Entra ID to manage via groups.
Serverless PaaS on top of Kubernetes. No clusters or nodes to manage. Scales to zero automatically. Ideal for microservices and event-driven apps.
| Dimension | ACI | Container Apps | AKS |
|---|---|---|---|
| Cluster management | No cluster | No cluster (abstracted away) | You manage the cluster (node pools, upgrades) |
| Scale to 0 | Yes (doesn't start until needed) | Yes, native | With KEDA (extra config) |
| HTTP ingress | Manual (external LB) | Built-in with HTTPS and a domain | Your own ingress controller |
| Dapr integration | No | Yes — native sidecar | Manual |
| Complexity | Minimal | Low | High (maximum control) |
| Best for | Simple/batch tasks | Microservices, APIs, workers | Complex apps that need full Kubernetes |
Did you get this topic?
Test what you just learned
A team wants to run their Docker image on Azure. The app processes files from a queue every night for 20 minutes and then does nothing until the next day. Which service is most appropriate?
Put what you learned to the test with original AZ-104 exam questions.
Start AZ-104 mock examUnlimited mock exams with the Pro plan
Log in to track your progress.