DevOps Engineer interview question
How do you reduce a Docker image size?
Use a minimal trusted base, multi-stage builds, a strict .dockerignore, deterministic dependency layers, production-only packages, and no package caches or build tools in the final stage; inspect layers and scan the result.
Direct answer
What a strong answer covers
How it works
Image size is decided by what ends up in the final layers. A multi-stage build compiles or installs in one stage and copies only the runtime artefacts into a minimal base such as distroless or alpine, leaving compilers, package caches, and test dependencies behind. A .dockerignore keeps the build context and the image free of source history, local configs, and node_modules from the host. Dependency layers are ordered so they cache across builds, production-only installs skip dev packages, and package manager caches are removed in the same RUN step that created them. Tools like dive show which layer carries the weight, and a scanner confirms the smaller surface has fewer vulnerabilities.
Example
A Node service image shrank from 1.4 GB to 180 MB: the build stage ran npm ci and the TypeScript compiler, the final stage started from node:20-slim, copied dist and a production-only node_modules, and ran as a non-root user. A .dockerignore excluding .git and local env files also removed a leaked credentials file that had been baked into every previous image.
Common mistakes
- Installing build tools in the final stage and shipping a compiler to production.
- Deleting cache files in a later layer, which does not remove them from the earlier one.
- Using latest as the base tag so the image changes without a code change.
A useful answer structure
Answer from your own work.
Do not memorise a script: use only examples you can explain honestly in follow-up questions.
Open the desktop workspace and rehearse a clear answer in your own words.