Design a Docker artifact system for cost, traceability, and speed
Tests cost-speed-auditability tradeoffs for artifacts at scale. Strong answers cover tiered storage with lifecycle policies,immutable build provenance,regional caching, and automated garbage collection. Red flag: infinite mutable storage with no cleanup rules.
What's really being asked
This question evaluates whether you can design a socio-technical system, not just pick a tool. The interviewer cares about lifecycle governance: how you trade off storage cost against deployment latency and compliance traceability at organizational scale. They want to see awareness of immutable infrastructure, tiered storage economics, and the operational reality of thousands of engineers pushing artifacts daily.
The full answer
A good answer hits four things in order. First, a tiered storage architecture with automated lifecycle policies: hot storage for recent production images, warm for staged releases, and cold or deleted for old dev builds, with rules triggered by age, tag patterns, or branch names. Second, traceability through immutable content-addressable digests rather than mutable tags, plus metadata linking each artifact to a git commit SHA, CI pipeline ID, and build timestamp, ideally stored in an artifact metadata store or SBOM repository. Third, performance through regional distribution: a primary registry in each major geography, pull-through caches in clusters, and local registry mirrors so node pulls do not traverse continents or hit a single global endpoint. Fourth, cost control through garbage collection of untagged manifests and orphaned layers, team-level storage quotas, and retention rules that differentiate between ephemeral feature branch images and signed production releases that must be kept for years.
The mistakes people make
Common wrong answers include relying on a mutable latest tag for deployments, which destroys traceability and causes cache coherency bugs. Another red flag is proposing manual cleanup scripts without retention SLAs, which inevitably fail and turn the registry into an expensive dumping ground. Suggesting a single global registry without regional caches shows inexperience with distributed deployment latency. Ignoring layer deduplication or manifest lists also signals shallow knowledge of container registry internals.
What usually comes next
Interviewers often push deeper with three questions. How would you handle base image updates when all tags are immutable? They expect you to discuss rebuild pipelines and new digests. What happens if the registry is down during a production incident? They want failover registries or pre-pulled images on nodes. How do you charge storage back to teams? They want showback or quota enforcement per business unit.
A concrete example
A concrete example is a platform with three registries: a fast dev registry with a seven-day TTL on untagged images and no geo-replication; a staging registry with thirty-day retention and vulnerability scanning gates; and a production registry geo-replicated across three continents, requiring image signing, storing SBOMs for two years, and keeping release artifacts indefinitely. Each Kubernetes cluster runs a pull-through cache, and a nightly job garbage-collects orphaned blobs, reducing storage growth by roughly sixty percent in the first quarter.
Interview question
Which architecture best balances cost, traceability, and speed for a large-scale container registry?
- a.Maintain separate registries per team with mutable tags, layer deduplication, and ad-hoc scripts to delete old images when storage fills
- b.Store all images indefinitely in a single global registry with mutable version tags and manual quarterly cleanup
- c.Geo-replicate every image across all regions with content-addressable digests but no retention limits to guarantee auditability and fast pulls
- d.Use tiered storage with automated lifecycle policies, immutable digests linked to build metadata, regional pull-through caches, and garbage collection of untagged manifestsCorrect
Why? this is the answer
Tiered lifecycle policies with immutable digests and regional caches directly optimize the tradeoff between storage cost, deployment latency, and compliance traceability. Option C is tempting because content-addressable digests improve traceability, but keeping every image forever without retention rules or tiering inevitably explodes storage costs and ignores automated garbage collection.
Just read this? Test yourself on what you have been reading.
Read the original → cloud.google.com
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