Docker interview questions: Dockerfiles, images, and layers

RUN executes during docker build, and each RUN instruction produces a new image layer containing the filesystem changes it made. CMD does not execute during the build; it records the default command that runs when a container is started from the image, and that command can be overridden at docker run. Because both descriptions match Docker's behavior, the statement is true.

The FROM instruction is the first required instruction in a Dockerfile and defines the base image that all subsequent layers build upon. In the example FROM ubuntu:22.04, the image ubuntu:22.04 is pulled as the starting point for the build.

The FROM instruction sets the base image and starts a build stage; it is the required starting point for a Dockerfile, apart from ARG directives that may precede it. RUN executes build-time commands, COPY transfers local files, and CMD specifies the default container runtime command, so none of those initializes a stage or sets the base image.

Both COPY and ADD can move local files from the build context into an image, but Docker best practices recommend COPY because it does only that one thing. ADD additionally auto-extracts local tar archives and can fetch remote URLs, so COPY's narrower, more transparent behavior makes it the preferred instruction for copying build-context files. RUN executes build-time commands and EXPOSE only declares a runtime port, so neither applies here.

The FROM instruction is the first required instruction in every Dockerfile. It names the base image (for example, FROM python:3.12) that subsequent layers are applied to. Without it, the Dockerfile has no starting filesystem to build on. Comments, parser directives, and ARG instructions may appear before it, which is why the prompt excludes them.

The RUN instruction is a cache miss because BuildKit includes the command string in the cache key; adding bash changes that string. Without --link, a COPY instruction's cache key includes the parent layer ID, so when the RUN misses (producing a different layer), the COPY and everything after it also miss — even though app.tar.gz is byte-identical. COPY --link changes this by creating the layer on top of the base image rather than the immediately preceding layer, so its cache key is based on the base image and the file checksum alone. This lets the COPY --link hit cache despite the changed RUN, and because that layer digest is unchanged, the subsequent RUN tar also hits cache.

A cache mount is a persistent, writable directory managed by BuildKit's cache storage. Its contents are not captured in the layer's filesystem diff, so they never end up in the image. The cache key for the RUN instruction is built from the command string, the parent layer, and the mount specification (type, target, id, sharing), not from the files inside the mount. The mount only speeds up re-execution after a cache miss, for example by letting pip reuse downloaded packages. The option claiming the contents are saved into the layer is wrong because the mount is excluded from the layer diff, and the options claiming the contents are hashed into the cache key or copied into the image at the target path are both wrong for the same reasons.

The FROM instruction declares the base image, and every Dockerfile needs one to begin the build. Each later instruction adds a layer on top of that base. RUN executes a command during the build, COPY copies files from the build context into the image, and ENTRYPOINT sets the executable that runs when a container starts. Only ARG instructions may appear before FROM.

Docker's Dockerfile best practices recommend COPY for plain file copies because its behaviour is transparent: it only copies local files/directories from the build context. ADD does extra implicit work — it can download remote URLs and will auto-extract local tar archives — which makes builds less predictable and can mask surprises. Both preserve permissions and both handle single files. Reaching for ADD 'just in case' is the misconception; use ADD only when you specifically want local-archive auto-extraction.

Docker caches each instruction as a layer and reuses it when its inputs are unchanged. Copying only package.json before running npm install means the install layer's input stays the same when source files change, so it is served from cache, and only the final copy of the source is re-executed. Copying all source before the install, or copying the source before running the install even when package.json is copied first, changes the input of the install layer on every source edit, so the install reruns each time.

The WORKDIR instruction establishes the working directory for subsequent instructions in the Dockerfile. Unlike using RUN cd /app && ..., where the cd only applies within that one shell, WORKDIR persists across all following instructions. If the target directory does not exist, Docker creates it automatically, so an explicit mkdir is unnecessary. This makes WORKDIR the canonical way to set the filesystem context for a build stage.

Copying package.json and package-lock.json first, then running npm ci, makes the install deterministic because npm ci installs strictly from the lock file and fails if it is out of sync. Docker invalidates that install layer only when the manifests change, so it stays cached through source-only edits. Copying the full source with COPY . . last means a source change busts only the final layer. Placing the source copy before npm ci would invalidate the install layer on every source change, so it must come after.

The .dockerignore file sits at the root of the build context and tells the Docker client which paths to exclude when it sends the context to the daemon during docker build. Without it, every file under the context directory, including large node_modules folders, .git history, secrets and IDE configs, is packaged and transferred, which slows the build and can leak sensitive data. Excluding these paths keeps the context small, speeds up the transfer, and stops unrelated file changes from invalidating the layer cache for the COPY instruction.

ADD is the only Dockerfile instruction in this pair that unpacks a local tar archive during the build: when the source is a recognized compressed or uncompressed tar file in the build context, Docker extracts it into the destination directory. COPY always copies the file as-is, so it would leave the .tar.gz intact. Because this implicit extraction can be surprising, Docker's best-practice guidance recommends using COPY for plain file copies and reserving ADD for cases where auto-extraction is actually needed.

Docker builds each instruction as a layer and caches it keyed by the instruction text and the contents of any files copied in. In Option B, package.json and package-lock.json are copied first, so the npm ci layer is cached as long as those two files are unchanged. Only after that are the application source files copied. When source code changes, the cache is invalidated only from the second COPY . /app/ onward — npm ci stays cached and is not re-run. In Option A, COPY . /app includes source files, so any source change invalidates the cache for that layer and every subsequent layer including npm ci. In Option C, COPY . /app is first, so the same invalidation occurs before npm ci. In Option D, npm ci runs before package.json is even copied into the image, so it would fail or install nothing useful.

WORKDIR does two things: it ensures the target directory exists, creating any missing parent directories along the path (equivalent to mkdir -p), and it sets that path as the working directory for subsequent instructions. Since none of /app, /app/build, or /app/build/output exists in the base image, WORKDIR creates the whole chain without needing a RUN mkdir. The RUN pwd step therefore runs inside /app/build/output and prints /app/build/output with no error.

Each Dockerfile instruction produces a layer, and Docker caches each layer keyed on the instruction and its inputs. Copying rarely-changing files such as dependency manifests first keeps those layers cached, so dependency installation is not repeated when only application source code changes; source code is therefore copied after the manifests. When an earlier instruction's inputs change, the cache is invalidated from that point forward, so all subsequent layers must be rebuilt.

Docker builds layers top to bottom and reuses a layer only if its instruction and its inputs are unchanged, and it stops reusing the cache from the first changed layer onward. FROM and WORKDIR are unchanged, so they hit. COPY . . copies the whole build context, and its cache key is a checksum of those files, so the edited src/server.js makes it miss. That miss invalidates the following RUN npm ci and CMD instructions, so npm ci re-runs even though the lock file did not change. Copying package*.json and running npm ci before copying the rest of the source makes the install layer depend only on the manifests, so source-only edits reuse it.

An ARG declared before the first FROM is a global build argument: it is available for substitution in every FROM instruction across all stages, which is why both FROM alpine:${VERSION} lines correctly resolve to alpine:3.18. However, a global ARG is not automatically available inside any build stage for use in instructions like RUN, COPY, or ENV — it must be re-declared with a bare ARG VERSION inside that stage. The first stage does this (ARG VERSION on line 3), so VERSION is usable there. The second stage does not re-declare it, so when Docker performs variable substitution on the RUN echo "Running on Alpine ${VERSION}" line, VERSION is undefined for that stage and is replaced with an empty string. The resulting file content is therefore Running on Alpine (with a trailing space and no version number). The build does not fail — undefined ARG substitutions silently resolve to empty strings, not errors.

BuildKit's RUN --mount=type=cache creates a persistent cache directory on the builder that survives across builds, speeding up subsequent builds by reusing downloaded dependencies or compiled artifacts. Critically, a cache mount is a build-time-only construct: its contents are NOT committed into any image layer. This means the final image stays small (no leftover .m2 cache) and runtime containers do not see the cached files. The claim that the cache mount contents are committed into the resulting image layer is wrong because cache mount contents are never written to a layer. The claim that the Dockerfile must also declare a matching VOLUME /root/.m2 instruction for the cache mount to function correctly is wrong because no VOLUME declaration is needed — --mount=type=cache is self-contained. The claim that the cache mount is discarded immediately after each build completes is wrong because the cache explicitly persists across builds, which is its entire purpose.

Each RUN instruction runs in its own new shell process, so the export MESSAGE=world in the second RUN only changes that shell's environment and does not persist to later RUN instructions. ENV values are stored in the image configuration and are present for every subsequent RUN, so the third RUN's echo $MESSAGE expands to hello, which is written to /tmp/out.txt. The CMD then runs cat /tmp/out.txt at container start, printing hello.

The Dockerfile is a multi-stage build. The first stage (labeled builder) starts from golang:1.21 and compiles the Go program with CGO_ENABLED=0 and GOOS=linux, which yields a statically-linked binary with no dependence on external C libraries. The final stage uses FROM scratch, Docker's empty base image that contains no files, operating system, shell, or package manager. COPY --from=builder copies only the compiled /server binary into that stage, and ENTRYPOINT makes /server the process that runs at container start. The result is a very small image whose only content is one static binary, which also leaves a minimal attack surface.

An ARG declared before the first FROM is a global build argument. It is available for interpolation in FROM lines (so the base image correctly resolves to python:3.12-slim), but it is not available inside any build stage unless it is redeclared with an ARG instruction after the FROM. Because ARG BASE_IMAGE is not redeclared within the stage, the shell variable $BASE_IMAGE in the RUN command is unset and expands to an empty string. The build therefore succeeds (there is no error — an unset shell variable simply expands to nothing), and /tmp/info.txt contains Image: with a trailing empty value.

BuildKit cache mounts are persistent cache storage managed by BuildKit that is overlaid on the target path only for the duration of that single RUN instruction; their contents are not written into any image layer, so they never appear in docker history. Filesystem changes made by the RUN outside the mount path (here, the binary at /app/bin/myapp) are captured in the builder stage's layer as usual, which is why COPY --from=builder can retrieve it. The option claiming the cache is a committed layer is wrong for the reason above. The claim that the cache is wiped every build is wrong because the mount persists across builds (it may be pruned by cache management, but that is not a per-build wipe). The claim that it is a named volume is wrong because cache mounts are internal BuildKit cache entries, not volumes listed by docker volume ls.