Docker · Containers in practice
What Docker best practices do you follow?
Short answer
Use small pinned base images, multi-stage builds, a tight .dockerignore, non-root users, explicit resource limits, structured logs, healthchecks and immutable deployment tags.
Good Docker practice is mostly about making the artifact small, reproducible and predictable to operate. The same rules apply whether you run Compose on one host or Kubernetes in a cluster.
Build practices
- Pin base image versions or digests and rebuild for patches
- Use multi-stage builds and copy only runtime artifacts
- Order layers from least to most volatile
- Keep the build context small with .dockerignore
- Use exec-form ENTRYPOINT and CMD for signal handling
- Run as a dedicated non-root user
Runtime practices
- Set memory, CPU and pids limits from measured usage
- Log to stdout with rotation or central shipping
- Add healthchecks that test real dependencies
- Keep configuration in the environment and secrets in a secret store
- Use named volumes for state and back them up
- Deploy immutable tags or digests and keep a rollback path
Review the running container, not only the Dockerfile. Configuration can be overridden at run time, and a correct image can still be deployed with no limits, a writable root filesystem or a root user.
Follow-ups you should expect
Interviewers use these to check whether the first answer was understanding or memorisation.
- 1Which practice has the biggest impact on security?
- 2Why inspect the running container instead of only the Dockerfile?
- 3When is it acceptable to run as root in a container?
- 4How do you keep base images patched?
Say it in the interview
I keep images small and reproducible with pinned bases, multi-stage builds and a tight context, and I run them as non-root with explicit limits. At runtime I ship logs centrally, use real healthchecks, keep secrets out of the image and deploy immutable tags. I verify the deployed container too, because runtime overrides can undo a good Dockerfile.
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.