How would you design an automated artifact repository cleanup policy?

WHAT THIS TESTS: The interviewer wants to see if you can translate business constraints into an automated governance system. They care about cost control, pipeline performance, security posture, and compliance traceability. The question separates engineers who think in scripts from those who design policies with safety, observability, and stakeholder alignment.

A GOOD ANSWER COVERS: First, classification criteria. Group artifacts by type such as container images, libraries, and binaries, then assign retention tiers. For example, untagged CI builds might live 7 days, release candidates 30 days, and production images 7 years or indefinitely. Second, state-aware rules. Distinguish between deployed artifacts, promoted tags, and orphaned layers. Never delete anything currently referenced by a running workload or a legal hold. Third, automation mechanics. Use a scheduled job or registry-native lifecycle policy with a mandatory dry-run phase, quorum approval for manual exceptions, and audit logging for every deletion event. Fourth, safety nets. Implement soft deletes with a grace-period trash bin, dependency checks against deployment manifests, and notifications to owning teams before permanent removal. Fifth, metrics and feedback loops. Track storage cost per team, registry pull latency, and policy violation counts to refine thresholds quarterly.

COMMON WRONG ANSWERS: Proposing a single global TTL like delete everything after 90 days ignores the difference between staging scratch images and compliance-bound production releases. Another red flag is skipping the dry-run step or failing to mention how you protect artifacts that are not recently pulled but are still baselined in long-term support contracts. Suggesting manual cleanup tickets instead of automation also signals immaturity at the senior level.

LIKELY FOLLOW-UPS: How would you handle an artifact that is no longer built but still required by a legacy microservice? What happens if a deleted image is referenced by an immutable infrastructure definition in Git? How do you attribute storage costs back to individual teams or pipelines? Would your policy change for open-source supply chain artifacts versus internal binaries?

ONE CONCRETE EXAMPLE: A team running a Docker registry for 500 developers starts with 2 terabytes of untagged layers. They define a policy where untagged images older than 14 days move to a low-cost trash bin for another 7 days before hard deletion. Release tags matching semver are retained for 1 year unless explicitly promoted to a protected production namespace, which is exempt. The policy runs nightly as a dry-run report posted to Slack for 3 weeks before enforcement mode is enabled. Within 2 months, storage drops by 60 percent and average image pull time improves by 25 percent, with zero accidental deletions of active base images.

Source: Harness Glossary