A municipal CD pipeline promotes a civic API that talks to Meraki and DNA Center. Operators need reliable rollback to the last known-good build. Which image naming practice gives CD a stable release identity?
Select an answer to reveal the explanation.
Short Explanation
Think of a version tag like a stamped permit number on a blueprint—you can always pull that exact set. latest is a moving nickname, so rollback becomes guesswork when last week’s build vanished under a new latest.
Full Explanation
Immutable image tags give continuous delivery a fixed release identity: promoting myapp:1.4.2 or a git-sha digest means every environment pulls the same bytes the pipeline tested. Rollback is then a redeploy of that known reference rather than a search for whatever “newest” meant yesterday. Floating latest fails because the nickname moves with every push, so the last known-good civic API build can disappear under a new digest and operators lose a stable pin for Meraki/DNA Center consumers. Relying on untagged dangling image IDs from a build agent is equally fragile—those IDs are local, garbage-collectable, and never a portable release contract across registries or clusters. Overwriting one tag on a weekly schedule and trusting cache timestamps does not create history; it mutates the name in place and leaves rollback dependent on whether someone retained an older digest by accident. Exam caveat: immutability of the tag string still requires registry retention and digest pinning policies—retagging the same name later reintroduces the floating-tag failure mode. Operational check: confirm the deploy manifest references the promoted tag or digest, pull that reference in staging, and verify the running container’s image ID matches the release record before promoting the municipal API further.