3.1.1. Azure Container Registry: Build, Store, Version, Manage
💡 First Principle: A registry is a database whose rows are images and whose keys are repository:tag — and like any database, its value depends on a disciplined keying scheme. Tags are mutable pointers; digests are immutable truth. Version deliberately and you can always answer "exactly what code is running in production?"
Azure Container Registry (ACR) is a managed, private OCI registry. Images address as myregistry.azurecr.io/rag-api:1.4.2 — registry login server, repository, tag. Pushing follows the Docker ritual (az acr login, docker tag, docker push); pulling from services uses managed identity with the AcrPull role rather than admin credentials — the same identity-over-secrets theme from 2.1.1, and the exam's preferred answer whenever "how should AKS/App Service authenticate to ACR" appears.
Versioning discipline is where scenarios concentrate. A tag like :1.4.2 is a label a human moves; a digest (@sha256:...) is a content hash that cannot lie. The :latest tag is the classic trap — deployments pin to it, someone pushes a new build, and production changes without anyone deploying. Stable tags for humans, unique tags (build ID, semver) for deployments, digests when immutability is contractual.
ACR's three SKUs ladder up in capability, and the differentiators are exam keywords:
| SKU | Storage/throughput | Distinguishing features |
|---|---|---|
| Basic | Entry-level | Dev/test; full API surface |
| Standard | More of both | Production default |
| Premium | Highest | Geo-replication, private endpoints, higher concurrency |
Geo-replication is the flagship Premium feature: one registry, replicated to multiple regions, so a multi-region deployment pulls locally (fast, no egress) while you push once. "Deploy to three regions with a single registry and local pulls" → Premium, geo-replication — pattern-match it. Management rounds out with retention policies and az acr purge for pruning untagged manifests, and content trust/scanning integration on the security side.
⚠️ Exam Trap: "Pin deployments to :latest so they always get the newest image" describes an incident, not a practice. When a scenario reports "production behavior changed but nobody deployed," the root cause is a mutable tag — the fix is unique tags or digest pinning.
Reflection Question: Why does pulling by digest give a stronger guarantee than pulling by tag, and what operational convenience do you sacrifice?
