How Do Docker Image Layers and Build Caching Work?
Learn how Docker image layers and build caching work, why instruction order matters, and how to speed up builds — with a DevOps interview answer.
Expected Interview Answer
Each instruction in a Dockerfile produces an immutable, content-addressed image layer, and Docker’s build cache reuses a previously built layer whenever the instruction and its inputs are unchanged, which is why instruction order directly controls build speed.
Docker builds an image as a stack of read-only layers, one per instruction (FROM, RUN, COPY, and similar), and each layer is identified by a hash of its instruction plus the state of the layer beneath it. When you rebuild, Docker walks the Dockerfile top to bottom and reuses a cached layer as long as the instruction text and its build context have not changed; the moment one layer misses the cache, every layer after it must also be rebuilt, even if their own instructions did not change. This is why Dockerfiles put rarely changing steps, like installing dependencies from a lockfile, before frequently changing steps, like copying application source code. Multi-stage builds and BuildKit’s inline cache mounts extend this further by letting package manager caches persist across builds without bloating the final image.
- Cuts rebuild time from minutes to seconds for small code changes
- Reduces registry push/pull bandwidth via shared layer reuse
- Encourages a Dockerfile structure that documents build stability
- Enables remote/CI cache reuse across pipeline runs
AI Mentor Explanation
Docker layer caching is like a groundstaff crew preparing a pitch in fixed stages: rolling the surface, watering it, then marking the creases. If only the crease-marking step changes before a match, the crew reuses the already-rolled and already-watered surface instead of redoing everything from scratch. But if the rolling step itself changes, watering and marking must happen again on top of it, because each stage depends on the one before. A ground that never changes its rolling routine gets match-ready far faster every single time.
Step-by-Step Explanation
Step 1
Parse the Dockerfile
Docker reads instructions top to bottom, one layer planned per instruction.
Step 2
Check the cache
For each instruction, Docker hashes it plus the parent layer state and looks for a matching cached layer.
Step 3
Reuse or invalidate
A cache hit reuses the layer instantly; a miss rebuilds that layer and invalidates every layer after it.
Step 4
Order for stability
Rarely changing instructions (dependency installs) are placed before frequently changing ones (source copy).
What Interviewer Expects
- Understanding that layers are ordered and each depends on the one before it
- Awareness that one cache miss invalidates all subsequent layers
- Knowledge of ordering Dockerfile instructions for maximum cache reuse
- Familiarity with BuildKit cache mounts for package manager caches
Common Mistakes
- Copying full source code before installing dependencies
- Assuming cache invalidation only affects the changed instruction
- Not pinning dependency lockfiles, causing spurious cache misses
- Forgetting that build context changes (like a modified file) invalidate COPY layers
Best Answer (HR Friendly)
“Docker builds an image as a stack of stages, and it remembers each stage so it does not redo work that has not changed. If we only touch our application code, Docker skips reinstalling all our dependencies and reuses that cached step, which is why we always install dependencies before copying source code — it keeps our builds fast.”
Code Example
FROM node:20-alpine
WORKDIR /app
# Dependency files change rarely -> cached across most builds
COPY package*.json ./
RUN npm ci --production
# Source code changes often -> placed last so only this layer rebuilds
COPY . .
CMD ["node", "server.js"]Follow-up Questions
- What invalidates a Docker build cache layer?
- How does BuildKit improve on the classic layer cache?
- Why should COPY of source code usually come after dependency installation?
- How can you share a build cache across CI runners?
MCQ Practice
1. What happens when a Docker build instruction misses the cache?
A cache miss at one layer invalidates that layer and everything built after it, since each layer depends on the one before.
2. Why place dependency installation before copying application source code?
Placing stable steps earlier keeps them cached even when only frequently changing source code is modified.
3. What uniquely identifies a cached Docker layer?
Docker hashes each instruction together with its parent layer to decide whether a cached layer can be reused.
Flash Cards
What produces a Docker image layer? — Each Dockerfile instruction produces one immutable layer.
What happens on a cache miss? — That layer and all subsequent layers rebuild.
Best ordering rule? — Put rarely changing instructions before frequently changing ones.
What extends caching further in modern builds? — BuildKit cache mounts, which persist package manager caches across builds.