Docker layers and build cache efficiency
layer/union FS and caching.
each instruction makes a content-addressed read-only layer stacked by a union FS; shared layers are pushed/pulled once, and ordering the Dockerfile so volatile steps come last maximizes cache reuse.
What's really being asked
Whether you understand image layers as content-addressed, stacked units and can exploit that for fast transfers and fast builds.
The full answer
A Docker image is a stack of read-only layers. Most instructions in a Dockerfile, such as RUN, COPY and ADD, create a new layer capturing the filesystem changes that step made; the layers are combined at runtime by a union or overlay filesystem that presents one merged view, with a thin writable layer added on top for the running container. Each layer is content-addressed by a digest of its contents. This drives transfer efficiency: when you push or pull, the registry and client exchange only layers whose digests are not already present, so shared base layers are transferred once and reused across images and across pulls, and unchanged layers are skipped entirely. The same content addressing powers the build cache: Docker reuses a cached layer if the instruction and its inputs are unchanged, but the moment one layer changes, every layer after it is invalidated and rebuilt. The practical lever is Dockerfile ordering: put stable steps, like installing OS packages and language dependencies, early, and volatile steps, like copying your application source, late, so a code change only rebuilds the cheap tail. Copying a lockfile and installing dependencies before copying the rest of the source is the classic pattern.
The mistakes people make
Treating an image as one monolithic blob with no reuse. Thinking reordering does not matter, or copying all source first then installing dependencies, which busts the cache on every code change. Forgetting that changing an early layer invalidates all later ones. Confusing layers with multi-stage builds, though both help.
What usually comes next
How do multi-stage builds shrink final images? How does BuildKit improve caching and parallelism, including remote cache? Why combine commands to reduce layers, and the tradeoff with cache granularity? How does a .dockerignore protect the cache?
A concrete example
A Node Dockerfile that copies the whole repo then runs npm install rebuilds dependencies on every commit. Reorder it to copy package.json and lockfile, run npm install, then copy the rest. Now a source-only change reuses the cached dependency layer, and the registry pull on deploy skips the unchanged base and dependency layers, cutting both build and transfer time dramatically.
Interview question
Your CI rebuilds all dependencies on every commit even though only source changed. Which Dockerfile change best fixes this?
- a.Combine every instruction into a single RUN to reduce layers
- b.Copy the dependency manifest and install dependencies before copying the application sourceCorrect
- c.Copy all source first, then install dependencies last
- d.Disable the build cache so layers are always fresh
Why? this is the answer
Because any changed layer invalidates all later layers, installing dependencies before copying volatile source lets the dependency layer stay cached across code changes. Copying source first busts the cache every commit; merging instructions or disabling cache makes it worse.
Just read this? Test yourself on what you have been reading.
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on docker — each one lists the topics its interview covers.
See open roles