1.1 ACR: Build, Store, Version & Manage Images

Azure Container Registry (ACR) is the private registry most Azure AI and cloud developers use to build, store, version, and manage container images. On the AI-200 exam, ACR sits at the start of the containerized-solutions domain: you push images into ACR, then App Service, Azure Container Apps, or AKS pull those images to run. Treating ACR as a first-class artifact store—not a temporary Docker Hub mirror—keeps deployments repeatable and secure.

Why ACR Exists on Azure

Public registries work for demos, but production AI services need private images, Azure-native identity, and network controls. ACR gives you:

• A fully managed Docker-compatible registry (OCI images and Helm charts)
• Integration with Microsoft Entra ID, managed identities, and Azure RBAC
• Optional private endpoints and firewall rules so images never traverse the public internet
• Tight coupling to Azure build and deploy tools (ACR Tasks, App Service continuous deployment, AKS image pull secrets via managed identity)

When an App Service Linux web app is configured for a custom container, the default mental model is: build → push to ACR → App Service pulls the tagged (or digest-pinned) image.

Registry SKUs: Basic, Standard, Premium

ACR ships three service tiers. You choose a SKU when you create the registry; you can change tiers later, but Premium-only features require the Premium tier.

Geo-replication (Premium concept)

Geo-replication replicates a Premium registry to additional Azure regions. Pulls from a nearby replica reduce latency and outbound transfer for regional AKS or App Service deployments. From a developer perspective you still push to one registry login server; ACR handles regional replicas behind the scenes. Exam scenarios often contrast a single-region Standard registry (fine for one App Service region) with Premium geo-replication when the same image must be pulled efficiently in multiple regions.

Remember: geo-replication is about image distribution, not about running containers. Compute (App Service, AKS) still runs where you deploy it; ACR replicas simply make the pull faster and more resilient.

Build and Push Images into ACR

You can build images locally with Docker and push them, or build in Azure (covered in the next section on ACR Tasks). A local flow looks like:

1. Authenticate: az acr login --name <registryName> (or use a service principal / managed identity in CI).
2. Tag the image with the ACR login server: <registryName>.azurecr.io/<repository>:<tag>.
3. Push: docker push <registryName>.azurecr.io/<repository>:<tag>.

Repository and naming conventions

Inside a registry, images live in repositories (for example ai-api, embeddings-worker). Good practice for AI-200-style solutions:

• One repository per deployable service
• Tags that encode environment or build metadata (dev, staging, 1.4.2, git-abc1234)
• Avoid overwriting latest as your only production identifier

Versioning: Tags Versus Digests

This distinction appears frequently in Azure container questions.

Tags

A tag is a human-readable pointer to a manifest. Tags are mutable by default: pushing myapi:1.0 again can replace what 1.0 points to. That convenience is dangerous for production rollbacks and audits.

Digests

Every pushed image manifest has a content-addressable digest, typically written as sha256:<hex>. Referencing @sha256:... pins the exact bytes of the image configuration and layers. Even if someone retags v1, the digest still resolves to the original content.

For App Service and Kubernetes manifests, prefer digest pins (or immutable tags enforced by policy) once a release is validated.

Manage Images Day to Day

Listing and inspecting

Use Azure CLI or the portal to list repositories, tags, and manifests. Inspecting a manifest shows architecture (amd64/arm64), layers, and created time—useful when debugging “wrong image” incidents after a push.

Retention and cleanup

Registries accumulate failed builds and intermediate tags. Retention policies (available on supported SKUs) can automatically untag or delete old manifests based on age or count. Pair retention with CI naming so you never delete the tag your production App Service still references.

Locking and permissions

• Repository-scoped permissions and Azure RBAC roles (AcrPull, AcrPush, AcrDelete, Owner) limit who can mutate images.
• Avoid enabling the registry admin user long-term; it uses a shared username/password. Prefer managed identities for App Service pull access and workload identities / service principals for pipelines.

Network and security controls

Premium registries support private endpoints, so pull traffic stays on your virtual network. Combine with Entra authentication and disable anonymous pull. For regulated AI workloads, also consider content trust / signed images where your pipeline requires provenance.

Connecting ACR to Downstream Hosts

ACR does not run your app; hosting services pull from it:

• App Service: configure the container image URL (and optional continuous deployment webhook from ACR).
• Azure Container Apps / AKS: use managed identity or pull secrets with AcrPull.
• ACR Tasks: build and optionally run containers using ACR-managed compute (next section).

Exam-focused checklist

When a scenario asks how to store and version images for Azure hosting, map the answer to ACR capabilities:

1. Choose SKU based on geo-replication / private link needs.
2. Push to <name>.azurecr.io/repo:tag.
3. Prefer digests for production.
4. Authenticate with RBAC + managed identity.
5. Clean up with retention policies so registries stay manageable.

Mastering ACR image management is the foundation for every later container hosting skill on AI-200: if the wrong image lands in the registry—or the right image is tagged ambiguously—App Service and AKS will happily run the mistake at scale.