Before enabling a retention rule, read the preview list, compare it with deployed images and digest references, check multi-arch and attached artifacts, confirm evidence is stored elsewhere, and write down who can stop the rule. Treat deletion as irreversible unless your registry says otherwise.
Why a checklist
Both Amazon ECR and Google Artifact Registry give you a way to see what a policy would do before it acts. ECR calls it a lifecycle policy preview and says to use it to confirm which images the policy expires. Artifact Registry offers a dry run, with changes taking effect in about a day. The preview is only useful if you know what to look for.
The seven checks
- Read the full preview list. Do not skim the count. Open the oldest and newest entries and a few from the middle.
- Compare with what is deployed. Pull the image references from your clusters and deployment config. Any overlap is a bug in the rule or a gap in your tag scheme.
- Search for digest references. Azure warns that systems pulling by digest break if untagged manifests are deleted. Look in Helm values, manifests and admission policies.
- Check multi-arch images. ECR says an image referenced by a manifest list cannot be expired until the list is. Confirm the preview does not list children without parents.
- Check attached artifacts. Signatures, SBOMs and attestations may follow their subject image. See does deleting an image delete its SBOM and signature.
- Confirm evidence lives elsewhere. Keep the digest, SBOM and scan record in a store with its own retention. See keep the evidence after you delete the image.
- Name an owner and a stop button. Someone should be able to disable the rule fast and know who to tell.
Test with canary images
Push a few throwaway images that match each rule, one per class, and confirm they land where you predict. This is cheap and catches wildcard mistakes, such as the four wildcard limit per string that ECR documents.
Start conservative
Begin with a long age or a high count and tighten later. A rule that is too loose costs storage. A rule that is too tight can cost a production outage.
After enabling
ECR states images become expired within 24 hours after meeting criteria, and records actions as CloudTrail events. Review those events after the first cycle and compare to your prediction. Where the registry offers no audit event, take a before and after listing of the repository.
Related reading
For a rollout of the registry side of scanning, see first registry scan baseline and ratchet plan.
Try it yourself
Click through it at your own pace, or open it full screen.
Watch how a monitored inventory changes over time. The same idea applies to your registry: look at it before and after the rule runs.
Quick check
Is a preview enough on its own?
No. It shows what the rule matches, not what your clusters run. Compare it with deployed image references.
Can I undo a retention rule that deleted too much?
Not reliably. Azure states deleted image data is unrecoverable. Rebuild from source if needed.
Sources
- Amazon ECR lifecycle policies
- Artifact Registry cleanup policies
- Azure Container Registry retention for untagged manifests
Last reviewed: 19 October 2026.