How would you design an automated artifact repository cleanup policy?
.webp&w=1600&q=75)
Balancing cost, compliance, and speed via tiered artifact retention. A strong answer covers age rules, deployment state, protected tags, and dry-run gates.
What's really being asked
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.
The full answer
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.
The mistakes people make
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.
What usually comes next
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?
A 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.
Interview question
When designing an automated artifact cleanup policy, which approach best prevents accidental deletion of active production artifacts while controlling storage costs?
- a.Tier retention by artifact type and deployment state, enforce a mandatory dry-run phase, and use soft deletes with dependency checks against running workloadsCorrect
- b.Delete all untagged images immediately and retain every tagged image for 7 years to guarantee compliance
- c.Set one global 90-day TTL for all images and rely on manual restore requests if something critical is deleted
- d.Run nightly cleanup scripts that delete artifacts not pulled in the last 30 days, posting results to Slack without a grace period
Why? this is the answer
The correct approach combines tiered retention, dry-run validation, and state-aware soft deletes as outlined in the card. Option D is tempting because it automates cleanup and reports results, but deleting by last-pull date risks removing artifacts still required by legacy microservices or long-term support contracts.
Just read this? Test yourself on what you have been reading.
Read the original → harness.io
- #ci/cd
- #artifact management
- #cost optimization
- #devops
- #governance
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on ci/cd — each one lists the topics its interview covers.
See open roles