Docker · Containers in practice
What are common Docker mistakes you have seen?
Short answer
Deploying latest, running as root, baking secrets into images, ignoring log rotation, using one container for many processes, and treating a volume as a backup are frequent mistakes.
Most production incidents with Docker come from a small set of habits rather than exotic features. A review checklist catches them before they reach production.
The usual suspects
- Using the latest tag, so the deployed artifact is ambiguous
- Running as root and adding --privileged when something fails
- Copying secrets into the image or passing them as build args
- Leaving the default json-file log driver without rotation
- Putting a database and an application in one container
- Writing logs to files inside the container instead of stdout
- Ignoring SIGTERM, so shutdowns drop in-flight requests
- Storing persistent data in the writable layer
- Assuming a volume is a backup
- Building with a huge context that includes node_modules and .git
Another common error is assuming a healthcheck restarts a container. It reports state; restart policy or the orchestrator handles recovery. Confusing the two leads to services that appear healthy in dashboards while never recovering.
Many mistakes are really defaults that are fine for a demo and wrong for production. The fix is usually explicit configuration and a short review checklist, not a more complex platform.
Follow-ups you should expect
Interviewers use these to check whether the first answer was understanding or memorisation.
- 1Why is running multiple processes in one container a problem?
- 2What is wrong with using --privileged to fix a permissions issue?
- 3How do you catch these issues in review?
- 4Which mistake causes the most severe production impact?
Say it in the interview
The mistakes I see most are deploying latest, running as root, baking secrets into images and ignoring log rotation. I also see teams treat a healthcheck as an automatic restart or a volume as a backup. I catch these with a short review checklist covering tags, user, secrets, logs, signals and persistence, because they are configuration habits rather than obscure features.
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.