A delivery platform stores 400 microservice images in Amazon ECR across teams, facing stale vulnerable images and rising storage spend. Leadership wants automatic vulnerability detection, cleanup of old tags, and blocked mutable overwrites. Which ECR configuration governs image security and lifecycle?

The correct configuration combines enhanced scanning (Amazon Inspector) on push and continuously with a lifecycle policy that expires untagged images and tag immutability, which together cover detection, cost, and integrity for 400 images. Continuous scanning rescans existing images when new CVEs are published and covers OS and programming-language packages, while a lifecycle rule on untagged images prunes the orphaned manifests that CI rebuilds leave behind and that inflate storage spend, and immutable tags block overwrites that would hide provenance. Basic scanning with lifecycle cleanup and immutability fails on detection because basic scanning is limited to scan on push or manual scans and covers OS packages only, so images that were clean when pushed become vulnerable without any automatic rescan, leaving the stale vulnerable images the team complains about. Enhanced continuous scanning with immutability but retaining all image history fails on cost because nothing expires old or untagged images, so storage spend keeps growing. Enhanced continuous scanning with lifecycle cleanup but mutable tags fails on integrity because a tag can be repushed to point at a different digest, masking a vulnerable image as safe and breaking rollback trust. For exams, separate basic push-only OS scanning from enhanced continuous scanning with language coverage, and remember lifecycle policies address cost while immutability addresses integrity. Practically, confirm the enhanced scan type with continuous scanning enabled, a lifecycle rule with tagStatus untagged and an age or count limit, and immutability verified by a rejected duplicate tag push.