This chapter covers Azure Container Registry (ACR), a managed private Docker registry service that stores and manages container images and artifacts. ACR is a core component for any containerized workload on Azure and appears in roughly 5-10% of AZ-104 exam questions, often integrated with Azure Kubernetes Service (AKS), Azure Container Instances (ACI), or DevOps pipelines. You must understand ACR's SKUs, authentication methods, replication, tasks, and security features to pass the exam. This chapter provides the deep technical knowledge required to configure, manage, and troubleshoot ACR in production environments.
Jump to a section
Imagine a large shipping port where many companies store and distribute containers. The public port (Docker Hub) is open to everyone, but anyone can see and potentially tamper with your containers. Now, Azure Container Registry (ACR) is like a private, secure warehouse within that port. You own the warehouse, you control who has keys, and you can replicate your inventory to other warehouses in different cities for faster delivery. In this warehouse, each container image is stored in a repository (like a shelf), and each image can have multiple versions (tags), like different product batches. When you need to deploy a container to a Kubernetes cluster or an Azure Container Instance, you fetch the image from your private warehouse. The warehouse manager (ACR) authenticates you via your ID badge (Azure AD token or admin credentials), checks your permissions (RBAC roles), and then hands over the container. If you have geo-replication enabled, the warehouse automatically syncs your inventory to other locations, so your ships (deployments) can pick up containers from the nearest warehouse instead of traveling across the ocean. This reduces latency and ensures you always have the latest version. The warehouse also scans containers for vulnerabilities (like a security inspector checking for hazardous materials) and can automatically sign images to verify they haven't been tampered with. Without ACR, you'd have to rely on a public registry, risking security and performance issues.
What is Azure Container Registry (ACR)?
Azure Container Registry (ACR) is a managed, private Docker registry service based on the open-source Docker Registry 2.0. It allows you to store and manage container images and other OCI (Open Container Initiative) artifacts in a private repository within your Azure subscription. ACR supports Docker images, Helm charts, and OCI artifacts. It is the recommended registry for Azure compute services like AKS, ACI, Azure Batch, and Azure App Service.
ACR is not just a storage service; it provides enterprise-grade features including geo-replication, content trust (image signing), vulnerability scanning, automated image builds (ACR Tasks), and integration with Azure Active Directory (Azure AD) for authentication. The registry is accessible via the Docker CLI, the ACR REST API, or Azure portal.
How ACR Works Internally
At its core, ACR is a RESTful web service that implements the OCI Distribution Specification. When you push an image using docker push, the Docker client sends a series of HTTP requests to the ACR login server (e.g., myregistry.azurecr.io). The process involves:
1. Authentication: The client must first authenticate. ACR supports two primary authentication methods:
- Azure AD authentication: Using az acr login which obtains an Azure AD token and passes it to Docker. This is the recommended method for individual users.
- Admin account: ACR has a built-in admin account with two passwords that can be enabled per registry. This is used for CI/CD scenarios or legacy Docker clients.
- Repository-scoped tokens: Fine-grained access tokens that can be scoped to one or more repositories with specific permissions (read, write, delete).
Manifest and Blob Storage: When pushing an image, Docker splits the image into a manifest (JSON describing layers and configuration) and layers (blobs). The manifest is pushed as a single JSON document, and each layer is uploaded as a blob using a series of chunked uploads. ACR stores these in Azure Blob Storage behind the scenes. The registry uses a flat namespace for blobs, but repositories are organized as a hierarchy (e.g., myregistry.azurecr.io/nginx:latest).
Tagging: Tags are pointers to manifests. When you push myimage:latest, ACR creates or updates the tag to point to the new manifest. Multiple tags can point to the same manifest.
Replication: If geo-replication is enabled, ACR uses Azure Storage replication to asynchronously copy all blobs and manifests to the target regions. The replication is automatic and transparent to the user. When a pull request comes to a replica, the registry serves the data from the local storage if available, otherwise falls back to the primary region.
Key Components, Values, and Defaults
- SKUs: ACR offers three SKUs: Basic, Standard, and Premium. - Basic: 10 GB storage, 1 webhook, no geo-replication, 2 events/min for webhooks. Suitable for development. - Standard: 100 GB storage, 10 webhooks, no geo-replication, 10 events/min. Good for production. - Premium: 500 GB storage (scalable up to 10 TB by request), 100 webhooks, geo-replication, content trust, private endpoints, repository-scoped tokens, and increased throughput. Required for enterprise features.
Registry Name: Must be globally unique within Azure, 5-50 alphanumeric characters, lowercase only.
Login Server: <registry-name>.azurecr.io.
Storage Limits: By default, Basic: 10 GB, Standard: 100 GB, Premium: 500 GB. You can request increases for Premium.
Concurrent Operations: Basic: 10 concurrent operations per registry, Standard: 40, Premium: 200.
Webhooks: HTTP callbacks triggered by push, delete, or quarantine events. Up to 1/10/100 for Basic/Standard/Premium.
Geo-Replication: Only Premium SKU. Can replicate to any Azure region. Each replica is a fully functional registry with its own login server (e.g., myregistry.eastus.azurecr.io). Replication is asynchronous; typical latency is a few minutes.
Content Trust: Implements Docker Content Trust (Notary) to sign images. Enabled per registry in Premium SKU. Requires signing keys and a trust server.
Vulnerability Scanning: Integrated with Microsoft Defender for Cloud. Scans images on push and provides reports. Can be triggered manually.
Configuration and Verification Commands
Create an ACR instance:
az acr create --name myregistry --resource-group myrg --sku Premium --location eastusEnable admin account:
az acr update --name myregistry --admin-enabled trueLogin to ACR:
az acr login --name myregistryPush an image:
docker tag myimage:latest myregistry.azurecr.io/myimage:latest
docker push myregistry.azurecr.io/myimage:latestList repositories:
az acr repository list --name myregistry --output tableShow tags:
az acr repository show-tags --name myregistry --repository myimage --output tableEnable geo-replication:
az acr replication create --registry myregistry --location westeurope --resource-group myrgCreate a webhook:
az acr webhook create --name mywebhook --registry myregistry --uri http://example.com/hook --actions push --scope myimage:*List webhooks:
az acr webhook list --registry myregistry --output tableInteraction with Related Technologies
AKS: AKS can authenticate to ACR using Azure AD managed identity. When creating an AKS cluster, you can attach an ACR using az aks create --attach-acr myregistry. This grants the kubelet identity AcrPull role on the ACR. Alternatively, you can manually assign the role.
ACI: Container groups can pull images from ACR by providing registry credentials in the deployment YAML or using managed identity.
Azure DevOps: ACR integrates with Azure Pipelines via Docker registry service connection. You can build and push images using the Docker task.
ACR Tasks: Automated image builds triggered by source code commits or base image updates. Can run in Azure Container Instances.
Security Features
Private Endpoints: Premium SKU allows connecting to ACR via Azure Private Link, keeping traffic within the Microsoft backbone.
Firewall Rules: Restrict access by IP address or virtual network.
Service Endpoints: Allow access from a specific VNet.
RBAC Roles: Built-in roles: AcrPull, AcrPush, AcrDelete, Contributor, Owner. You can also create custom roles for fine-grained permissions.
Repository-scoped tokens: Generate tokens with specific permissions on specific repositories, useful for CI/CD without exposing full registry access.
Backup and Disaster Recovery
ACR is a regional service. For disaster recovery, use geo-replication (Premium SKU) to replicate to multiple regions. Alternatively, use az acr import to copy images between registries. There is no native backup; you must export images using docker save and docker load or use tools like skopeo.
Create an ACR instance
Use the Azure CLI command `az acr create` with parameters for name, resource group, SKU (Basic, Standard, or Premium), and location. The name must be globally unique and lowercase alphanumeric (5-50 characters). For production, choose Premium if you need geo-replication, private endpoints, or content trust. Standard is suitable for most workloads. Basic is for development only. After creation, the login server is `<registry-name>.azurecr.io`. Verify with `az acr show --name myregistry`. The SKU can be upgraded but not downgraded.
Authenticate to the registry
For individual users, use `az acr login --name myregistry`. This authenticates with Azure AD and caches the token in Docker's config file. For automated scenarios, enable the admin account with `az acr update --name myregistry --admin-enabled true` and use the username and password (two passwords available for rotation). Alternatively, create repository-scoped tokens for fine-grained access. The token is used as a password with a specific username (e.g., `mytoken`). RBAC roles can also be assigned to Azure AD identities for pull/push permissions.
Push a container image
Tag your local image with the ACR login server and repository name: `docker tag myimage:latest myregistry.azurecr.io/myimage:latest`. Then push: `docker push myregistry.azurecr.io/myimage:latest`. The push splits the image into layers and manifest. Each layer is uploaded as a blob. The manifest is a JSON file describing the layers. On success, the tag is created or updated. Use `az acr repository list` and `az acr repository show-tags` to verify. The image is stored in Azure Blob Storage within the registry's storage account.
Pull the image from AKS
When deploying to AKS, the cluster needs permission to pull images from ACR. The recommended approach is to attach the ACR during AKS creation: `az aks create --attach-acr myregistry`. This grants the AKS cluster's kubelet identity the `AcrPull` role. Alternatively, use a Kubernetes secret with admin credentials. In the deployment YAML, specify the image as `myregistry.azurecr.io/myimage:latest`. The kubelet authenticates using the managed identity and pulls the image. Verify with `kubectl get pods` and `kubectl describe pod`.
Enable geo-replication
For Premium SKU only, use `az acr replication create --registry myregistry --location westeurope --resource-group myrg`. This creates a replica in the specified region. Replication is asynchronous; images pushed to the primary are automatically replicated. When pulling from a replica, the registry serves from local storage if available, else falls back to primary. List replicas with `az acr replication list`. Each replica has its own login server (e.g., `myregistry.westeurope.azurecr.io`). Geo-replication provides low-latency pulls and disaster recovery.
Scenario 1: Global Microservices Deployment with AKS
A multinational e-commerce company runs a Kubernetes cluster in multiple Azure regions (East US, West Europe, Southeast Asia) to serve customers with low latency. They use ACR Premium with geo-replication to replicate container images to each region. The CI/CD pipeline builds images in East US and pushes to the primary ACR. Geo-replication automatically syncs the images to West Europe and Southeast Asia replicas within minutes. AKS clusters in each region pull images from their local replica, reducing pull times from minutes to seconds. Misconfiguration: If the ACR SKU is Standard instead of Premium, geo-replication is unavailable, causing high latency for pulls from distant regions. The solution: upgrade to Premium and configure replicas in each region.
Scenario 2: Secure Supply Chain with Image Signing
A financial services company requires that all container images in production are signed to verify integrity and origin. They enable content trust on their Premium ACR. Developers build and sign images using Docker Content Trust. The signing process generates a delegation key and pushes the signed manifest. The ACR validates the signature on push. In the AKS cluster, they configure the admission controller to only accept signed images. Misconfiguration: If content trust is not enabled, unsigned images can be deployed, leading to security risks. The solution: enable content trust and enforce it via Kubernetes policies.
Scenario 3: Automated Image Builds with ACR Tasks
A SaaS startup uses ACR Tasks to automatically rebuild images when the base image is updated. They configure a task that triggers on base image updates in the registry. The task pulls the base image, rebuilds the application image, and pushes the new version. This ensures that security patches in the base image are automatically applied. They also use multi-step tasks to run tests before pushing. Misconfiguration: If the task is not configured with the correct trigger (e.g., on source code commit instead of base image update), the automation fails. The solution: set the trigger to base_image_update and ensure the task has appropriate credentials to push.
What AZ-104 Tests on ACR
AZ-104 exam objective 3.3 covers 'Manage container images using Azure Container Registry'. You must know:
How to create and configure an ACR (SKU tiers, admin account, authentication methods).
How to push and pull images using Docker CLI and Azure CLI.
How to enable and configure geo-replication (Premium only).
How to integrate ACR with AKS (attach ACR, use managed identity).
How to secure ACR (RBAC roles, private endpoints, firewall rules).
How to use ACR Tasks for automated builds.
Common Wrong Answers and Why Candidates Choose Them
'You can enable geo-replication on Standard SKU.' – Wrong. Only Premium SKU supports geo-replication. Candidates confuse Standard with Premium because Standard is 'production-ready'. Remember: geo-replication is a Premium-only feature.
'Admin account is required for AKS to pull images.' – Wrong. AKS can use managed identity with AcrPull role. Admin account is for legacy or CI/CD without Azure AD. The exam tests modern methods.
'ACR stores images as VM snapshots.' – Wrong. ACR stores images as layers (blobs) in Azure Blob Storage, not as VHDs. This misconception arises from confusing containers with VMs.
'You can downgrade the SKU from Premium to Standard.' – Wrong. SKU downgrade is not supported. Candidates think it's like other Azure resources where you can scale down. This is a common trap.
Specific Numbers and Terms on the Exam
SKU names: Basic, Standard, Premium.
Storage limits: Basic 10 GB, Standard 100 GB, Premium 500 GB (scalable).
Concurrent operations: Basic 10, Standard 40, Premium 200.
Webhook limits: Basic 1, Standard 10, Premium 100.
Login server format: <registry-name>.azurecr.io.
RBAC roles: AcrPull, AcrPush, AcrDelete.
Geo-replication: Premium only.
Content trust: Premium only.
Private endpoints: Premium only.
Edge Cases and Exceptions
If you delete a repository, all tags and manifests are deleted. There is no soft delete.
ACR does not support anonymous pull access. All requests must be authenticated.
When using geo-replication, the replica is read-only for push operations; only the primary accepts writes.
ACR Tasks can run on a schedule, on source code commit, or on base image update.
How to Eliminate Wrong Answers
If a question mentions 'geo-replication', 'content trust', or 'private endpoints', the answer must involve Premium SKU.
If a question asks about AKS pulling images, look for 'managed identity' or 'AcrPull role' as the correct method.
If a question involves 'admin account', the context is usually CI/CD without Azure AD.
Remember that ACR is a private registry; there is no public access.
ACR is a private Docker registry; all operations require authentication.
Three SKUs: Basic (10 GB), Standard (100 GB), Premium (500 GB+).
Geo-replication is Premium-only; creates read-only replicas for low-latency pulls.
AKS authentication: use managed identity with AcrPull role, not admin account.
Content trust and private endpoints are Premium-only features.
ACR Tasks automate image builds triggered by code commits or base image updates.
RBAC roles: AcrPull, AcrPush, AcrDelete; custom roles possible.
SKU downgrade is not supported; only upgrade is allowed.
Vulnerability scanning requires Microsoft Defender for Cloud for Container Registries.
Login server format: <registry-name>.azurecr.io.
These come up on the exam all the time. Here's how to tell them apart.
Azure Container Registry (ACR)
Private by default; requires authentication for all operations.
Managed service; no infrastructure to maintain.
Integrated with Azure AD, RBAC, and Azure services.
Supports geo-replication (Premium) for low-latency pulls globally.
Content trust, vulnerability scanning, and private endpoints available.
Docker Hub
Public registry; private repositories require paid plan.
Self-managed or SaaS; Docker, Inc. manages the public hub.
No native Azure integration; uses Docker ID or tokens.
No geo-replication; single global endpoint.
Basic features; advanced security requires Docker Scout (paid) or third-party.
ACR with Admin Account
Uses static username and password.
Two passwords provided for rotation.
Suitable for CI/CD without Azure AD integration.
Less secure; credentials can be leaked.
Not recommended for production; use for testing only.
ACR with Azure AD Authentication
Uses Azure AD tokens or managed identities.
No static passwords; tokens expire.
Integrates with Azure AD for centralized identity management.
More secure; supports conditional access and MFA.
Recommended for production; used by AKS and Azure services.
Mistake
ACR stores images as virtual hard disks (VHDs).
Correct
ACR stores container images as a manifest and a set of layer blobs in Azure Blob Storage. Each layer is a tar archive, not a VHD. This is the same as Docker Hub.
Mistake
You can enable geo-replication on any ACR SKU.
Correct
Geo-replication is only available on the Premium SKU. Basic and Standard SKUs do not support it.
Mistake
The admin account is the only way for AKS to authenticate to ACR.
Correct
AKS can use a managed identity with the AcrPull role assigned. The admin account is a legacy method and not recommended for production.
Mistake
ACR automatically scans all images for vulnerabilities.
Correct
Vulnerability scanning is not automatic by default. You must enable Microsoft Defender for Cloud for Container Registries. Scanning can be triggered on push or manually.
Mistake
You can downgrade an ACR SKU from Premium to Standard.
Correct
SKU downgrade is not supported. You can only upgrade (e.g., Basic to Standard, Standard to Premium). Once upgraded, you cannot go back.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Geo-replication is only available on the Premium SKU. Use the Azure CLI command `az acr replication create --registry myregistry --location <region> --resource-group myrg`. This creates a replica in the specified region. The replica is read-only for pushes; all writes go to the primary. Pulls from the replica serve from local storage if available. You can have multiple replicas. Verify with `az acr replication list`.
Yes, you can enable the admin account on the registry. This provides a username and two passwords for authentication. However, this is less secure and not recommended for production. For automated scenarios, consider using repository-scoped tokens or managed identities instead.
The recommended method is to use a managed identity. When you create an AKS cluster with `az aks create --attach-acr myregistry`, the AKS cluster's kubelet identity is granted the AcrPull role on the ACR. Alternatively, you can manually assign the role using `az role assignment create`. You can also use a Kubernetes secret with admin credentials, but this is less secure.
ACR Tasks are a built-in feature of ACR that can build and push container images automatically based on triggers like source code commits, base image updates, or schedules. They run in Azure Container Instances. Azure Pipelines is a full CI/CD service that can also build images, but it offers more flexibility, integration with multiple source control systems, and advanced pipeline features. For simple container builds, ACR Tasks are easier to set up.
Yes, ACR supports OCI artifacts. You can store Helm charts, OCI image indexes, and other OCI-compliant artifacts. Use the `oras` CLI to push and pull these artifacts. For example, `oras push myregistry.azurecr.io/helm-chart:v1 mychart.tgz`.
Use the Azure CLI: `az acr repository delete --name myregistry --repository myimage --tag latest` to delete a specific tag. To delete an entire repository, omit the `--tag` parameter. You can also use the portal or REST API. Note: deletion is permanent; there is no recycle bin.
Content trust is a Premium feature that implements Docker Content Trust (Notary). It allows you to sign images to verify their integrity and origin. When enabled, only signed images can be pushed (if configured). Clients can verify signatures before pulling. This protects against tampering.
You've just covered Azure Container Registry (ACR) — now see how well it sticks with free AZ-104 practice questions. Full explanations included, no account needed.
Done with this chapter?