Docker · Containers in practice

How do container registries work and how do you use them safely?

MediumregistriesdistributionauthenticationUpdated Oct 2026
Quiz this track

Short answer

A registry stores image manifests and layers, and clients pull by tag or digest. Use authenticated private repositories, immutable tags and a retention policy for production images.

A registry is an HTTP service that stores layers by digest and manifests that reference them. Docker Hub, GitHub Container Registry, ECR, GCR and ACR all implement the same distribution API with different authentication and policy features.

sh
docker login registry.example.com
docker tag api:1.0.0 registry.example.com/team/api:1.0.0
docker push registry.example.com/team/api:1.0.0
docker pull registry.example.com/team/api@sha256:abc123
Push by tag for humans, deploy by digest for immutability.

Operational concerns

  • Use short-lived credentials or workload identity instead of long-lived passwords
  • Enable tag immutability so a release tag cannot be overwritten
  • Set retention and cleanup rules to control storage cost
  • Use a pull-through cache or mirror for rate limits and latency
  • Restrict who can push to production repositories

A registry is also a trust boundary. If an attacker can push to a repository your cluster pulls from, they can run their code. Enforce signing or admission policies, and separate build and deploy credentials.

Deleting a tag does not necessarily delete the underlying layers immediately. Garbage collection is a separate registry operation.

Follow-ups you should expect

Interviewers use these to check whether the first answer was understanding or memorisation.

  1. 1What is the difference between a tag and a digest in a registry?
  2. 2Why enable tag immutability?
  3. 3How do you avoid Docker Hub rate limits in CI?
  4. 4What happens to layers when a tag is deleted?

Say it in the interview

A registry stores manifests and content-addressed layers, and clients pull by tag or digest. I use private repositories with short-lived credentials, immutable release tags and cleanup policies. I also treat push access as a trust boundary, so production pulls are restricted and preferably verified by signature or admission policy.

Use this as a model, not a script. Saying it in your own words is what makes it survive follow-up pressure.

Related questions

Reading is step one

Now say it out loud.

Understanding an answer and delivering it under pressure are different skills. Rehearse this topic in a live Docker mock interview and get scored feedback on depth, clarity and confidence.