This chapter covers containerized solutions on Azure, focusing on Azure Container Instances (ACI), Azure Container Apps, and Azure Kubernetes Service (AKS). These services are critical for deploying, scaling, and managing microservices-based applications. In the AZ-204 exam, approximately 15-20% of questions relate to compute solutions, with a significant portion on containers. You will learn how to choose the right container service, configure container groups, manage container registries, and integrate with other Azure services. Mastery of these topics is essential for passing the exam and for real-world cloud-native development.
Jump to a section
Imagine a global shipping company that needs to transport goods from factories to stores worldwide. Before standardized containers, each item was loaded individually, leading to inefficiencies, damage, and compatibility issues between ships, trains, and trucks. The introduction of standardized shipping containers revolutionized logistics. Each container is a uniform, self-contained unit that can be sealed, stacked, and transported via any mode of transport without opening it. The container includes its own labeling (metadata) and can hold any cargo (application code and dependencies). Similarly, Docker containers package an application with its dependencies into a standardized, isolated unit that can run consistently across any host that supports the container runtime. The container image is like the container design specification; it is built once and can be instantiated (run) multiple times. The container orchestration platform (like Kubernetes) acts as the global shipping logistics system, deciding which containers go where, scaling them out, and managing their lifecycle. Just as containers reduce shipping costs and errors, software containers reduce deployment friction and environment inconsistencies.
What Are Containers and Why Use Them?
Containers are lightweight, standalone, executable packages that include everything needed to run a piece of software: code, runtime, system tools, libraries, and settings. Unlike virtual machines (VMs), containers share the host OS kernel, making them more resource-efficient and faster to start. The most common container runtime is Docker, which uses images to define the container's filesystem and runtime configuration. Containers solve the "it works on my machine" problem by ensuring consistent behavior across development, testing, and production environments.
Azure Container Instances (ACI)
ACI is a Platform-as-a-Service (PaaS) offering that allows you to run containers directly on Azure without managing underlying VMs or orchestration. It is ideal for simple applications, batch jobs, or event-driven tasks. Key features include: - Hypervisor-level isolation: Each container instance runs in its own VM, ensuring strong security boundaries. - Public IP and DNS name: By default, each container group gets a public IP and fully qualified domain name (FQDN) for inbound traffic. - Fast startup: Typically under 5 seconds for a cold start. - Custom sizes: You can specify CPU (1-4 cores) and memory (1-16 GB) per container group. - Persistent storage: Mount Azure Files shares for stateful workloads.
#### Container Groups
ACI uses container groups, which are similar to pods in Kubernetes. A container group is a collection of containers that share the same lifecycle, network, and storage. They are deployed on the same host and can communicate via localhost. Key characteristics: - Shared network: All containers in a group share a single public IP and DNS label. - Shared storage: Volumes can be mounted across containers in the group. - Co-scheduling: All containers start together and stop together.
#### Networking
ACI integrates with Azure Virtual Network (VNet) via delegated subnets. This allows containers to communicate with other Azure resources privately. Without VNet integration, containers use a public endpoint. You can also use Application Gateway as an ingress controller for HTTP traffic.
#### Restart Policies
ACI supports three restart policies: - Always: The container is always restarted after termination (default for long-running apps). - OnFailure: Restarted only if the container exits with a non-zero exit code (for batch jobs). - Never: The container is not restarted (for one-shot tasks).
#### Environment Variables and Secrets
You can pass environment variables at runtime. For sensitive data, use secure environment variables, which are encrypted and not visible in the container's properties. Alternatively, mount secrets from Azure Key Vault.
Azure Container Apps (ACA)
Azure Container Apps is a serverless container platform that runs on top of Azure Kubernetes Service (AKS) but abstracts away the Kubernetes complexity. It is designed for microservices and is Kubernetes-native under the hood. Key features: - Serverless: No need to manage clusters, nodes, or pods. - Autoscaling: Based on HTTP traffic, events (KEDA), or CPU/memory usage. - Revision management: Each deployment creates a new revision; you can manage traffic splitting between revisions for blue-green deployments. - Ingress: Built-in HTTPS ingress with custom domains and TLS termination. - Dapr integration: Distributed Application Runtime (Dapr) provides APIs for state management, pub/sub, service invocation, and more. - Jobs: Run containerized tasks that execute to completion (like batch jobs).
#### Architecture
Container Apps are built on Azure Kubernetes Service, but the cluster is managed by Microsoft. You define a Container App Environment, which is a secure boundary around a set of container apps. The environment includes a virtual network, Log Analytics workspace, and storage. Each container app is a microservice that scales independently.
#### Scaling Rules
HTTP scaling: Based on concurrent HTTP requests per replica (default target is 10 concurrent requests).
Event-driven scaling: Using KEDA scalers for Azure Service Bus, Event Hubs, queues, etc.
CPU/Memory scaling: Based on average CPU or memory usage across all replicas.
Custom scaling: Using KEDA's custom scaler.
#### Revisions
A revision is a snapshot of a container app's version. Each time you update the container image or configuration, a new revision is created. You can: - Set active/inactive: Deactivate old revisions. - Traffic splitting: Route a percentage of traffic to different revisions (e.g., 90% to v1, 10% to v2). - Latest revision: A special label that always points to the most recent deployment.
Azure Kubernetes Service (AKS)
AKS is a managed Kubernetes service that simplifies deploying, managing, and scaling containerized applications using Kubernetes. It handles master node management, health monitoring, and repairs. Key features: - Managed control plane: The Kubernetes API server, etcd, and scheduler are managed by Azure. - Node pools: Groups of worker nodes with the same configuration. You can have system node pools (for critical system pods) and user node pools (for application pods). - Cluster autoscaler: Automatically scales the number of nodes based on pod resource requests. - Azure AD integration: Use Azure Active Directory for authentication and Kubernetes RBAC for authorization. - Network policies: Control traffic flow between pods using Azure Network Policy or Calico. - Azure Policy: Enforce policies on the cluster (e.g., restrict privileged containers).
#### Node Pools
AKS supports multiple node pools with different VM SKUs, scaling policies, and availability zones. You can use spot node pools for cost savings (with the risk of eviction).
#### Storage
AKS integrates with Azure Disk and Azure Files for persistent storage. You can use CSI drivers for dynamic provisioning. Key classes: - managed-csi: Azure Disk (premium or standard) for high-performance block storage. - azurefile-csi: Azure Files for SMB 3.0 shared storage.
#### Networking
AKS supports two network models: - kubenet: A basic network plugin that creates a virtual network and assigns pod IPs from a private CIDR. Requires manual routing. - Azure CNI: Each pod gets an IP from the VNet subnet, enabling direct connectivity to other Azure services. Offers better performance but requires more IP addresses.
#### Ingress Controllers
Common ingress controllers include: - NGINX Ingress Controller: Deployed as a pod, handles HTTP/HTTPS routing. - Azure Application Gateway Ingress Controller (AGIC): Uses Application Gateway as the ingress, providing Web Application Firewall (WAF). - Azure Front Door: For global load balancing and SSL offload.
Azure Container Registry (ACR)
ACR is a private Docker registry for storing and managing container images. It integrates with ACI, AKS, and Container Apps. Key features: - Tiers: Basic, Standard, Premium. Premium includes geo-replication, private endpoints, and content trust. - Tasks: Automate image building and patching on code commit or base image update. - Helm chart support: Store and manage Helm charts for Kubernetes deployments. - Firewall and virtual network: Restrict access using service endpoints or private endpoints.
#### Authentication
Admin account: Enable for simple username/password access (not recommended for production).
Azure AD authentication: Use az acr login or Docker login with an Azure AD token.
Managed identities: AKS clusters can use a managed identity to pull images without credentials.
Choosing the Right Service
ACI: Simple, single-container apps, batch jobs, event-driven tasks. No orchestration needed.
Container Apps: Microservices, serverless containers, event-driven apps, need scaling and revisions but not full Kubernetes control.
AKS: Complex, multi-container applications, need fine-grained control over orchestration, scaling, networking, and security. Requires Kubernetes expertise.
Create a Container Registry (ACR)
First, create an Azure Container Registry to store your Docker images. Use the Azure CLI: `az acr create --resource-group myRG --name myACR --sku Basic`. The name must be globally unique and alphanumeric (5-50 characters). The Basic SKU is sufficient for development; use Standard or Premium for production. Once created, log in using `az acr login --name myACR`. This authenticates your Docker client to the registry. The login server URL is `myACR.azurecr.io`. You can now push images to this registry.
Build and Push a Docker Image
Create a Dockerfile for your application. For example, a simple Node.js app: `FROM node:14-alpine; COPY . /app; WORKDIR /app; RUN npm install; EXPOSE 3000; CMD ["node", "server.js"]`. Build the image locally: `docker build -t myACR.azurecr.io/myapp:v1 .`. Then push it to ACR: `docker push myACR.azurecr.io/myapp:v1`. The image is now stored in your private registry. For production, consider using ACR Tasks to automate building on code commits.
Deploy to Azure Container Instances
Deploy the image to ACI using the Azure CLI: `az container create --resource-group myRG --name myContainer --image myACR.azurecr.io/myapp:v1 --cpu 1 --memory 1 --registry-login-server myACR.azurecr.io --registry-username <username> --registry-password <password> --dns-name-label myapp-dns --ports 80`. This creates a container group with one container. The DNS label `myapp-dns` combined with the region creates a FQDN `myapp-dns.region.azurecontainer.io`. The container pulls the image from ACR using the provided credentials. For production, use managed identities instead of username/password.
Configure Environment and Scaling
For ACI, you can pass environment variables with `--environment-variables`. For scaling, ACI does not auto-scale; you must manually create multiple container groups or use Container Apps. In Container Apps, define scaling rules in the `properties.template.scale` section of the ARM template. For example, set `minReplicas: 0` (serverless) and `maxReplicas: 10` with a CPU rule. The scaling is based on KEDA. For AKS, use `kubectl autoscale deployment myapp --cpu-percent=50 --min=1 --max=10` to create a HorizontalPodAutoscaler.
Monitor and Manage
Monitor container health using Azure Monitor. For ACI, view logs with `az container logs --resource-group myRG --name myContainer`. For Container Apps, use the Log Analytics workspace integrated with the environment. For AKS, enable Container Insights to monitor pod metrics and logs. Use `kubectl get pods` to check status. For troubleshooting, use `kubectl describe pod <pod-name>` to see events. For ACI, use `az container show` to get the instance view. Set up alerts for CPU/memory usage and restart counts.
Scenario 1: Batch Processing with ACI
A media processing company needs to transcode thousands of videos daily. They use Azure Container Instances to run FFmpeg containers. Each job is triggered by a message in Azure Queue Storage. An Azure Function reads the queue and creates a container group with the video file mounted from Azure Files. The container runs the transcoding job, writes the output back, and exits. The restart policy is set to OnFailure to retry failed jobs. This approach scales to hundreds of concurrent instances, each isolated in its own VM. Costs are low because containers only run when jobs are pending. A common misconfiguration is forgetting to set --restart-policy OnFailure, causing the container to restart and re-process the same file indefinitely.
Scenario 2: Microservices with Container Apps
An e-commerce platform uses Azure Container Apps for its microservices: product catalog, shopping cart, order processing, and payment. Each service is a separate container app with its own scaling rules. The cart service scales based on HTTP traffic, while the order processing scales based on Service Bus queue length using KEDA. Traffic splitting is used for blue-green deployments: new revisions receive 10% traffic initially, then gradually increased. Dapr is used for state management (shopping cart state) and pub/sub (order events). The environment is secured within a virtual network, and ingress uses a custom domain with TLS. A pitfall is not setting appropriate minReplicas for latency-sensitive services; setting minReplicas: 0 causes cold starts on the first request.
Scenario 3: Enterprise Kubernetes with AKS
A financial services company runs a complex trading application on AKS. They use multiple node pools: a system node pool with small VMs for system pods, and user node pools with GPU-enabled VMs for machine learning models. Azure AD integration provides authentication, and Azure Policy enforces that only approved images from ACR can run. Network policies restrict pod-to-pod communication based on microservice boundaries. Persistent storage is provided by Azure Disk for databases and Azure Files for shared configuration. The cluster autoscaler handles varying load during market hours. Misconfigurations include not setting resource requests/limits, causing noisy neighbor issues, and not using pod disruption budgets, leading to downtime during node upgrades.
Exam Objective Codes: This chapter maps to AZ-204 objective "Implement containerized solutions" (15-20% of exam). Sub-objectives include: Create and manage container images (ACR), Configure Azure Container Instances, Configure Azure Container Apps, Configure Azure Kubernetes Service, and Integrate with other Azure services.
Common Wrong Answers:
1. Choosing ACI for a multi-container microservice with complex orchestration: Candidates pick ACI because it's simpler, but ACI lacks orchestration features like service discovery, rolling updates, and auto-scaling. The correct answer is AKS or Container Apps.
2. Selecting the Basic ACR SKU for production with geo-replication: The Basic SKU does not support geo-replication. Candidates often forget this. The correct SKU is Premium.
3. Using `az container create` without `--registry-login-server` when using ACR: Candidates assume the registry is automatically detected. Actually, you must specify the login server for private registries.
4. Setting `minReplicas: 0` for a latency-sensitive Container App: Candidates think serverless is always best, but cold starts cause delays. The correct setting is minReplicas: 1 or higher.
Specific Numbers and Terms:
ACI CPU limits: 1-4 cores per container group.
ACI memory limits: 1-16 GB per container group.
Container Apps default HTTP scaling target: 10 concurrent requests per replica.
AKS node pool minimum: 1 node (though system node pool may require 2 for availability).
ACR SKU tiers: Basic (10 GB storage), Standard (100 GB), Premium (500 GB+ geo-replication).
Edge Cases:
ACI container groups cannot span multiple availability zones.
Container Apps revision traffic splitting does not support sticky sessions (session affinity) by default; you need to configure it.
AKS cluster upgrades: You cannot skip minor versions (e.g., 1.24 to 1.26).
ACR tasks: Base image updates trigger automatic rebuilds only if you enable the task's trigger property.
Elimination Strategy:
If the scenario requires orchestration, scaling, and service discovery, eliminate ACI.
If the scenario requires full Kubernetes control and custom networking, eliminate Container Apps.
If the scenario is simple, event-driven, or batch, eliminate AKS.
For registry questions, remember which SKU supports geo-replication, private endpoints, and content trust.
Containers share the host OS kernel, making them lighter than VMs.
Azure Container Instances (ACI) is for simple, isolated containers without orchestration.
Azure Container Apps is a serverless container platform with built-in scaling and revisions.
Azure Kubernetes Service (AKS) is a managed Kubernetes offering for complex orchestration.
Azure Container Registry (ACR) stores container images; Premium SKU supports geo-replication.
Use managed identities for ACR authentication in production, not admin accounts.
Container Apps revision traffic splitting enables canary deployments.
ACI container groups share lifecycle, network, and storage.
AKS node pools can be system or user; system pools run critical system pods.
Container Apps scaling rules use KEDA for event-driven scaling.
These come up on the exam all the time. Here's how to tell them apart.
Azure Container Instances (ACI)
Simple, single-container or small multi-container groups
No orchestration or scaling built-in
Hypervisor-level isolation (strong security)
Fast startup (under 5 seconds)
Public IP and DNS name by default
Azure Container Apps (ACA)
Serverless microservices with built-in scaling
Supports revisions, traffic splitting, and Dapr
Runs on AKS but abstracts Kubernetes
Scales based on HTTP, events, CPU/memory
Built-in ingress with custom domains and TLS
Azure Container Apps (ACA)
Serverless, no cluster management
Limited to container apps (no daemonsets, etc.)
Scales automatically with KEDA
Revision management for blue-green deployments
Integrated with Dapr for distributed apps
Azure Kubernetes Service (AKS)
Full Kubernetes control (pods, deployments, services)
Supports all Kubernetes workloads
Custom networking, node pools, GPU support
Cluster autoscaler and HorizontalPodAutoscaler
Requires Kubernetes expertise to manage
Mistake
Containers are the same as virtual machines but lighter.
Correct
Containers share the host OS kernel, while VMs include a full guest OS. Containers are isolated at the process level, not hardware level. This means containers are more portable and efficient but cannot run a different OS than the host.
Mistake
Azure Container Instances can auto-scale automatically.
Correct
ACI does not have built-in auto-scaling. You must manually create additional container groups or use Container Apps/Service Fabric for scaling. ACI is designed for simple, isolated containers.
Mistake
You need to manage the Kubernetes master nodes in AKS.
Correct
AKS is a managed Kubernetes service; Microsoft manages the control plane (API server, etcd, scheduler). You only manage the worker nodes (node pools).
Mistake
Container Apps and AKS are the same thing.
Correct
Container Apps is built on AKS but abstracts away Kubernetes complexity. It is serverless and simpler, but you cannot directly access the Kubernetes API. AKS gives you full control but requires more management.
Mistake
ACR admin account is the recommended way to authenticate.
Correct
The admin account is insecure for production. Use Azure AD authentication or managed identities for AKS and ACI to pull images without storing credentials.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Use ACI for simple, single-container tasks, batch jobs, or event-driven workloads that don't need scaling or orchestration. Use Container Apps for microservices that need auto-scaling, traffic splitting, and Dapr integration. If you need full Kubernetes control, use AKS.
Use the `--attach-acr` parameter when creating the AKS cluster with `az aks create --attach-acr <acr-name>`. This creates a role assignment granting the AKS cluster's managed identity AcrPull role on the registry. Alternatively, attach after creation with `az aks update --attach-acr`.
Yes, you can deploy ACI into an Azure Virtual Network by specifying `--vnet` and `--subnet` parameters. This allows containers to communicate privately with other Azure resources. You must delegate the subnet to `Microsoft.ContainerInstance/containerGroups`.
A container group in ACI is similar to a Kubernetes pod. Both are a group of containers that share the same lifecycle, network (localhost), and storage. However, container groups are managed by ACI, while pods are managed by Kubernetes.
Define scaling rules in the container app's configuration. You can set rules based on HTTP concurrency (default target 10), CPU/memory usage, or event-driven triggers using KEDA (e.g., Azure Service Bus queue length). Set minReplicas and maxReplicas in the template.
Dapr (Distributed Application Runtime) provides APIs for state management, pub/sub, service invocation, and more. Container Apps has built-in Dapr integration; you can enable it by setting `dapr.enabled: true` in the container app resource. It simplifies building microservices.
Yes, you can mount an Azure Files share to an ACI container group using the `--azure-file-volume-account-name`, `--azure-file-volume-account-key`, and `--azure-file-volume-share-name` parameters. The share is mounted at the specified mount path.
You've just covered Containerized Solutions on Azure — now see how well it sticks with free AZ-204 practice questions. Full explanations included, no account needed.
Done with this chapter?