6.1 Azure Container Registry and Image Workflow

What ACR does in an administrator workflow

Azure Container Registry, or ACR, is a managed private registry for container images and OCI artifacts. In AZ-104 terms, it is not the compute platform. It is the place where images are stored, secured, scanned by connected tooling, imported, replicated, and pulled by services that actually run containers. When a question says a development team has produced an image and the administrator must deploy it to Azure Container Instances, Azure Container Apps, App Service for Containers, or AKS, ACR is commonly the registry choice.

A basic image workflow has four parts. First, build the image from a Dockerfile or import an existing image. Second, push or import the image into a registry repository with a tag. Third, grant a runtime identity permission to pull the image. Fourth, configure the compute resource with the registry server name, image name, tag, and credentials or managed identity.

The login server format matters: <registry-name>.azurecr.io. Image references are usually written as <registry-name>.azurecr.io/<repository>:<tag>. A common exam trap is giving only repository:tag to a service that expects the full registry path, or creating the container instance before the identity has pull rights.

Tier and capability choices

Portal path: Azure portal > Container registries > Create for a registry, then use Repositories to inspect pushed images and tags. Use Access keys only when the scenario permits admin credentials. For production, prefer Microsoft Entra identities and role assignments.

CLI examples:

az acr create \
  --resource-group rg-compute \
  --name examacr104 \
  --sku Premium \
  --location eastus

az acr login --name examacr104

docker tag web:v1 examacr104.azurecr.io/apps/web:v1
docker push examacr104.azurecr.io/apps/web:v1

az acr import \
  --name examacr104 \
  --source mcr.microsoft.com/azuredocs/aci-helloworld:latest \
  --image samples/aci-helloworld:latest

Authentication and authorization

ACR uses Azure RBAC for registry operations. For a runtime service that only needs to pull images, assign AcrPull at the registry scope. For build or push workflows, AcrPush is more appropriate. The built-in admin account is easy for demos but is usually the wrong answer for least privilege because it creates registry-wide username and password credentials.

Managed identity is the clean exam answer when the compute service supports it. For example, an App Service app running a custom container can use a managed identity to pull from ACR. Container Apps also supports managed identity for registry authentication. If the compute platform or scenario does not support identity-based pull, credentials may be required, but choose the least privileged option available.

Troubleshooting pull failures follows a predictable tree:

1. Confirm the image reference includes the login server, repository, and tag.
2. Confirm the image tag exists in Repositories or with az acr repository show-tags.
3. Confirm the runtime identity has AcrPull on the registry.
4. Confirm the registry firewall allows the caller or that private connectivity is configured.
5. Confirm DNS and routing work if a private endpoint is used.
6. Check whether the service is pulling from the expected region or replica.

Useful commands:

az acr repository list --name examacr104 --output table
az acr repository show-tags --name examacr104 --repository apps/web --output table
az role assignment create \
  --assignee <principal-id> \
  --role AcrPull \
  --scope $(az acr show -g rg-compute -n examacr104 --query id -o tsv)

Network isolation and private access

Premium ACR supports private endpoints and firewall restrictions. This is where AZ-104 blends compute, networking, and identity. If a registry denies public network access and a container platform cannot reach the private endpoint, authentication is not the only problem. The pull request must also resolve the registry name to the private endpoint address and route over the private network.

For private endpoint scenarios, validate the private DNS zone link. The registry login server still looks like <name>.azurecr.io, but the name should resolve privately from the workload network. If the question mentions a VNet-integrated compute service, a private endpoint, and a failed pull after public access is disabled, suspect DNS or subnet integration before changing image tags.

ACR Tasks and image maintenance

ACR Tasks can build images with az acr build, run quick tasks, or automate builds from source changes. For AZ-104, know the use case more than every task trigger option. If the requirement is to build a container image in Azure and place it in ACR without installing Docker locally, az acr build is a strong fit.

az acr build \
  --registry examacr104 \
  --image apps/web:v2 \
  .

Administrators also need to manage repository hygiene. Untagged images and old tags consume storage. ACR retention policies and purge-style automation are common operational controls, especially when frequent builds produce many tags. The exam may describe rising registry costs or failed pushes due to quota pressure; deleting unused manifests or increasing the tier can both be relevant depending on the requirement.

Exam traps

Do not confuse ACR with Container Instances or Container Apps. ACR stores images; it does not run web apps by itself. Do not use storage account SAS tokens for registry access. ACR authorization is controlled through registry credentials, Microsoft Entra identity, and Azure RBAC roles such as AcrPull and AcrPush.

Do not choose the admin account when a managed identity and AcrPull role assignment meet the requirement. Do not forget that private endpoint and firewall decisions can break image pulls even when the password or role assignment is correct. Do not assume geo-replication exists in every tier; Premium is the tier to associate with geo-replicated registries.

A final scenario pattern: a container app fails to start after a new image is pushed. If the app still points to v1, pushing v2 does nothing. You must update the compute resource to reference the new tag or use a deployment process that updates the revision, slot, or container setting.