This chapter covers Azure Container Registry (ACR), a managed Docker registry service for storing and managing container images. Understanding ACR is essential for the AZ-900 exam because it demonstrates how Azure supports container-based application deployment, a key pillar of modern cloud-native architecture. This objective area (Azure Architecture Services, Objective 2.2) carries approximately 10-15% of the exam weight. By the end of this chapter, you will grasp what ACR is, how it works, its core components, and how it fits into the broader Azure ecosystem.
Jump to a section
Imagine your company ships products to customers using standardized shipping containers. You need a secure warehouse near the port to store, manage, and retrieve these containers. Azure Container Registry (ACR) is that warehouse for your software containers (Docker images). Just as a warehouse has designated bays for different container types, ACR organizes images into repositories. When you build a new version of your product, you 'push' the container to ACR, like delivering a new container to your warehouse. When your shipping department (Azure Kubernetes Service or other orchestrators) needs a specific container, it 'pulls' it from ACR, similar to retrieving a container from the correct bay. ACR also supports geo-replication, like having multiple warehouses in different ports worldwide to reduce shipping time. Access is controlled by Azure Active Directory, like a security guard checking badges. ACR uses a private network endpoint (like a dedicated loading dock) to keep traffic secure. This eliminates the need for each team to maintain their own garage (local registry) and ensures a single, secure, audited source of truth for all container images.
Azure Container Registry (ACR) is a private, managed Docker registry service that stores and manages container images and related artifacts. In modern application development, applications are increasingly containerized using technologies like Docker. Containers package an application with its dependencies, ensuring it runs consistently across environments. These containers are built from images stored in a registry. ACR solves the problem of where to securely store these images, how to version them, and how to control access. Without a private registry, teams would either use public registries (like Docker Hub) which raise security and compliance concerns, or they would need to self-host a registry, incurring operational overhead. ACR integrates natively with Azure services like Azure Kubernetes Service (AKS), Azure Container Instances (ACI), and Azure DevOps, providing a seamless deployment pipeline.
How It Works – Step-by-Step Mechanism
ACR operates on a client-server model. The client (Docker CLI, Moby, or other OCI-compliant tools) interacts with the ACR REST API over HTTPS.
Authentication and Authorization: Before any operation, the client must authenticate with ACR. ACR supports several authentication methods: Azure Active Directory (Azure AD) individual login, service principal (for automated tools), managed identity (for Azure resources), and admin account (legacy, not recommended). When you run az acr login, the Azure CLI obtains an Azure AD token and then uses it to authenticate with the registry. This token is valid for one hour. ACR also supports repository-scoped permissions via tokens (preview), allowing fine-grained access control.
Image Push: To upload an image, you first tag it with the ACR login server name (e.g., myregistry.azurecr.io/myapp:v1). Then you execute docker push myregistry.azurecr.io/myapp:v1. The Docker client sends the image layers to ACR, which stores them in blob storage accounts within the Azure region. ACR automatically replicates across multiple storage accounts within the region for durability. The image manifest is stored in a database.
Image Pull: When a pull request is made (e.g., docker pull myregistry.azurecr.io/myapp:v1), ACR authenticates the request, checks permissions (if using repository-scoped tokens), and then serves the image layers from the blob storage. The pull operation is optimized with layer caching.
Geo-Replication: For multi-region deployments, you can enable geo-replication. This creates replicas of the registry in other Azure regions. When an image is pushed to one region, it is automatically replicated to all enabled regions. Pulls from a region are served from the local replica, reducing latency and egress costs. Geo-replication is a premium tier feature.
Key Components, Tiers, and Pricing Models
ACR has several components:
Registry: The top-level resource. Each registry has a globally unique name (e.g., myregistry.azurecr.io).
Repository: A collection of related images (e.g., myapp, nginx).
Tag: A version label for an image (e.g., v1, latest).
Manifest: Metadata describing the image layers and configuration.
Layer: Each file system change in a Docker image.
Service Tiers (SKUs):
Basic: Up to 10 GB storage, 1 webhook, no geo-replication. Suitable for development.
Standard: Up to 100 GB storage, 10 webhooks, no geo-replication. Suitable for production.
Premium: Up to 500 GB storage (scalable), 100 webhooks, geo-replication, private endpoints, repository-scoped tokens, and content trust. Suitable for enterprise.
Pricing is based on storage consumed (per GB/month) and data transfer (per GB egress). Geo-replication incurs additional cost per replica. The premium tier also offers a higher baseline throughput.
Comparison to On-Premises Equivalent
On-premises, you would typically run a private Docker registry using open-source software like Docker Registry (distribution) or Harbor. This requires managing virtual machines, storage (NFS or SAN), backups, high availability, and security patching. You would also need to handle authentication yourself (e.g., LDAP integration). ACR eliminates this operational burden: Microsoft manages the infrastructure, provides 99.9% SLA (premium tier includes SLA), and integrates with Azure Active Directory for authentication. On-premises registries often lack geo-replication, requiring complex manual replication scripts. ACR's geo-replication is a turnkey feature.
Azure Portal and CLI Touchpoints
Azure Portal:
Navigate to "Container registries" and click "Create".
Choose subscription, resource group, registry name, location, and SKU.
Enable admin user (not recommended) or use Azure AD authentication.
After creation, you can view repositories, tags, webhooks, and tasks.
For geo-replication, go to the registry's "Replications" blade.
Azure CLI:
Create a registry: az acr create --resource-group myResourceGroup --name myRegistry --sku Basic
Login: az acr login --name myRegistry
List repositories: az acr repository list --name myRegistry
Delete a repository: az acr repository delete --name myRegistry --repository myapp
Enable geo-replication: az acr replication create --registry myRegistry --location westus
Build an image using ACR Tasks: az acr build --registry myRegistry --image myapp:v1 .
Important Limits:
Registry name: 5-50 alphanumeric characters, globally unique.
Storage: Basic 10 GB, Standard 100 GB, Premium up to 500 GB (can be increased via support).
Number of repositories: Soft limit of 10,000 per registry.
Number of tags: Soft limit of 100,000 per repository.
Create an Azure Container Registry
Begin by creating a new ACR instance in the Azure portal, CLI, or PowerShell. You specify a globally unique name (e.g., `myacr123`), a resource group, location, and SKU (Basic, Standard, or Premium). For exam purposes, remember that the name must be alphanumeric and 5-50 characters. Behind the scenes, Azure provisions a REST API endpoint (e.g., `myacr123.azurecr.io`) and allocates storage accounts. The SKU determines storage limits, throughput, and features like geo-replication. Basic is free for the first 30 days but limited; Premium is needed for geo-replication and private endpoints.
Authenticate to the Registry
Before pushing or pulling images, you must authenticate. The recommended method is to use Azure AD authentication via `az acr login`. This command retrieves an Azure AD token and stores it in the Docker config file (`.docker/config.json`). Alternatively, you can use a service principal (for CI/CD) or managed identity (for Azure services like AKS). Avoid using the admin account (username/password) as it is less secure. On the exam, know that ACR supports OAuth2 tokens and that tokens expire after one hour, requiring re-authentication.
Tag and Push an Image
To upload a Docker image, you first tag it with the ACR login server name. For example, if your local image is `myapp:latest`, tag it as `myacr123.azurecr.io/myapp:v1`. Then run `docker push myacr123.azurecr.io/myapp:v1`. The Docker client sends each layer to ACR, which stores them in Azure blob storage. ACR verifies the manifest and stores it in its metadata database. The push operation may take time depending on image size and network speed. After successful push, the image is available for pull.
Pull and Run the Image
To use the image, any authenticated client can pull it using `docker pull myacr123.azurecr.io/myapp:v1`. ACR checks authentication and authorization (if using repository-scoped tokens), then serves the layers. The pull is optimized: if layers already exist locally, they are not downloaded again. You can then run the container using `docker run myacr123.azurecr.io/myapp:v1`. For production, you typically use an orchestrator like AKS to pull images automatically. AKS can authenticate using a managed identity or a pull secret.
Enable Geo-Replication (Premium)
If your application is deployed in multiple Azure regions, you can enable geo-replication to reduce latency and improve resilience. In the portal, go to the registry's "Replications" blade and add a new replication region. The CLI command is `az acr replication create --registry myRegistry --location westus`. Once enabled, images pushed to any region are automatically replicated asynchronously to all other replicas. Pulls are served from the local replica. Geo-replication is only available in the Premium SKU. Note that replication may have a slight delay (minutes) for large images.
Scenario 1: Microservices Deployment on AKS
A fintech company runs a microservices-based trading platform on Azure Kubernetes Service (AKS). Each microservice (e.g., order service, payment service) is containerized. The team uses Azure Container Registry to store all images. They use ACR Tasks to automatically build images from code commits in Azure DevOps. AKS is configured with managed identity to pull images from ACR without storing credentials. Geo-replication is enabled (Premium tier) because the application is deployed in East US and West Europe. This ensures low-latency pulls for each region. Cost: They pay for storage (~$0.10 per GB/month) and egress (pulls within the same region are free, but cross-region egress incurs charges). A common mistake is not using managed identity for AKS, leading to credential management overhead. If ACR is not geo-replicated, pulls from West Europe would cross regions, increasing latency and egress costs.
Scenario 2: CI/CD Pipeline with ACR Tasks
A SaaS startup uses GitHub Actions to build and deploy their application. They use ACR Tasks to automate image building. When a developer pushes code to the main branch, a GitHub Actions workflow triggers az acr build, which sends the Dockerfile and context to ACR. ACR Tasks builds the image in the cloud (no local Docker needed) and pushes it directly to the registry. The task can also run automated tests inside the container. This eliminates the need for a separate build server. The startup uses the Basic SKU initially due to low volume. As they scale, they upgrade to Standard. A pitfall is forgetting to set up authentication for the GitHub Actions workflow (using a service principal). Without proper RBAC, the pipeline fails.
Scenario 3: Secure Compliance with Private Endpoints
A healthcare company must comply with HIPAA regulations. They use ACR with Premium SKU and enable private endpoints. This ensures that all traffic to ACR stays within the Azure backbone network and never traverses the public internet. They also enable content trust to sign images, ensuring only signed images can be pulled. The security team sets up repository-scoped tokens to give developers write access only to specific repositories. A common error is not disabling public network access after enabling private endpoints, leaving a potential attack vector. Also, they must configure DNS resolution correctly for the private endpoint hostnames.
Objective 2.2: Describe Azure compute and networking services
AZ-900 tests your understanding of Azure Container Registry as a compute service supporting containerized applications. You need to know:
ACR is a managed private Docker registry.
It stores and manages container images.
It integrates with AKS, ACI, and Azure DevOps.
It supports geo-replication (Premium only).
Authentication methods: Azure AD, service principal, managed identity, admin account.
SKUs: Basic, Standard, Premium (know features of each).
Common Wrong Answers and Why Candidates Choose Them
"ACR is a container orchestrator like AKS": Candidates confuse ACR with AKS because both deal with containers. Reality: ACR is only a registry (storage), not an orchestrator. AKS runs containers.
"ACR supports geo-replication in all tiers": Candidates assume geo-replication is standard. Reality: Only Premium tier supports geo-replication.
"Admin account is the recommended authentication method": Candidates see the admin account in the portal and think it's easiest. Reality: Azure AD authentication is recommended for security; admin account is legacy.
"ACR can only store Docker images": Candidates think it's Docker-specific. Reality: ACR supports OCI artifacts, including Helm charts and Open Container Initiative (OCI) images.
Specific Terms and Values
Login server: <registry-name>.azurecr.io
SKUs: Basic (10 GB), Standard (100 GB), Premium (500 GB, geo-replication, private endpoints)
Authentication: az acr login uses Azure AD tokens, valid for 1 hour.
Geo-replication: Available in Premium, replicas in different regions, automatic.
Webhooks: Up to 1 (Basic), 10 (Standard), 100 (Premium).
Edge Cases and Tricky Distinctions
ACR vs. Docker Hub: Azure asks: "Which service provides a private registry?" ACR is the answer. Docker Hub is public (unless paid).
ACR Tasks: It can build images in the cloud without a local Docker engine. This is a distinct feature from ACR itself.
Repository-scoped tokens: Only in Premium tier. Allows fine-grained permissions (e.g., read-only to one repository).
Content trust: Also Premium only. Enables image signing (Docker Content Trust).
Memory Trick
Think "ACR = A Container Repository". For tiers: "Basic for Basics (low storage), Standard for Standard production, Premium for Premium features (geo-replication, private endpoints, content trust)."
Azure Container Registry is a managed private Docker registry for storing and managing container images.
ACR integrates with Azure Kubernetes Service (AKS), Azure Container Instances (ACI), and Azure DevOps.
Three SKUs: Basic (10 GB storage), Standard (100 GB), Premium (500 GB + geo-replication, private endpoints, content trust).
Geo-replication is only available in Premium tier; it automatically replicates images to multiple Azure regions.
Authentication methods: Azure AD (recommended), service principal, managed identity, admin account (legacy).
ACR supports OCI artifacts, not just Docker images (e.g., Helm charts).
ACR Tasks enable cloud-based image building without a local Docker engine.
The login server format is <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 to access.
Managed by Microsoft; no infrastructure to maintain.
Integrated with Azure services (AKS, ACI, DevOps).
Supports geo-replication (Premium tier).
Pricing based on storage and data transfer.
Docker Hub
Public by default; private repos require paid plan.
Self-managed or managed by Docker Inc.; not integrated with Azure.
No native integration with Azure; requires manual configuration.
No geo-replication; images are stored in one region.
Free for public repos; paid for private repos and teams.
Mistake
Azure Container Registry is a container orchestrator.
Correct
ACR is a registry for storing container images, not an orchestrator. Orchestration (running containers) is done by Azure Kubernetes Service (AKS) or Azure Container Instances (ACI).
Mistake
Geo-replication is available in all ACR tiers.
Correct
Geo-replication is only available in the Premium SKU. Basic and Standard tiers do not support it. You must upgrade to Premium to enable geo-replication.
Mistake
The admin account is the best way to authenticate to ACR.
Correct
The admin account is a legacy feature and is not recommended. Azure AD authentication (via `az acr login`, service principal, or managed identity) is more secure and should be used instead.
Mistake
ACR can only store Docker images.
Correct
ACR supports OCI (Open Container Initiative) artifacts, including Docker images, Helm charts, and other OCI-compliant artifacts. It is not limited to Docker.
Mistake
ACR Tasks are part of Azure DevOps, not ACR.
Correct
ACR Tasks are a feature of ACR itself. They allow you to build container images in the cloud directly from source code using the `az acr build` command, without needing a local Docker engine.
Azure Container Registry (ACR) is used to store and manage private container images and OCI artifacts. It provides a secure, scalable registry that integrates with Azure services like AKS and ACI. You push images to ACR after building them, and then pull them to deploy containers. Exam tip: ACR is not an orchestrator; it's a storage service for container images.
The recommended authentication method is Azure AD authentication using `az acr login`. This obtains a token valid for one hour. Alternatively, you can use a service principal (for automated tools), managed identity (for Azure resources), or the admin account (not recommended). On the exam, remember that the admin account is legacy and less secure.
Basic: up to 10 GB storage, 1 webhook, no geo-replication. Standard: up to 100 GB storage, 10 webhooks, no geo-replication. Premium: up to 500 GB storage (scalable), 100 webhooks, geo-replication, private endpoints, content trust, and repository-scoped tokens. Exam tip: Geo-replication and private endpoints are exclusive to Premium.
Yes, ACR supports OCI (Open Container Initiative) artifacts, including Helm charts, OCI images, and other formats. It is not limited to Docker images. This is a common exam point: ACR is an OCI-compliant registry.
Geo-replication is a Premium tier feature that replicates your registry to multiple Azure regions. When you push an image to one region, it is automatically replicated asynchronously to all enabled replicas. Pulls are served from the local replica, reducing latency. Replication may take a few minutes to complete.
ACR Tasks is a feature of ACR that allows you to build container images in the cloud using the `az acr build` command. You can provide a Dockerfile and source code, and ACR will build the image and push it to the registry. This eliminates the need for a local Docker engine. ACR Tasks can also be triggered by Git commits or base image updates.
AKS can authenticate to ACR using a managed identity or a pull secret. When deploying pods, AKS pulls images from ACR. You can attach an ACR to an AKS cluster using `az aks update --attach-acr`. This integration allows seamless deployment without storing credentials. Exam tip: Managed identity is the recommended method.
You've just covered Azure Container Registry — now see how well it sticks with free AZ-900 practice questions. Full explanations included, no account needed.
Done with this chapter?