Container image

What it is

A container image is an immutable package containing an application, its runtime dependencies, metadata, and a filesystem assembled from layers. A container is a running process created from that image; the image is not the running workload.

Why it exists and what to understand first

Images make the application/runtime boundary portable and repeatable. First understand git, packages, processes, ports, and the difference between a build artifact and a runtime. A Dockerfile describes how to assemble layers; a registry stores named image tags or digests; a container host pulls and runs the image.

Relationships, choices, and failure modes

The build produces an image, Azure Container Registry stores it, and ACI or Container Apps pulls it using an authorized identity. The handoff fails when the image reference is wrong, the registry is unreachable, or the runtime principal lacks pull permission. A tag can move, so deployment traceability should prefer an immutable digest. An image is not a package feed item and does not replace an application artifact when the target runtime is not container-based.

Worked example

Northwind builds orders:2026.09.16, pushes it to ACR, records its digest, and deploys that digest to a staging revision. After health checks, it promotes the same digest. Rebuilding during promotion could make the tested and deployed bytes differ.

Where it appears

AZ-204 compute module, before ACR, ACI, Container Apps, App Service containers, and AZ-400 build/release artifacts.

Re-audit

📘 Sources: Microsoft Learn — Serverless containers in Azure and Azure Container Registry overview.