Show that patching in place reverts and fixing the image does not

applied · 70 min · Objective 4.1

Task

Remediate the same finding two ways against an elastic fleet: patch the running instances, and rebuild the image. Then trigger a replacement and see which fix survived. This is the single most useful thing to know about vulnerability management in a cloud.

Steps

  1. Build an image with a deliberately outdated package and deploy four replicas from it. Scan one running container and record the finding in lab/remediate.md. Scan the container's FILESYSTEM, not its image: mkdir fs && docker export <container> | tar -x -C fs/, then trivy rootfs fs/ (or grype dir:fs/). The image a container came from never changes, so scanning it would hide both the in-place fix and its disappearance.
  2. Patch IN PLACE: update the package inside each running container. Re-scan and confirm the finding is gone from the running fleet.
  3. Trigger a replacement -- delete a pod, or scale down and back up. Scan the NEW container and record whether the finding returned.
  4. Now fix properly: rebuild the image with the updated package, and roll the deployment to the new image version.
  5. Trigger a replacement again, scan the new container, and record the result. Write the two-sentence rule about where a fix must be applied in an elastic estate.

Verify

grep -Eci 'in place' lab/remediate.md
grep -Eci 'returned|reappear|back' lab/remediate.md
grep -Eci 'image' lab/remediate.md
grep -Eci 'did not return|absent|clean' lab/remediate.md

The file must record the finding returning after an in-place patch and not returning after an image rebuild. If the in-place patch seemed to survive replacement, check that you exported the NEW container rather than a survivor, and that nobody moved the image tag to a rebuilt image in between -- a cached copy of the old image would bring the finding straight back, not hide it.

This is an independent study companion for CompTIA Cloud+ CV0-004 and is not produced by or endorsed by CompTIA.