Dockerfile CMD versus ENTRYPOINT

WHAT THIS TESTS It checks whether you understand the interplay that controls a container's main process and how run-time arguments are resolved against the two instructions.

A GOOD ANSWER COVERS ENTRYPOINT declares the executable that the container always runs. CMD provides default arguments to that executable, or, when there is no ENTRYPOINT, the default command itself. The resolution rule is the crux: arguments supplied on docker run override CMD completely, but they are appended to ENTRYPOINT rather than replacing it. Both have exec form (JSON array) and shell form; exec form is preferred because it runs the binary as PID 1 directly so it receives signals like SIGTERM, whereas shell form wraps it in /bin/sh -c and can swallow signals. Used together, ENTRYPOINT fixes the program and CMD gives overridable defaults.

COMMON WRONG ANSWERS Claiming docker run arguments replace ENTRYPOINT. Treating CMD and ENTRYPOINT as interchangeable. Using shell form and then wondering why the container ignores SIGTERM on shutdown.

LIKELY FOLLOW-UPS Why does exec form matter for signal handling and graceful shutdown? How do you override ENTRYPOINT at run time? What happens if you set neither?

ONE CONCRETE EXAMPLE A Dockerfile sets ENTRYPOINT ["ping"] and CMD ["localhost"]. Running the container with no args pings localhost; running it with example.com pings example.com because the argument overrides CMD but appends to the fixed ping ENTRYPOINT. This makes the image behave like the ping command with a sensible default target.