Container image digest

Understand the concept

In plain English

Container image digest is an immutable sha256 reference that points to one exact image manifest in a registry. In Azure, teams see it when a team pins a Container Apps, AKS, or Azure Container Instances deployment to the artifact that was approved, scanned, and released. It turns a vague deployment or policy discussion into a specific value that operators can verify in portal views, CLI output, or logs. The practical question is what it means, which resource owns it, which environment uses it, and what proof makes the next change safe.

Why it matters

Container image digest matters because it is the strongest proof that production is running the exact artifact the team approved. When teams misunderstand it, mutable tags can drift, rollback can pull the wrong build, and security teams may be unable to connect a vulnerability finding to a live workload. A precise glossary entry gives architects, developers, security reviewers, and operators the same vocabulary for design reviews, change tickets, and incidents. It connects the Azure feature to ownership, measurable objectives, runbook checks, and audit evidence. That shared view helps teams make safer choices under pressure, prove compliance quickly, and avoid treating a production control as a portal-only detail.

Technical context

Technically, Container image digest is the content address for a registry manifest, not a friendly release label. Engineers verify it through ACR repository metadata, deployment image references, digest-based pull strings, scan results, pull events, and release approvals. Important fields include registry login server, repository, digest, manifest media type, image tag, architecture, scan status, retention state, and consuming workload. In production reviews, capture subscription, resource group, region, identity, deployment name, and rollback notes before changing it. That context keeps troubleshooting tied to facts rather than assumptions.

Exam context

Compare with

Where it is used

Where you see it

1. You see Container image digest in container registries, deployment manifests, Kubernetes events, and image scan reports when confirming immutable sha256 digest, manifest, repository, and pulled artifact for release, audit, or incident evidence.
2. You see Container image digest during troubleshooting when a tag points to different content than expected and operators must connect portal state, CLI output, logs, metrics, owners, and rollback notes.
3. You see Container image digest in architecture reviews when teams decide how deployments pin exact container image content, how evidence is gathered, and how it affects security, reliability, operations, cost, and performance.

Common situations

• Use Container image digest during design reviews to connect the Azure concept to an owner, environment, and measurable production outcome.
• Inspect Container image digest before releases, audits, or incidents so the team works from current Azure evidence instead of assumptions.
• Automate repeatable checks for Container image digest when the same workload pattern appears across development, test, and production.
• Document how Container image digest affects rollback, security review, support escalation, and long-term governance.

Illustrative Azure scenarios

These examples show how the concept can affect design and operations. They are illustrative scenarios, not customer claims.

Azure CLI

Use Azure CLI for Container image digest when you need repeatable evidence, safe discovery, and scriptable checks across subscriptions, environments, and incidents.

az acr repository show --name <registry-name> --image <repository>@sha256:<digest>

az acr repository show-tags --name <registry-name> --repository <repository> --detail

az acr repository update --name <registry-name> --image <repository>@sha256:<digest> --write-enabled false

Architecture context

A container image digest is the immutable reference I trust when proving exactly what artifact is running. Tags are convenient, but a digest ties deployment to a specific manifest and protects production from silent tag movement. Architecturally, digest pinning connects CI/CD, registry governance, vulnerability scanning, rollback, and admission policy. I expect release evidence to include the registry, repository, tag, digest, build run, scan result, and environment where it was deployed. In AKS, Container Apps, and Container Instances, the digest helps separate image drift from configuration drift during incidents. Good teams promote by digest, keep rollback digests available, and avoid relying on mutable labels for regulated or high-change workloads.

Security

Security for Container image digest focuses on digest pinning, trusted registries, vulnerability results, repository locks, image signing, pull identity, and who can delete manifests. Review managed identities, RBAC assignments, private networking, secrets, policy exemptions, audit logs, and the exact people or automation that can change the setting. Prefer least privilege, approved repositories, documented break-glass access, and evidence captured before production changes. Watch for public endpoints, stale credentials, broad Contributor access, unreviewed images, or logs that reveal sensitive values. The security goal is to make misuse visible early and make every exception traceable to an owner, expiration date, business reason, and misuse signal.

Cost

Cost for Container image digest comes from registry storage, duplicate layers, retained rollback artifacts, geo-replication, scan volume, and wasted rebuilds caused by unclear image references. Some charges are direct, but many costs appear as incident response, duplicate environments, longer deployments, excessive telemetry, or support time caused by unclear ownership. Review budgets, tags, retention policies, data volume, region choices, automation frequency, and monitoring ingestion before scaling the design each month. Tie every cost increase to a business reason, expected duration, and measurement window. This lets finance distinguish intentional investment from waste and helps engineers avoid small configuration choices becoming monthly variance. Review trends before renewals.

Reliability

Reliability for Container image digest depends on registry availability, retained rollback digests, tag-to-digest mapping, architecture compatibility, and image pull success. Operators should know the expected healthy state, dependencies, failure symptoms, alert thresholds, and rollback path before a change window opens. Monitor resource state, logs, metrics, quota, latency, dependency health, and user-facing errors rather than relying on a portal screenshot alone. Test the failure path where possible, including denied access, unavailable dependencies, bad configuration, and restoration from the previous known-good state. Good reliability practice turns the term into an observable control that supports faster recovery and fewer repeated incidents. Review evidence after each release.

Performance

Performance for Container image digest is about image size, layer reuse, pull latency, registry location, digest availability, and startup behavior during scale events. Measure signals that users or workloads actually feel, such as startup time, latency, throughput, error rate, queue depth, CPU, memory, pull duration, moderation delay, or API response time. Avoid tuning one setting in isolation when identity, network path, region, cache state, dependency behavior, and resource limits may also influence results. Keep baseline measurements before and after changes so regressions are visible. The best performance reviews connect the term to a real bottleneck instead of the most obvious Azure setting.

Operations

Operationally, Container image digest belongs in runbooks, release notes, dashboards, and handoff checklists, not only in an engineer's memory. Teams should know which portal blade, CLI command, log query, metric, deployment file, or ticket proves the current state. Capture before-and-after evidence with subscription, resource group, region, resource IDs, owner, monitoring window, and rollback trigger. Use naming standards and tags so support teams can find the right resource during incidents. The practical operations win is repeatability: any qualified operator should be able to inspect, explain, and safely change it without guessing. Record the outcome for service reviews, audits, and accountable owners.

Common mistakes

• Treating Container image digest as a label instead of checking the owning resource, scope, identity, and live configuration.
• Copying a command from another environment without validating subscription, resource group, region, and safety impact.
• Closing an incident or release without saving the evidence that proves the setting was correct after the change.