Azure Container Registry

Understand the concept

In plain English

Azure Container Registry, or ACR, is a private place in Azure to store container images and related artifacts. Instead of pulling production images from a developer laptop or public registry, teams push approved images into a registry they control. AKS, Container Apps, App Service, pipelines, and other platforms can then pull those images. ACR also supports repository organization, access control, imports, tasks, retention, networking options, and geo-replication for serious container supply chains. It becomes the release shelf for containerized applications.

Why it matters

Azure Container Registry matters because production container reliability starts before the workload is scheduled. If images come from unknown sources, mutable tags, slow public registries, or credentials shared across teams, deployments become fragile and hard to audit. ACR gives teams a controlled image source close to Azure workloads, with identity, repository, retention, import, build, and replication capabilities. It helps platform teams answer which image is approved, who can push, which clusters can pull, and whether old tags should still exist. Without that control, container platforms inherit supply-chain, availability, and rollback risks. It also gives incident responders a digest-level trail when releases behave differently across environments.

Technical context

ACR sits in the container supply-chain and deployment architecture. It stores Docker-compatible images and OCI artifacts in repositories and tags, integrates with Microsoft Entra ID and Azure RBAC, and supports pulls from AKS, App Service, Container Apps, Batch, and pipelines. Premium features can include private endpoints, geo-replication, higher limits, and advanced security patterns. It connects to CI/CD, image scanning, Defender for Cloud, managed identity, webhooks, ACR Tasks, repository retention, and network-restricted deployment environments. That position makes it critical to both platform engineering and release governance.

Exam context

What to know

operator field manual with architecture, governance, CLI, and case-study depth

Where it is used

Where you see it

1. In the Azure portal, ACR appears as a Container Registry with repositories, access keys, networking, private endpoints, tasks, webhooks, and replication settings. for each registry
2. In Azure CLI, az acr show, repository list, import, task list, and login commands expose registry configuration, automation state, and image inventory. during release reviews
3. In AKS or App Service deployments, ACR appears through image references, pull identities, image pull errors, repository tags, digests, and rollout delays. during failed rollouts

Common situations

• Store approved production container images in a private Azure registry instead of relying on public registries.
• Allow AKS, Container Apps, or App Service to pull images using managed identity or scoped Azure permissions.
• Import external base images into a controlled registry so builds do not depend on internet pulls during release.
• Use geo-replication for multi-region container platforms that need faster, more reliable image pulls.
• Automate image builds, patch rebuilds, retention, and repository cleanup with ACR Tasks and lifecycle controls.

Illustrative Azure scenarios

These examples show how the concept can affect design and operations. They are illustrative scenarios, not customer claims.

Azure CLI

I use Azure CLI for ACR because registry work is repetitive, evidence-heavy, and often tied to pipelines. After ten years of Azure operations, I want commands that create registries, inspect SKUs, list repositories, check tags, import images, review tasks, and verify access without relying on portal screenshots. CLI also fits security reviews where teams need JSON proof of admin-user state, network rules, private endpoints, identity assignments, and retention policy. During deployment incidents, az acr commands quickly show whether the image exists, whether the registry is reachable, and whether the pipeline pushed the expected tag. This is especially useful when one bad tag blocks several dependent services.

az acr create --name <registry-name> --resource-group <resource-group> --sku Premium

az acr show --name <registry-name> --resource-group <resource-group>

az acr repository list --name <registry-name> --output table

az acr import --name <registry-name> --source <source-image> --image <target-image>

az acr task list --registry <registry-name> --resource-group <resource-group>

Architecture context

Architecturally, ACR is the trusted image distribution point between build systems and runtime platforms. I place it near AKS, Container Apps, App Service, and pipeline identities so production pulls do not depend on public registry availability or ad hoc credentials. Registry design should define naming, repository structure, tag immutability expectations, promotion flow, private networking, geo-replication, retention, and scanning. Premium tier is often justified when private endpoints, geo-replication, and higher operational limits matter. A good design separates build permission from pull permission and treats image promotion as a controlled release step, not a developer convenience. That discipline makes container releases reviewable, recoverable, and measurable.

Security

Security is direct because ACR controls which container images can reach production. Use Microsoft Entra authentication, Azure RBAC, managed identities, and scoped permissions instead of broad shared admin credentials. Disable the admin user unless a specific legacy workflow truly requires it. Restrict network access with private endpoints or firewall rules where needed, and connect Defender for Cloud or pipeline scanning to find vulnerable images. Avoid mutable latest tags for production and protect repository delete permissions. Review who can push, import, sign, scan, and pull images because a compromised image can bypass many runtime controls. Repository policies and review processes should match the criticality of each workload.

Cost

Cost is driven by registry SKU, storage consumed by images and artifacts, geo-replication, build tasks, network transfer, retention choices, and security tooling. Large images, duplicate tags, and unbounded build history increase storage quickly. Premium features cost more but may reduce downtime, latency, and security risk for critical workloads. Geo-replicating every repository to every region can waste money if only a few services are global. FinOps reviews should track storage by repository, stale tags, replication scope, task frequency, and whether build pipelines produce unnecessarily large images. Chargeback should consider which teams create the largest images and longest retention chains. monthly reviews

Reliability

Reliability depends on image availability, regional placement, tag discipline, registry limits, network reachability, and pull authentication. A cluster cannot deploy what it cannot pull. Geo-replication can reduce regional pull latency and improve availability for multi-region workloads, while retention and import practices preserve known-good release images for rollback. Overaggressive cleanup can remove images still referenced by running workloads. Private networking must be tested from each runtime environment. Operators should monitor failed pulls, repository existence, tag changes, replication status, and registry throttling. Reliable container operations start with predictable image distribution. Document the expected behavior if the registry, DNS, or private endpoint becomes unreachable.

Performance

Performance shows up as image push time, pull time, deployment startup, replication delay, and build-task duration. Large images slow rollouts and increase node disk pressure. Registries close to AKS or App Service regions reduce pull latency, and Premium geo-replication can help multi-region deployments. Pull failures or throttling may look like Kubernetes scheduling problems when the bottleneck is the registry. Operators should measure image size, layer reuse, pull duration, failed pulls, and rollout timing after new base images. Smaller, well-layered images and local registry placement usually improve deployment speed more than cluster changes. Build pipelines should fail when image growth crosses agreed release thresholds.

Operations

Operators manage ACR through registry inventory, repository and tag review, access assignments, network rules, private endpoints, import jobs, task runs, retention policy, replication status, and image scanning signals. Day-two work includes cleaning old tags, investigating failed pulls, rotating pipeline credentials, confirming managed identity access, and documenting which registry feeds each cluster or app. CLI is useful for listing repositories, importing base images, checking tasks, and capturing current state before security changes. Runbooks should name the registry, repository, tag, digest, runtime target, pull identity, and rollback image for every production deployment. Good teams also record image digests instead of relying only on human-readable tags.

Common mistakes

• Using mutable latest tags in production, which makes rollback and incident analysis much harder.
• Leaving the admin user enabled and sharing password-based registry access across pipelines or developers.
• Deleting old tags without checking whether running clusters, slots, or rollback plans still reference those images.