An on-call engineer patches a CVE inside a long-lived utilities-billing container with docker exec and apt-get. What is the Docker-native fix so the running instance matches what is in the registry?
Select an answer to reveal the explanation.
Short Explanation
Patching a live container with docker exec makes a snowflake that no longer matches the registry. Rebuild the image and replace the container—immutability at the container layer.
Full Explanation
Immutability at the container layer means the running utilities-billing instance should match a known image in the registry. After an on-call engineer patches a CVE with docker exec and apt-get, the live filesystem has diverged from every tagged artifact. The Docker-native fix is to bake the patched packages (or updated base) into a new image, push that image, and replace the container so runtime and registry agree again. Future hosts and CI pulls then get the fix without tribal knowledge of what was typed into an interactive shell.
Leaving the mutated container running and documenting packages in a wiki preserves a snowflake: the next redeploy from the old image reintroduces the CVE, and the wiki rots. Exporting the writable layer to Object Storage and attaching it as a Block Volume confuses ephemeral container mutation with durable block storage architecture; it does not restore image provenance. Using Resource Manager to terraform the live container filesystem in place is the wrong tool—Infrastructure as Code manages OCI resources, not ad-hoc package trees inside a running Docker writable layer.
Exam caveat: docker exec remains useful for diagnosis, but production CVE fixes belong in the Dockerfile or base image pipeline, not as permanent live edits. Operational check: after rebuild and replace, compare the image digest of the running container to the digest in OCIR for that tag, and re-run the vulnerability scan on the new image to confirm the CVE is gone from the artifact you will actually redeploy.