8.7 Managing Container Images, Tags & Azure Container Registry

Managing and Distributing Windows Server Container Images

Building an image is only half of the container objective. The AZ-800 blueprint lists "Create Windows Server container images" and "Manage Windows Server container images" as two separate skills, and the second one is where most candidates lose marks. Managing images means knowing where they come from, how they are named and versioned, how you move them between a build host and a private registry, and how you reclaim disk space when a Server Core layer quietly consumes 2 GB on every node. This section covers the image lifecycle after the docker build in section 8.4.

---

1. Image Anatomy: Layers, Tags and Digests

A container image is an immutable, layered artifact. Each instruction in a Dockerfile adds a read-only layer; a running container adds a thin writable layer on top. Layers are content-addressed and shared, so ten containers built from the same Server Core base consume one copy of that base on disk.

Two different things identify an image, and the exam likes the distinction:

Because tags are mutable, :latest is never a safe production reference. Pin to an explicit OS tag such as ltsc2022 or ltsc2025, or to a digest.

Inspect what a host already holds:

# List local images with repository, tag, image ID and size
docker images

# Show the layer history and the command that created each layer
docker history mcr.microsoft.com/windows/servercore:ltsc2025

# Full metadata as JSON, including digest, OS version and layer diff IDs
docker inspect mcr.microsoft.com/windows/nanoserver:ltsc2025

---

2. Where Windows Base Images Come From

Windows container base images are served from the Microsoft Container Registry (MCR) at mcr.microsoft.com. MCR has no catalog experience of its own — it relies on existing catalogs such as Docker Hub for discovery, which is why you browse tags on Docker Hub but always pull from MCR:

docker pull mcr.microsoft.com/windows/servercore:ltsc2025

Microsoft publishes four base images. The sizing and capability differences drive real exam scenarios:

[!IMPORTANT] The windows/server image is smaller than the windows image (3.1 GB vs 3.4 GB), inherits Server Core's reliability improvements, and is the one that supports GPU acceleration. The windows image isn't available for Windows Server 2025. Candidates routinely assume "Windows Server" must be the larger of the two — it isn't.

Microsoft also ships insider variants (windows/servercore/insider, windows/nanoserver/insider) for hosts running Insider builds. Match insider images to insider hosts only.

The build-matching rule, restated for images

Section 8.4 introduced isolation modes; it matters again when you choose an image tag. Under process isolation the container base image build must match the host OS build exactly — an ltsc2022 image will not start under process isolation on an ltsc2025 host. Hyper-V isolation supplies a matching kernel in a utility VM, which is what allows a down-level image to run. When a scenario says "the image fails to start after we upgraded the hosts," the fix is either re-tagging to the new OS version or switching to --isolation=hyperv.

---

3. Tagging and Pushing to a Private Registry

Azure Container Registry (ACR) is the private registry for hybrid Windows workloads. The workflow is always the same four moves: authenticate, tag with the fully qualified login server, push, pull.

# 1. Authenticate. Azure CLI is the recommended path; it refreshes the Docker credential store.
az login
az acr login --name myregistry

# Azure PowerShell equivalent
Connect-AzAccount
Connect-AzContainerRegistry -Name myregistry

# 2. Create an alias of the local image using the fully qualified registry path.
#    'samples' is a namespace that keeps the registry root uncluttered.
docker tag myapp:1.0 myregistry.azurecr.io/samples/myapp:1.0

# 3. Push the tagged image
docker push myregistry.azurecr.io/samples/myapp:1.0

# 4. Pull it on any other host that can authenticate
docker pull myregistry.azurecr.io/samples/myapp:1.0

[!TIP] Always use the fully qualified registry name in all lowercase (myregistry.azurecr.io) both when logging in and when tagging. docker push myapp:1.0 without the registry prefix targets Docker Hub, not ACR — a very common lab failure.

The registry login server is always <registryname>.azurecr.io. For unattended pipelines you authenticate with a service principal rather than user credentials: docker login myregistry.azurecr.io and supply the service principal appID as the username and its secret as the password.

---

4. Managing Images in the Registry and Reclaiming Space

Registry-side inventory and cleanup are separate from local cleanup — deleting a local image does nothing to the registry.

# Registry inventory
az acr repository list --name myregistry --output table
az acr repository show-tags --name myregistry --repository samples/myapp --output table

# Delete the manifest behind a tag, its unique layers, and every other tag pointing at it
az acr repository delete --name myregistry --image samples/myapp:1.0

The Azure PowerShell module Az.ContainerRegistry splits this into two cmdlets, and the difference is exam-worthy:

Local host cleanup uses different verbs entirely:

# Remove one local image (fails if a container still references it)
docker rmi myregistry.azurecr.io/samples/myapp:1.0

# Reclaim space from dangling (untagged) layers
docker image prune

containerd-only hosts

Modern Windows Server container hosts may run containerd with no Docker CLI present. The image verbs move to ctr and crictl:

crictl images          # list images known to the CRI runtime
crictl pull mcr.microsoft.com/windows/nanoserver:ltsc2025
crictl rmi <image-id>  # remove an image

---

5. Exam Traps