The AZ-204 exam always includes container-related services. You need to clearly distinguish between three services — ACR, ACI, and Container Apps — and understand the basics of Dockerfile.
What Is a Container?
Imagine a moving box for a house relocation. When you pack, you put in the items, padding, and instructions all together. No matter where you ship that box, the contents stay exactly the same. Containers work the same way. They bundle your application code, required libraries, and configuration files into one package so the application runs identically on any computer.
| Concept | One-Line Description | |---------|---------------------| | Image | A blueprint for creating a container. An immutable file. | | Container | A running instance of an image. An actively executing process. | | Registry | A warehouse for storing and sharing images. |
ACR (Azure Container Registry)
ACR is a private warehouse for storing Docker images. If Docker Hub is a public warehouse open to everyone, ACR is a private warehouse accessible only within your organization. In corporate environments where security is critical, you cannot expose images to the public, making a private registry essential.
Key ACR Features
Private image storage: Keep internal images secure without exposing them to the outside world ACR Tasks: Automatically builds images when code changes, enabling CI/CD integration. Developers do not need to run build commands manually. Geo-Replication: Stores copies of images in multiple regions worldwide so images can be downloaded quickly from anywhere. Available in the Premium tier only. RBAC integration: Manage image access permissions by role (Contributor, Reader, etc.) Managed Identity: Authenticate securely between Azure services without passwords
| Tier | Features | |------|---------| | Basic | Development/testing, low storage capacity | | Standard | General production, webhook support | | Premium | Geo-replication, private link, content trust |
ACI (Azure Container Instances)
ACI lets you run containers as fast as possible without setting up a cluster or servers. Like opening a package and using it immediately, you run containers instantly with no infrastructure setup required.
It is ideal for simple workloads where complex orchestrators like Kubernetes are unnecessary. Commonly used for one-time batch jobs or short-lived tasks that terminate after execution.
Key ACI Features
No cluster required: Run a container with a single command, no Kubernetes configuration needed Container Groups: Bundle multiple containers into one logical unit. Used for the sidecar pattern (main app + log collector, etc.). Linux only. Environment variable injection: Inject configuration values at container startup. Change settings without modifying code. Volume mount: Mount Azure Files so containers can store persistent data Restart policy: Always (always restart), OnFailure (restart on failure only), Never (no restart)
| Item | Description | |------|-------------| | Startup speed | Runs within seconds — the fastest container execution method in Azure | | Billing | Based on execution time (per second) and memory usage | | Use cases | One-time batch jobs, quick testing, CI/CD pipeline tasks |
Container Apps
Container Apps is a managed, serverless platform for running containers. It lets you use the powerful capabilities of Kubernetes (auto-scaling, traffic splitting, etc.) without managing Kubernetes directly. Think of a coffee shop that automatically calls in more baristas when it is busy and has nobody working when it is empty (scale to zero).
Key Container Apps Features
Serverless: No need to manage a Kubernetes cluster directly. Azure manages the infrastructure automatically. KEDA-based autoscaling: Automatically scales instances up or down based on events like HTTP request count or message queue length Scale to Zero: When there are no requests, running instances drop to zero. Very effective for cost savings. Revisions: Immutable snapshots of your app. When deploying a new version, you can split traffic between old and new (e.g., 20% new, 80% old) for a gradual rollout. Dapr integration: Simplifies service-to-service communication, state management, and message pub/sub between microservices
| Comparison | ACI | Container Apps | |------------|-----|----------------| | Cluster management | Not required | Not required | | Autoscaling | Not available | Available (KEDA) | | Scale to zero | Not available | Available | | Use case | One-time tasks | Long-running services |
!ACR versus ACI versus Container Apps
Dockerfile and Multi-Stage Builds
A Dockerfile is a recipe written step by step that describes how to build an image. Like a cooking recipe, it says: "Start with this ingredient (base image), perform these steps in order, and produce the final result."
Multi-Stage Builds
This technique separates the build stage (compiling code) from the run stage (executing the app). It is like separating the production line from the packaging line in a factory. Build tools needed for compilation are not included in the final image, making the image much smaller.
Build stage: Compile source code, include build tools Run stage: Copy only the compiled output, exclude build tools Result: Significantly smaller final image size, fewer security vulnerabilities
Exam Key Points
"Private Docker image storage" -- ACR (Azure Container Registry)
"Automatically build images when code changes" -- ACR Tasks
"Fast global distribution with geo-replication" -- ACR Premium tier
"Fastest container execution without a cluster" -- ACI (Azure Container Instances)
"Main app and helper app as one unit" -- Container Group (sidecar pattern)
"Serverless container platform with KEDA scaling" -- Container Apps
"Zero instances when there are no requests" -- Container Apps Scale to Zero
"Split traffic between new and old versions" -- Container Apps Revisions
"Microservice communication and state management sidecar" -- Dapr (Container Apps integration)
"Reduce image size by separating build and run stages" -- Multi-stage build (Dockerfile)
"Authenticate between Azure services without a password" -- Managed Identity