Docker · Containers in practice
What would you check before running Docker in production?
Short answer
Check immutable images, non-root runtime, resource limits, health and readiness, log shipping, secret handling, backup and restore, scanning, and a tested rollback path.
Production readiness is a set of explicit decisions, not a single tool. Walk through build, runtime, operations and recovery, and make sure each has an owner and a tested mechanism.
A practical checklist
- Images are pinned by digest, signed, scanned and rebuilt on a schedule
- Containers run as non-root with dropped capabilities and a read-only root where possible
- CPU, memory and pids limits are set from measured usage
- Healthchecks and probes reflect real dependency health
- Logs go to stdout and are shipped with rotation and retention
- Secrets come from a secret manager, not the image or plain env
- Persistent data has a tested backup and restore procedure
- Graceful shutdown handles SIGTERM within the stop timeout
- Metrics, dashboards and alerts cover errors, latency, restarts and capacity
- A rollback to the previous digest is documented and rehearsed
docker inspect --format "{{.Config.User}} {{.HostConfig.Memory}} {{.HostConfig.NanoCpus}}" api-1
docker inspect --format "{{.State.Health.Status}}" api-1
docker image inspect registry.example.com/api@sha256:abc123 --format "{{.RepoDigests}}"Also decide what Docker is not responsible for: scheduling across hosts, self-healing, multi-node storage and secret rotation. If those are requirements, a single Docker host is the wrong platform regardless of how well the container is built.
Follow-ups you should expect
Interviewers use these to check whether the first answer was understanding or memorisation.
- 1How do you verify the deployed container matches the intended configuration?
- 2What is missing from a single-host Docker setup for high availability?
- 3How do you rehearse a rollback?
- 4Which readiness item would you fix first and why?
Say it in the interview
I review build, runtime and recovery separately. That means pinned and scanned images, non-root execution, resource limits, real healthchecks, shipped logs, external secrets, tested backups and a rehearsed rollback. I also inspect the running container, not just the Dockerfile, and I am explicit about what a single Docker host cannot provide, such as multi-node failover.
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.