This chapter covers Azure Container Registry (ACR), a fully managed Docker registry service for storing and managing container images and artifacts. On the AZ-204 exam, ACR is a core topic under objective 1.2 (Create containerized solutions) and appears in approximately 10-15% of exam questions, often integrated with Azure Kubernetes Service (AKS), Azure DevOps, and security scenarios. You will need to understand ACR tiers, authentication methods, geo-replication, tasks, and how to integrate with CI/CD pipelines.
Jump to a section
Think of Azure Container Registry (ACR) as a highly secure, automated warehouse for shipping containers. Each shipping container is a Docker image, labeled with a unique tag (e.g., v1.0, latest). The warehouse has multiple storage bays (repositories) organized by project. When a developer builds a new container image, they push it to the warehouse, which assigns a manifest — a detailed bill of lading listing every layer (like cargo crates) and their checksums. The warehouse manager (ACR) verifies the integrity of each crate using SHA-256 hashes. When a Kubernetes cluster needs to deploy a container, it pulls the manifest, then fetches only the missing layers, caching them locally like a forklift moving crates to a staging area. ACR supports geo-replication: imagine multiple warehouses in different cities, all synchronizing their inventory automatically. Access control is enforced by a security guard (Azure AD) who checks badges (RBAC roles) before allowing any push or pull. Tasks (ACR Tasks) automate building and patching: like a robot that automatically repackages crates when a supplier sends a new component. The warehouse also scans every crate for vulnerabilities using a built-in scanner (Microsoft Defender for Cloud) and quarantines any that fail inspection. This ensures only safe, verified containers reach production — no smuggled goods allowed.
What is Azure Container Registry and Why It Exists
Azure Container Registry (ACR) is a managed, private Docker registry service in Azure that stores and manages container images and related artifacts. It is the recommended registry for Azure deployments because it provides secure, scalable, and geo-replicated storage. ACR eliminates the need to manage your own registry infrastructure (like running a private Docker Registry on a VM) and integrates natively with Azure services such as Azure Kubernetes Service (AKS), Azure Container Instances (ACI), Azure DevOps, and GitHub Actions.
How ACR Works Internally
When you push an image to ACR, the Docker client sends each layer as a separate blob to the registry. ACR stores each layer as a content-addressable blob — its storage key is a SHA-256 hash of the layer content. The image manifest (a JSON document) lists all layers and their digests, along with configuration metadata. When pulling, the client first fetches the manifest, then downloads only the layers not already cached locally. ACR supports the OCI (Open Container Initiative) distribution specification, ensuring compatibility with Docker and other container runtimes.
Key Components, Values, and Defaults
Tiers: Basic (10GB storage, 2 events/min), Standard (100GB, 10 events/min), Premium (500GB, 50 events/min). Premium adds geo-replication, private endpoints, and customer-managed keys.
Authentication: Three methods: Admin account (username/password, not recommended for production), Azure AD authentication (using az acr login or direct AD tokens), and repository-scoped tokens (Premium tier). For automated scenarios, use service principals or managed identities.
Geo-replication: Available only in Premium tier. Replicates across multiple regions with a single registry endpoint. Replication is asynchronous; eventual consistency.
ACR Tasks: Build images in Azure using simple tasks (Dockerfile build, multi-step tasks, automated builds on source code commit or base image update). Supports quick tasks (az acr build) and automated tasks via triggers.
Content trust: Enables Docker Content Trust (Docker Notary) to sign images and verify publisher identity. Requires Premium tier.
Vulnerability scanning: Integrated with Microsoft Defender for Cloud; scans on push and provides reports. Also supports integration with Aqua, Twistlock, or Sysdig.
Configuration and Verification Commands
Create a registry:
az acr create --name myregistry --resource-group mygroup --sku Premium --admin-enabled falseLogin using Azure AD:
az acr login --name myregistryPush an image:
docker push myregistry.azurecr.io/hello-world:v1List repositories:
az acr repository list --name myregistry --output tableShow tags:
az acr repository show-tags --name myregistry --repository hello-world --output tableImport an image from Docker Hub:
az acr import --name myregistry --source docker.io/library/nginx:latest --image nginx:latestEnable geo-replication (Premium):
az acr replication create --registry myregistry --location westeurope --resource-group mygroupInteraction with Related Technologies
AKS: AKS can authenticate to ACR using managed identities. When creating a cluster, you can attach an ACR using az aks create --attach-acr myregistry. The cluster's kubelet pulls images from ACR using the managed identity.
Azure DevOps: Use the Docker task with an ACR service connection. The Azure CLI task can run az acr build to build and push in one step.
Azure Container Instances: Can reference images in ACR using image registry credentials passed as parameters.
GitHub Actions: Use the Azure Container Registry login action before building and pushing.
Security and Networking
Firewall and virtual networks: Premium tier allows restricting access via firewall rules and service endpoints. Private endpoints provide private IP connectivity from your VNet.
RBAC roles: Built-in roles include AcrPull (pull only), AcrPush (push and pull), AcrDelete (delete), and Contributor (full access). Assign roles to Azure AD identities.
Repository-scoped tokens: Fine-grained tokens that map to specific repositories and actions (e.g., read, write). Useful for CI/CD pipelines.
Monitoring and Diagnostics
Metrics: Storage usage, pull/push counts, replication status. Available in Azure Monitor.
Logs: Diagnostic settings can stream to Log Analytics workspace. Logs include authentication attempts, image operations, and replication events.
Alerts: Set up alerts on storage quota, failed pulls, etc.
Pricing Considerations
Basic: $0.167 per day (approx. $5/month) + $0.10/GB/month for storage beyond 10GB. Suitable for development.
Standard: $0.667 per day + $0.10/GB/month beyond 100GB. Good for production with moderate throughput.
Premium: $1.667 per day + $0.10/GB/month beyond 500GB. Add geo-replication at $0.667 per day per replication. Use for high availability and low-latency pulls globally.
Create an Azure Container Registry
Use the Azure CLI command `az acr create` with parameters for name, resource group, SKU (Basic, Standard, or Premium), and admin-enabled flag. The registry name must be globally unique within Azure and between 5-50 alphanumeric characters. The command provisions the registry in the specified region, sets up storage accounts (managed by Azure), and configures the DNS name `myregistry.azurecr.io`. For Premium SKU, you can also specify `--default-action Deny` to disable public access initially. The creation takes about 30-60 seconds.
Authenticate to ACR
For Azure AD authentication, run `az acr login --name myregistry`. This uses the Azure CLI context (your logged-in user) to obtain an ACR refresh token and stores it in `~/.docker/config.json`. The token is valid for 3 hours by default. For automated scenarios, use a service principal: create one with `az ad sp create-for-rbac --scopes /subscriptions/.../registries/myregistry --role AcrPush`, then login using `docker login myregistry.azurecr.io --username <appId> --password <password>`. The password is a client secret; it never expires unless rotated. Alternatively, use managed identities for Azure resources (e.g., AKS, VMs) to authenticate without secrets.
Push an image to ACR
First, tag your local image with the ACR login server: `docker tag myimage:latest myregistry.azurecr.io/myimage:v1`. Then push: `docker push myregistry.azurecr.io/myimage:v1`. The Docker client sends each layer as a blob to the registry endpoint. ACR stores each layer as a content-addressable blob keyed by its SHA-256 digest. The manifest is stored as a JSON document listing all layers. On completion, ACR returns a digest (e.g., `sha256:...`). The push operation is recorded in the registry's diagnostic logs. If the push fails due to network issues, the client retries automatically. Storage consumed is the sum of all layer sizes (compressed).
Pull an image from ACR
Run `docker pull myregistry.azurecr.io/myimage:v1`. The Docker client first requests the manifest from ACR. If the manifest is found, it parses the layer digests. For each layer, it checks local cache; if missing, it downloads the blob from ACR. ACR returns the layer data with a 200 OK. The client verifies the layer digest matches the expected SHA-256. After all layers are downloaded, the image is assembled. Pulls are faster if layers are cached locally or if geo-replication provides a nearby replica. ACR also supports multi-architecture images (e.g., linux/amd64, linux/arm64) via manifest lists.
Enable geo-replication (Premium)
Use `az acr replication create --registry myregistry --location westeurope --resource-group mygroup`. This creates a replication in West Europe. ACR automatically replicates all images asynchronously to the new region. Replication is eventual; it may take minutes to hours depending on image size and number. You can create up to 50 replications per registry. The replication endpoint is `myregistry.azurecr.io` — the same DNS name. When pulling, ACR routes the client to the nearest replica based on latency. Geo-replication provides low-latency pulls and regional failover. If a region fails, pulls are redirected to another replica. Storage costs apply per replica.
Enterprise Scenario 1: Global Microservices Deployment
A multinational e-commerce company runs hundreds of microservices on AKS clusters across North America, Europe, and Asia. They use a single Premium ACR with geo-replications in US East, West Europe, and Southeast Asia. Each cluster uses a managed identity assigned to the AKS cluster to authenticate to ACR. The CI/CD pipeline (Azure DevOps) builds images and pushes to ACR. Geo-replication ensures that pulls from each region are fast (< 1 second for manifest retrieval). The team configured firewall rules to block public access and used private endpoints for each VNet. They also enabled content trust for production images — only signed images can be deployed. Vulnerability scanning is enabled; critical vulnerabilities trigger a pipeline gate that blocks deployment. The registry stores over 500 GB of images across 200 repositories. Storage costs are about $150/month for the registry plus $100/month for replicas. Without geo-replication, pulls from Asia would take 5-10 seconds, causing pod startup delays.
Enterprise Scenario 2: Secure Software Supply Chain
A financial services firm needs to enforce strict security on container images. They use ACR Premium with customer-managed keys (CMK) for encryption at rest. Images are built using ACR Tasks that run in a dedicated network (VNet) with no public internet access. Base images are imported from Docker Hub via az acr import and scanned for vulnerabilities. Developers push only to a 'dev' repository; a promotion workflow moves images to 'staging' and 'prod' repositories after passing security scans and signing. RBAC roles are assigned: developers get AcrPush on dev, operators get AcrPull on staging and prod. Repository-scoped tokens are used for CI/CD pipelines to limit scope. The firm also enables audit logging to track every push and pull. A misconfiguration once left the admin account enabled; a security audit caught it and disabled it. The lesson: always disable admin account in production.
What Goes Wrong When Misconfigured
Public access enabled: Anyone on the internet can pull images if the registry is public. Always set firewall rules or use private endpoints.
Admin account used: Shared credentials are a security risk. Use Azure AD authentication with managed identities.
Geo-replication not configured for global deployments: Pulls from distant regions are slow, causing pod startup delays.
Insufficient RBAC: Overly permissive roles (e.g., Contributor) allow unintended deletions. Use least privilege (AcrPull, AcrPush).
Exactly What AZ-204 Tests on ACR (Objective 1.2)
The exam focuses on: (1) Creating and configuring ACR (SKU selection, geo-replication), (2) Authentication methods (admin account vs Azure AD vs service principal vs managed identity), (3) Integrating ACR with AKS and ACI, (4) Using ACR Tasks for automated builds, (5) Security features (RBAC, firewall, private endpoints, content trust, vulnerability scanning).
Most Common Wrong Answers
Using admin account for production: Many candidates think admin account is fine for automation. Wrong — admin account is a shared secret with no auditing; use service principal or managed identity.
Assuming geo-replication is synchronous: Some think all replicas are immediately consistent. ACR geo-replication is asynchronous; eventual consistency.
Choosing Basic tier for production: Basic has low throughput limits (2 events/min) and no geo-replication. Standard or Premium is required for production.
Forgetting to attach ACR to AKS: If ACR is not attached, the cluster needs image pull secrets. Managed identity attachment simplifies authentication.
Specific Numbers and Terms
SKUs: Basic (10GB, 2 events/min), Standard (100GB, 10 events/min), Premium (500GB, 50 events/min).
Geo-replication: Premium only, up to 50 replications.
Authentication token lifetime: 3 hours for az acr login.
ACR Tasks: az acr build builds and pushes in one step. Supports quick tasks, automated builds, and multi-step tasks.
Private endpoints: Supported only in Premium tier.
Content trust: Requires Premium and Docker Content Trust.
Edge Cases the Exam Loves
What if you need to pull from a different Azure AD tenant? Use service principal cross-tenant authentication.
Can you use ACR with a non-Docker OCI artifact? Yes, ACR supports OCI artifacts (e.g., Helm charts, CNAB).
How to update a base image automatically? Enable base image update trigger in ACR Tasks.
How to Eliminate Wrong Answers
If the question mentions 'lowest cost' and 'development only', choose Basic.
If 'global deployment' and 'low latency pulls' are mentioned, choose Premium with geo-replication.
If 'automated builds on git commit', choose ACR Tasks.
If 'secure pull from AKS without secrets', choose managed identity.
ACR tiers: Basic (10GB, 2 events/min), Standard (100GB, 10 events/min), Premium (500GB, 50 events/min).
Geo-replication is only available in Premium tier and is asynchronous.
Use Azure AD authentication (az acr login) for users and managed identities for Azure services.
ACR Tasks can build images on code commit or base image update, supporting multi-step YAML pipelines.
Private endpoints and firewall rules are available only in Premium tier.
Content trust (image signing) requires Premium tier and Docker Content Trust.
Attach ACR to AKS using managed identity (az aks create --attach-acr) to avoid image pull secrets.
Import images from external registries using az acr import without pulling locally.
These come up on the exam all the time. Here's how to tell them apart.
Azure Container Registry (ACR)
Managed service in Azure, no infrastructure to manage.
Integrated with Azure services (AKS, ACI, Azure DevOps).
Supports private registries by default with RBAC.
Geo-replication available (Premium tier).
Built-in vulnerability scanning (Microsoft Defender for Cloud).
Docker Hub
Public registry with limited free private repos (1 private repo on free plan).
Not integrated with Azure; requires manual authentication.
Private repos require paid plan for team access.
No geo-replication; pulls from US servers can be slow globally.
Vulnerability scanning only for paid users (Docker Scout).
Mistake
ACR admin account is recommended for CI/CD pipelines.
Correct
Admin account uses shared username/password with no audit trail. Use service principal or managed identity for automated access.
Mistake
Geo-replication provides synchronous replication across regions.
Correct
Geo-replication is asynchronous; there is no guarantee of immediate consistency. It is designed for low-latency pulls, not data consistency.
Mistake
You can only store Docker images in ACR.
Correct
ACR supports any OCI artifact, including Helm charts, OCI images, and CNAB bundles.
Mistake
Basic tier is sufficient for production workloads.
Correct
Basic tier has low throughput (2 events/min) and no geo-replication. Standard or Premium is needed for production.
Mistake
ACR Tasks can only build Dockerfiles.
Correct
ACR Tasks support multi-step tasks (YAML-based) that can run arbitrary commands, not just Docker builds.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Use managed identity. When creating the cluster, use `az aks create --attach-acr myregistry`. The cluster's kubelet gets a managed identity that has AcrPull role on the registry. No secrets are stored. Alternatively, for existing clusters, use `az aks update --attach-acr myregistry`.
`az acr build` performs the build entirely in Azure, so no Docker daemon is needed locally. It uploads the build context, runs the build, and pushes the image directly to ACR. `docker build` + `docker push` requires a local Docker daemon and pushes the image. Use `az acr build` for CI/CD pipelines to avoid local dependencies.
Yes, ACR is OCI-compliant and can store any OCI artifact, including Helm charts, OCI images, and CNAB bundles. Use `oras` CLI to push and pull non-Docker artifacts.
Enable the Premium tier and configure firewall rules: `az acr update --name myregistry --default-action Deny`. Then add a VNet rule: `az acr network-rule add --name myregistry --vnet-name myvnet --subnet mysubnet`. Alternatively, use private endpoints for private IP connectivity.
You cannot push new images until you free up space or upgrade to a higher tier. Set up alerts on storage usage to avoid this. Storage is billed per GB/month beyond the included quota.
Use ACR Tasks with a purge task: `az acr task create --name purge --registry myregistry --cmd "acr purge --filter 'hello-world:.*' --untagged --ago 30d" --schedule "0 0 * * *" --context /dev/null`. This deletes tags older than 30 days and all untagged manifests.
Yes, you can use Docker CLI with username/password (admin account or service principal) or use REST API. For automated scenarios, service principal credentials are used with `docker login`.
You've just covered Azure Container Registry — now see how well it sticks with free AZ-204 practice questions. Full explanations included, no account needed.
Done with this chapter?