A parks department needs a slim image for a Python tool that calls the Webex API. The Dockerfile already has a base image and a COPY of the app. Which single instruction best completes the default startup without authoring an entire recipe from scratch?
Select an answer to reveal the explanation.
Short Explanation
You do not rewrite the whole cookbook for one missing step—you add the instruction that starts dinner. CMD or ENTRYPOINT tells the container what process to run when nothing else is specified.
Full Explanation
A Dockerfile must declare how the container starts: CMD or ENTRYPOINT should launch the application’s documented start command so docker run and orchestrators get a default process without extra overrides. That single instruction turns the image into a runnable unit for the civic service rather than a filesystem snapshot waiting for tribal knowledge. Pasting an entire multi-stage production Dockerfile with every hardening flag is unnecessary when the gap is a missing start command—scope the change to what actually fails at runtime. Mounting VOLUME /var/run/docker.sock so the container can drive the host daemon is a privilege and coupling anti-pattern; it does not define the app’s own process and expands the attack surface. Switching to FROM scratch and omitting CMD because “Python images invent one” is false for scratch and unreliable even for curated bases—explicit process definition remains the contract. Exam caveat: ENTRYPOINT and CMD compose differently (exec form vs shell form, and how arguments append); know which form your platform overrides on deploy. Operational check: build the image, run it with no command override, and confirm the documented municipal API process is what docker top or the orchestrator reports as the main container process.