A vulnerability scan reports several CVEs in a running container. The analyst traces them to packages inherited from the base image, and the container is ephemeral. Which remediation is most appropriate?
Select an answer to reveal the explanation.
Short Explanation
Think of a container like a baked cake: if the recipe's ingredients are bad, frosting the slice won't fix it. You need to bake a new cake from a better recipe, so rebuild the image and redeploy. Patching the running container is the trap because ephemeral containers can vanish and the next instance inherits the same bad base.
Full Explanation
Container images are immutable build artifacts assembled from layers, so vulnerabilities inherited from a base image exist in the image's package manifest and layer contents, not merely in a running process. When a scan identifies CVEs introduced by the base image, remediation means changing the source image: update the base image or package versions, rebuild, test, and redeploy. This ensures new containers start from a patched state and preserves reproducibility across CI/CD. Patching inside a running container can temporarily reduce exposure, but it does not alter the template, is often lost when the container restarts, and violates immutable infrastructure expectations. Restarting the container with an updated host kernel addresses host-level vulnerabilities, not user-space packages supplied by the image, so the inherited CVEs remain. Applying a network rule to block exploitation is a compensating control that may limit attack paths but does not remove the vulnerable packages or satisfy vulnerability management closure. Exam caveat: if the stem says the CVEs are inherited from the base image and the container is ephemeral, prefer image rebuild over in-place patching. Operational check: identify the vulnerable package, update the build file or base image reference, rebuild, scan the new image, and redeploy.