What's changed: Deepened AZ-204 Chapter 1 to Associate depth (tables, scenarios, FAQ, traps; localized figures)
1.3Container Development (ACR, ACI, Container Apps)
Understand container development options: Azure Container Registry (store/build images), Container Instances (simple container runs), and Container Apps/AKS (scaling microservices).
Containers package an app with its dependencies for portability—a staple for dev/deploy. Azure offers options from image management to running and scaling.
1.3.1Container options
- ACR (Azure Container Registry): a private registry to store/build (ACR Tasks) container images.
- ACI (Container Instances): run a single/few containers quickly and serverlessly.
- Container Apps: run microservices with scaling (incl. KEDA event-driven). AKS is full Kubernetes.
Container development flows "build/store the image (ACR) → run it (ACI/Container Apps/AKS)." ACR (Azure Container Registry) is a private registry where ACR Tasks build/patch/auto-update images in the cloud, authenticating via managed identity/tokens, with geo-replication for availability. Choose the runtime by need: ACI runs a single/few containers quickly and serverlessly (batch/jobs/ephemeral); Container Apps offers KEDA-based event-driven scaling (scale to zero) and Dapr integration for microservices (no need to manage Kubernetes); AKS is full Kubernetes for advanced orchestration. App Service can also host containers. For CI/CD, push to ACR and each service pulls. The axes: "store/build images = ACR," "simple/ephemeral = ACI," "scale microservices without K8s = Container Apps," "full K8s control = AKS," "web-centric with containers = App Service."
| Requirement | Use |
|---|---|
| Store/build images | ACR (+ ACR Tasks) |
| Single/ephemeral container fast | ACI |
| Scale microservices (no K8s) | Container Apps (KEDA/Dapr) |
| Full Kubernetes control | AKS |
Scenario: containerize an API and scale from zero to many by queue length. Store images in ACR (auto build/patch via ACR Tasks) and run on Container Apps (KEDA scales by queue length, zero when idle). For large platforms needing fine Kubernetes control, use AKS; for batch/ephemeral work, ACI. Each service pulls from ACR securely via a managed identity.
Q. Store/build images? ACR (ACR Tasks). Q. Single/ephemeral container? ACI. Q. Scale microservices without K8s? Container Apps. Q. Full Kubernetes? AKS. Q. Event-driven scale to zero? Container Apps (KEDA). Q. Pull from ACR securely? Managed identity.
Watch the mix-ups: (1) ACR is the registry/build, not the runtime (ACI/Container Apps/AKS run it)—don’t swap roles. (2) Container Apps ≠ AKS—use AKS to operate Kubernetes directly, Container Apps to use it abstracted. (3) ACI isn’t for large-scale orchestration (single/ephemeral). (4) Prefer managed identity over keys to pull from ACR.
Common on AZ-204: store/build images = ACR, run simple containers fast = ACI, scale microservices = Container Apps, full Kubernetes = AKS. Push images to ACR, then deploy via each service.
1.3.2Section summary
- ACR (store/build) / ACI (simple run) / Container Apps·AKS (scale)
- Push images to ACR, then deploy
Sign in to track progress — Log in.
Quick check
(just a quick review)Q1. Which Azure private registry stores and builds container images?
Q2. You want to run a single container quickly without managing servers. Which Azure service fits best?
Q3. Which Azure service runs microservices with event-driven scaling?