Lesson 15 of 30

Dockerfile Best Practices & Image Hardening

Q: Walk me through what you'd change about a Dockerfile before it goes to production.

A strong answer covers: Names running as a dedicated non-root USER instead of the default root, and notes that a multi-stage build's final stage still needs its own explicit USER instruction.; Names .dockerignore as a build-context control distinct from .gitignore — files correctly excluded from git can still leak into the build context and get baked in via a broad COPY.; Explains the build-time-secret layer-history trap: a value written via ARG/ENV early in the file is captured into that layer permanently, and a later RUN deleting the file only hides it, doesn't remove it.; Mentions minimizing installed packages (skipping unnecessary apt/apk packages) as reducing CVE surface, not just image size..

A Dockerfile that builds successfully and a Dockerfile that's safe to run in production are two different bars. Hardening is the checklist that closes the gap.

12 min read

Check your understanding

Every option explains itself — why the right one is right, and why each wrong one is wrong. Miss one and it comes back later on a spaced-repetition schedule.

Question 1 of 3

A Dockerfile never declares a `USER` instruction. What user does the container run as by default?

rootA randomly generated unprivileged user Docker creates automaticallyThe same user account that ran `docker build` on the host machine

Stuck? Ask the AI tutor

Hints without spoilers, and a plain explanation of why a wrong answer was wrong — answered only from this lesson. Free account, no card.

Interview questions on Dockerfile Best Practices & Image Hardening

What interviewers actually ask about this, and what a strong answer has to cover.

Walk me through what you'd change about a Dockerfile before it goes to production.

A strong answer covers

Names running as a dedicated non-root USER instead of the default root, and notes that a multi-stage build's final stage still needs its own explicit USER instruction.
Names .dockerignore as a build-context control distinct from .gitignore — files correctly excluded from git can still leak into the build context and get baked in via a broad COPY.
Explains the build-time-secret layer-history trap: a value written via ARG/ENV early in the file is captured into that layer permanently, and a later RUN deleting the file only hides it, doesn't remove it.
Mentions minimizing installed packages (skipping unnecessary apt/apk packages) as reducing CVE surface, not just image size.

Likely follow-ups

If root-inside-a-container isn't the same risk as root-on-the-host because of namespaces, why does running as non-root still matter?
How would you actually verify whether a secret is present in an image's layer history, rather than just assuming a later RUN cleaned it up?

Practice these with the AI interviewer →

The plain-language idea

A default Dockerfile makes a few choices for you, silently, and every one of them is a small security tradeoff:

The container runs as root unless you say otherwise. If an attacker finds a way to execute code inside your container (a dependency vulnerability, an injection bug — the application layer, not Docker itself, is usually the entry point), running as root means whatever that exploit can do is bounded only by the container's own isolation, not by any additional privilege restriction inside it.
Every installed package is one more thing that can have a CVE. A base image with a full package set (compilers, debug tools, package managers) that your application never actually uses at runtime is pure unnecessary surface.
A value written into an early layer stays there, in the image's history, even after a later layer tries to remove it. Layers are additive — nothing is ever truly deleted, only hidden by a layer on top.
The build context can smuggle in more than you meant to send. Without a .dockerignore, docker build . ships everything in the directory — including .git, node_modules, and any local .env file — to the Docker daemon, and a stray COPY . . can bake any of it into the image.

See it in a real thing: a hardened Dockerfile

FROM node:20-alpine

# Run as a dedicated non-root user, not root
RUN addgroup -S appgroup && adduser -S appuser -G appgroup

WORKDIR /app
COPY package.json pnpm-lock.yaml ./
RUN pnpm install --frozen-lockfile --prod
COPY --chown=appuser:appgroup . .

USER appuser
CMD ["node", "dist/server.js"]

USER appuser on its own line, near the end, switches every subsequent instruction (and the running container itself) to that unprivileged user — COPY --chown ensures the files it needs are actually readable by that user, since files copied before the USER switch are owned by root by default.

What people usually miss

Watch out

Root-inside-container isn't the same risk as root-on-the-host, but it's still a real one. Namespaces mean container root isn't automatically host root — but it's still full privilege within the container's view of the filesystem and process tree, which matters a great deal if a container-escape vulnerability is ever combined with it.
.dockerignore is the build-context equivalent of .gitignore, and both need their own rules. A .gitignore entry doesn't apply to what docker build sends to the daemon — a .env file correctly excluded from git can still leak into a build context and get baked into an image if it isn't separately listed in .dockerignore.
Fewer installed packages is a security decision, not just a size one. --no-install-recommends (Debian-based) or skipping unnecessary apk add packages reduces the set of CVEs that can ever apply to your image, independent of the base image choice itself.
A multi-stage build's final USER still needs to be set explicitly. Using a slim runtime stage doesn't automatically mean non-root — the final stage needs its own USER instruction just like a single-stage build would, since each stage's default user is root unless declared otherwise.

Why this matters in interviews

"Walk me through what you'd change about this Dockerfile before it goes to production" is a real, common exercise, and naming non-root USER, .dockerignore completeness, and the build-time-secret layer-history trap specifically — rather than a vague "make it more secure" — is what signals hands-on hardening experience rather than a general security-awareness answer.