What is the Difference Between ENTRYPOINT and CMD?
Understand the difference between Docker ENTRYPOINT and CMD, how they combine, and why exec form matters for signal handling.
Expected Interview Answer
ENTRYPOINT defines the fixed, always-executed command a container runs, while CMD supplies default arguments to that command (or a default full command if no ENTRYPOINT exists) that a user can override at `docker run` time.
When both are set in exec form, Docker concatenates them so ENTRYPOINT is the executable and CMD provides its default arguments; anything passed after the image name on `docker run` replaces CMD entirely but leaves ENTRYPOINT untouched, which is why ENTRYPOINT is used to lock in a binary like an application server while CMD supplies a default flag such as a config path. If only CMD is set with no ENTRYPOINT, the whole CMD is treated as the default command and is fully replaceable by run-time arguments. Shell form (`CMD npm start` without brackets) wraps the command in `/bin/sh -c`, which adds a shell process, breaks proper signal forwarding to the app, and drops any arguments appended at `docker run`, so exec form (`CMD ["npm", "start"]`) is preferred in production images. A common production pattern uses ENTRYPOINT for a wrapper script that does setup (like waiting for a dependency) and then `exec`s into CMD’s arguments, combining fixed behavior with user-overridable defaults.
- Locks in the intended executable while keeping arguments flexible
- Exec form ensures proper signal handling (SIGTERM reaches the app)
- Enables wrapper-script patterns for startup logic before the main process
- Makes images predictable while still configurable at run time
AI Mentor Explanation
ENTRYPOINT is like a fixed team rule that every net session must start with the designated warm-up drill, no matter who runs the session. CMD is like the default set of throw-downs suggested for that drill, which the coach on duty can swap out for a different set of throw-downs on any given day. The warm-up drill itself never changes, but the specific throw-downs are just a replaceable default. If a coach specifies custom throw-downs, only that part changes; the mandatory warm-up structure stays fixed.
Step-by-Step Explanation
Step 1
Set ENTRYPOINT
Declare the fixed executable that must always run, e.g. `ENTRYPOINT ["node"]`.
Step 2
Set CMD as default args
Provide default arguments passed to ENTRYPOINT, e.g. `CMD ["server.js"]`.
Step 3
Run with defaults
`docker run myapp` executes `node server.js` using the CMD default.
Step 4
Override at run time
`docker run myapp worker.js` replaces CMD only, executing `node worker.js` while ENTRYPOINT stays fixed.
What Interviewer Expects
- Clear articulation that ENTRYPOINT is fixed, CMD is default/overridable arguments
- Knowledge that `docker run` arguments replace CMD, not ENTRYPOINT
- Awareness of exec form vs shell form and its signal-handling implications
- Ability to describe the wrapper-script + exec CMD production pattern
Common Mistakes
- Saying ENTRYPOINT and CMD are interchangeable
- Using shell form in production, breaking SIGTERM propagation
- Believing `docker run` arguments override ENTRYPOINT by default
- Forgetting that CMD alone, with no ENTRYPOINT, is fully replaceable
Best Answer (HR Friendly)
“ENTRYPOINT is the part of the container that never changes — the actual program we always want to run. CMD is just the default set of options passed to that program, and anyone starting the container can override those options without touching the core program itself, which gives us both consistency and flexibility.”
Code Example
# Dockerfile
ENTRYPOINT ["node"]
CMD ["server.js"]
# Runs: node server.js
docker run myapp
# Runs: node worker.js (only CMD is replaced)
docker run myapp worker.jsFollow-up Questions
- What happens if you use `docker run --entrypoint`?
- Why does shell form break proper SIGTERM signal forwarding?
- How would you write an ENTRYPOINT wrapper script that still respects CMD?
- What happens if a Dockerfile defines CMD but no ENTRYPOINT?
MCQ Practice
1. What does `docker run myapp arg1` do when both ENTRYPOINT and CMD are set?
Arguments after the image name replace CMD; ENTRYPOINT remains the fixed executable that receives those arguments.
2. Why is exec form (`CMD ["npm", "start"]`) preferred over shell form (`CMD npm start`)?
Shell form adds an extra shell process between Docker and the app, so signals like SIGTERM may not reach the actual application process.
3. What happens if a Dockerfile has CMD but no ENTRYPOINT?
With no ENTRYPOINT, CMD is treated as the entire default command, and any arguments given to `docker run` replace it completely.
Flash Cards
What is ENTRYPOINT? — The fixed executable a container always runs, not overridable by run-time arguments alone.
What is CMD? — Default arguments to ENTRYPOINT (or the full default command if no ENTRYPOINT exists), overridable at `docker run`.
Why prefer exec form? — It avoids an extra shell process so signals like SIGTERM reach the app correctly.
What does `docker run image arg` override? — Only CMD — ENTRYPOINT stays fixed and receives arg as an argument.