Containers: registry, Container Instances, Container Apps

Nordlicht Reisen GmbH, a fictional travel agency, has packaged its booking interface as a container image. You are to store the image in a private place, start a single container briefly, and run the interface as a service that starts more copies under load. The exam calls this: create and manage an Azure container registry, provision a container by using Container Instances and Container Apps, and manage sizing and scaling.

Prior knowledge: What containers are and where they sit between virtual machines and serverless is covered in "AZ-900 compact," lesson 2.3. How developers build an image and use a container app for background work is covered in K3, lesson 3.5.7 ("Background work in Container Apps"). Here you get the administrator's view: create, secure, size, scale, clean up. Kubernetes with AKS is not part of it; that is an elective module.

Azure Container Registry

An Azure Container Registry (ACR) is a private registry for container images and related artifacts. The name must be unique in Azure and consists of 5 to 50 lowercase letters and digits. The login server (login server) is called <name>.azurecr.io. With the Domain Name Label feature, the server name contains a hash value, according to Microsoft; read loginServer from the output.

The tiers

When you create a registry, you choose the tier (SKU, in the portal "Pricing Plan"). The numbers come from Microsoft's page "SKU features and limits" (November 11, 2026):

All tiers have the same programming interfaces. You can change the tier later without downtime (az acr update --name <registry> --sku Premium); when downgrading from Premium, you must remove geo-replications first. More storage than is included costs extra.

Creating a registry and bringing images in

az group create --name rg-az104-container --location germanywestcentral
az acr create --resource-group rg-az104-container --name <registryname> --sku Basic

Three ways bring an image into the registry:

Microsoft points out that az acr import needs no local Docker installation and also runs in Azure Cloud Shell. Cloud Shell, on the other hand, does not have the Docker service (dockerd) that docker push needs. For az acr build, Microsoft gives a note: ACR Tasks runs are temporarily paused for subscriptions with Azure credit. This course therefore uses az acr import for the exercise.

az acr import --name <registryname> --source mcr.microsoft.com/azuredocs/aci-helloworld:latest --image aci-helloworld:v1
az acr repository list --name <registryname> --output table
az acr repository show-tags --name <registryname> --repository aci-helloworld --output table

The first two commands take only the registry name, not the login server. The list shows the names of the repositories in one column; the second command shows the tags. Azure PowerShell has Import-AzContainerRegistryImage for this. According to Microsoft, the importing identity needs the permission to trigger imports on the target registry (role Container Registry Data Importer and Data Reader).

Access to the registry

The roles for images are AcrPull (pull images) and AcrPush (pull and upload). A managed identity of a container app gets AcrPull on the registry, and then the app pulls its image without a password. A registry can be created in the mode "RBAC plus ABAC for repositories" (--role-assignment-mode); there, AcrPull and AcrPush do not apply, and you use Container Registry Repository Reader and Writer. The mode is shown by az acr show --name <registryname> --query roleAssignmentMode. The token from az acr login is valid for three hours.

According to Microsoft, the portal needs the admin account to deploy an image directly from the registry to Container Instances or Container Apps.