Many base images default to root. What should a professional Dockerfile for a parks reservation API do before the process starts?
Select an answer to reveal the explanation.
Short Explanation
Running as root inside the container is like leaving the master key in the ignition. Creating a non-root USER and switching to it shrinks the blast radius if the process is compromised.
Full Explanation
Many base images default to root so package installs during build succeed easily, but the long-running parks reservation process should not retain container-root privileges after the image is ready. Create a dedicated non-root user in the Dockerfile and switch to it with the USER instruction before the application starts. That shrinks blast radius if the process is compromised and is baseline image hygiene for a public-facing municipal API—least privilege inside the container, not convenience forever at runtime.
Leaving the default root user so package managers always succeed at run time prioritizes convenience over least privilege and often implies runtime package installs you should not need in production. EXPOSE does not drop privileges after a port is bound; it only documents listening intent. Baking SSH host keys as root so operators can patch the live container fights immutable infrastructure and expands the attack surface instead of shrinking it.
Exam caveat: USER in the image is hygiene, not a full substitute for host hardening, Pod security admission, or dropping Linux capabilities—those remain separate layered controls. Operational check: start the container and confirm the main process UID is non-zero via id or process inspection, and verify the app can still read its mounted configuration files as that non-root user.