Container Interview Question

Why It Matters

Correct CMD/ENTRYPOINT usage ensures reliable container shutdowns and simplifies debugging, directly impacting production stability and interview credibility.

Key Takeaways

• Docker run creates new container; passing bash replaces CMD.
• Use docker exec to inspect a running container without stopping app.
• ENTRYPOINT runs always; CMD provides default arguments, can be overridden.
• Prefer JSON-array form for CMD/ENTRYPOINT to forward signals correctly.
• Combine ENTRYPOINT python app.py with CMD default flags for flexible deployment.

Summary

The video tackles a common Docker interview puzzle: why a container built with a CMD of python app.py shows only a Bash shell when launched with docker run -it myimage bash. It explains that docker run always starts a fresh container, and any command supplied after the image name completely replaces the image’s CMD, so Bash overwrote the Python process.

Key technical points include using docker exec to attach a shell to an already‑running container, running the app in detached mode (‑d) for debugging, and understanding the distinction between CMD and ENTRYPOINT. CMD offers default arguments that can be overridden, while ENTRYPOINT is immutable unless explicitly overridden with --entrypoint. The recommended pattern is to set ENTRYPOINT to the main executable (e.g., python app.py) and CMD to default flags (e.g., ‑‑port 880).

The presenter also highlights the subtle but critical difference between shell‑form and exec‑form syntax. Shell form wraps the command in /bin/sh, which intercepts termination signals, causing Kubernetes to force‑kill containers during graceful shutdowns. Using the JSON‑array (exec) form lets signals reach the application directly, ensuring clean termination.

For practitioners, the takeaway is clear: use docker exec for live debugging, define immutable ENTRYPOINT with mutable CMD for flexibility, and always prefer the exec‑form syntax to avoid signal‑handling pitfalls. Mastering these nuances not only solves interview questions but also prevents 3 a.m. production outages.

Original Description

One line in your Dockerfile decides if your app lives or dies. Seriously.

Your teammate builds an image, deploys it, everything's green. Then he tries to look inside the container with bash and the app is just not there.

No crash log. No stack trace. Nothing.

Here's the thing nobody tells you early enough:

CMD gets replaced the moment you pass anything after docker run

ENTRYPOINT doesn't — it always executes

The right pattern? Use both. ENTRYPOINT for the executable, CMD for default args

And always use JSON array syntax — or Kubernetes can't gracefully stop your container

This one question separates "I've used Docker" from "I've shipped Docker in production."

Have you been burned by this before? Tell us in the comments 👇

#docker #devops #dockerfile #kubernetes #cmdvsentrypoint #programming #techinterview #containers #coding #dockertips #cloudcomputing #softwareengineering #backend #sre #learntocode #interviewprep #buildinpublic #techtok