Lesson 7 of 30

Registries & CI/CD Integration

Q: How do you make sure the Docker image running in production is provably the same one that was tested in staging?

A strong answer covers: Build the image once in CI, tag it traceably (e.g. git SHA), and push it to a registry; Promote the same image forward through environments via re-tagging (docker tag), never rebuilding per environment; Explain why rebuilding separately per environment risks producing a subtly different image even from identical source.

The general CI/CD lesson in this platform's Practices track covers build-test-deploy as a pipeline shape. This one is narrower: the specific decisions a pipeline has to make once what it's shipping is a Docker image.

12 min read

Check your understanding

Every option explains itself — why the right one is right, and why each wrong one is wrong. Miss one and it comes back later on a spaced-repetition schedule.

Question 1 of 3

In a build-once-promote-everywhere pipeline, what does `docker tag registry.example.com/myapp:a1b2c3d registry.example.com/myapp:production` actually do?

It adds an additional tag pointing at the already-built image — no rebuild happensIt triggers a fresh rebuild of the image, now labeled for the production environmentIt copies the image's files into a new, separate image with a different digest

Stuck? Ask the AI tutor

Hints without spoilers, and a plain explanation of why a wrong answer was wrong — answered only from this lesson. Free account, no card.

Interview questions on Registries & CI/CD Integration

What interviewers actually ask about this, and what a strong answer has to cover.

How do you make sure the Docker image running in production is provably the same one that was tested in staging?

A strong answer covers

Build the image once in CI, tag it traceably (e.g. git SHA), and push it to a registry
Promote the same image forward through environments via re-tagging (docker tag), never rebuilding per environment
Explain why rebuilding separately per environment risks producing a subtly different image even from identical source

Likely follow-ups

If the image itself stays constant across environments, what actually does differ between staging and production?
Where should image vulnerability scanning happen in this pipeline, and what should it be able to do — just report, or actually block a build?

Practice these with the AI interviewer →

The plain-language idea

Once a pipeline's deployable artifact is a Docker image, one principle should govern almost every other decision: build once, promote the same image everywhere. CI builds and tags exactly one image per change, pushes it to a registry once, and every environment after that — staging, then production — pulls and runs that exact same image, never a fresh rebuild per environment.

The alternative (rebuilding the image separately for staging and for production) reintroduces the very problem containers exist to solve: two builds, even from identical source, aren't guaranteed identical — a base image update between builds, a registry serving a different "latest" of a dependency, or simple build-environment drift can produce a production image that was never actually the one tested in staging.

See it in a real thing: a tagging strategy that actually means something

# In CI, after tests pass:
docker build -t registry.example.com/myapp:$(git rev-parse --short HEAD) .
docker push registry.example.com/myapp:$(git rev-parse --short HEAD)

# Promoting the SAME image to staging, then production — never rebuilding:
docker tag registry.example.com/myapp:a1b2c3d registry.example.com/myapp:staging
docker push registry.example.com/myapp:staging
# ...tests pass in staging...
docker tag registry.example.com/myapp:a1b2c3d registry.example.com/myapp:production
docker push registry.example.com/myapp:production

Build once, promote the same image forwardStep 1 of 3

CI builds once and tags the image with the git SHA — a1b2c3d.

staging and production here are just additional tags pointing at the same image digest as the original git-SHA-tagged build — docker tag doesn't rebuild anything, it just adds another name for an image that already exists. The image that ran in staging is provably, byte-for-byte, the same one that reaches production.

What people usually miss

Watch out

Registry authentication in CI uses short-lived, scoped credentials, not a shared personal login. Most CI providers integrate with a registry's own token or IAM-role-based auth (e.g. AWS ECR's aws ecr get-login-password) specifically so pipeline credentials can be rotated, scoped to push-only, and revoked independently of any individual's personal access.
Image vulnerability scanning belongs in the pipeline, as a gate, not as a separate manual step. Tools like Trivy or a registry's built-in scanner (ECR, GHCR, Docker Hub all offer one) can fail a build automatically on a critical CVE in a base image or dependency, catching a known-vulnerable package before it ships rather than after.
A registry's storage isn't infinite in practice, even if it feels that way. Every CI run that pushes a uniquely-tagged image without a retention/cleanup policy accumulates images indefinitely — most teams need an explicit lifecycle policy (e.g. "delete untagged images after 14 days") rather than manual cleanup.
"Build once, promote everywhere" doesn't mean config is the same everywhere. The image itself is identical across environments; the configuration and secrets injected at runtime (from the earlier lesson in this track) are what actually differ per environment — the image staying constant is exactly what makes that separation possible to reason about.

Why this matters in interviews

"How do you make sure what's running in production is actually what was tested in staging?" is a real, senior-leaning question, and "build once, tag with something traceable like a git SHA, promote that same image forward" is a precise, confident answer — versus "we redeploy for each environment," which is the answer that reveals the gap this lesson exists to close.