Operators retagged :release in OCIR so it now points at yesterday’s build, and a cluster that pulls :release silently changed artifacts. How should a team pin a specific push?
Select an answer to reveal the explanation.
Short Explanation
A version tag like :release can be moved to a new build. A digest (or a tag you never retarget) pins the exact push so pulls stay stable.
Full Explanation
A mutable tag such as :release can be moved to point at a different manifest after operators retag. Clusters that pull by that tag can silently receive yesterday’s (or tomorrow’s) build without any change to the Deployment’s image string. To pin a specific push, identify the image by digest (sha256:…) or by a tag your process never retargets. Digests are content-addressed: they refer to one immutable manifest for that push, so pulls stay bit-stable even if :release moves.
Deleting every tag so only untagged layers remain is not a pinning strategy and complicates operable references. The tenancy display name is not an immutable content address for an image. Pinning only by a git branch name stored in Object Storage metadata does not bind the kubelet to a specific registry manifest; branch names move just like tags unless the deploy path resolves to a digest.
Exam caveat: digests pin the manifest—understand whether your tooling also verifies signatures if supply-chain policy requires it. Operational check: after a push, record the digest from OCIR or docker images --digests, deploy with image@sha256:…, retag :release to another build, and confirm the running workload’s resolved digest did not change.