How do Docker image layers and the build cache work?
Learn how Docker image layers stack and how the build cache reuses unchanged steps, plus how to order Dockerfile instructions for fast rebuilds.
Expected Interview Answer
A Docker image is a stack of read-only layers, one per build instruction, and the build cache reuses an existing layer whenever its instruction and inputs are unchanged instead of rebuilding it.
Each Dockerfile instruction (FROM, RUN, COPY, etc.) produces a layer that records the filesystem changes it made. During a build, Docker checks whether a layer with the same parent and the same instruction/input already exists; if so it reuses the cached layer and moves on. As soon as one layer misses, every layer after it is rebuilt, because each layer depends on the state of the one before it. Ordering instructions from least- to most-frequently changing (dependencies before source code) maximizes cache hits and speeds up rebuilds.
- Dramatically faster rebuilds when only later steps change
- Layers are shared across images, saving disk and network
- Only changed layers are pushed or pulled
- Encourages a deterministic, reproducible build order
- Smaller effective transfers on CI and deploys
AI Mentor Explanation
Building an innings is stacked like image layers: the opening partnership, the middle-order consolidation, and the death-overs slog each build on the score already set. If the openers played the exact same way (same instruction, same input), the scoreboard from that phase is reused unchanged; but the moment one partnership collapses differently, every phase after it must be replayed from that new position, just as a cache miss forces all later layers to rebuild.
Step-by-Step Explanation
Step 1
Each instruction makes a layer
FROM, RUN, COPY and similar instructions each create a read-only layer recording that step's filesystem changes.
Step 2
Layers stack in order
Every layer is built on top of the previous one, so a layer's content depends on the exact state produced before it.
Step 3
Cache lookup per layer
During a build, Docker checks for an existing layer with the same parent and the same instruction and inputs, and reuses it on a match.
Step 4
First miss invalidates the rest
Once any layer's inputs change, that layer and every layer after it must be rebuilt from scratch.
Step 5
Order for cache efficiency
Place rarely-changing steps (base image, dependency installs) before frequently-changing ones (COPY of source) to keep more layers cached.
What Interviewer Expects
- Understanding that images are stacks of read-only layers
- How the cache decides to reuse versus rebuild a layer
- Why a cache miss invalidates all subsequent layers
- Instruction ordering to maximize cache hits
- Awareness that layers are shared and only deltas transfer
Common Mistakes
- Thinking the whole image rebuilds on any change rather than only from the first miss
- Copying source code before installing dependencies, busting the cache every build
- Believing layers are writable at runtime
- Assuming ADD/COPY of unchanged files always invalidates cache when it does not
- Ignoring that each RUN creates a separate persisted layer
Best Answer (HR Friendly)
“A Docker image is built up in stacked pieces called layers, one for each step in the recipe. Docker remembers previous builds and reuses any step that hasn't changed, so rebuilds are fast — it only redoes work from the first thing you actually changed onward.”
Code Example
FROM node:20-alpine
WORKDIR /app
# Copy only manifests first so dependency install is cached
# until package.json or the lockfile actually changes
COPY package.json package-lock.json ./
RUN npm ci
# Source code changes often, so copy it after the install layer
COPY . .
RUN npm run build
CMD ["node", "dist/server.js"]Follow-up Questions
- Why does copying source before npm install slow down rebuilds?
- How does a multi-stage build reduce final image size?
- What is the difference between a layer and an image?
- How can you inspect the layers of an image?
- What does '--no-cache' do during docker build?
MCQ Practice
1. When does Docker rebuild a layer instead of using the cache?
Docker reuses a cached layer when its parent, instruction, and inputs are unchanged; otherwise it rebuilds that layer and all after it.
2. If layer 3 of 6 changes, which layers are rebuilt?
A cache miss invalidates the changed layer and every layer that depends on it, so layers 3 through 6 are rebuilt.
3. Why copy package.json before the rest of the source?
Dependencies change rarely, so installing them before copying frequently-changing source keeps that expensive layer cached.
Flash Cards
What is a Docker image layer? — A read-only filesystem diff produced by a single Dockerfile instruction, stacked on top of the previous layer.
When is a cached layer reused? — When its parent, instruction, and inputs are all unchanged from a previous build.
What happens after a cache miss? — The missed layer and every subsequent layer are rebuilt from scratch.
Best practice for instruction order? — Put least-frequently-changing steps (deps) before frequently-changing ones (source) to maximize cache hits.
Continue Learning
Related Interview Questions
How does the Docker layer cache get invalidated and how do you order instructions to exploit it?
medium
What is the difference between the CMD and ENTRYPOINT instructions in a Dockerfile?
medium
What is the difference between COPY and ADD in a Dockerfile?
easy
How do you reduce Docker image size and why does it matter?
medium