How does the Docker layer cache get invalidated and how do you order instructions to exploit it?
Understand how the Docker build cache is invalidated and how to order Dockerfile instructions to keep dependency layers cached for fast rebuilds.
Expected Interview Answer
Docker caches each build instruction as a layer and reuses it only if that instruction and all instructions before it are unchanged; once any layer's inputs change, that layer and every layer after it are rebuilt. You exploit this by ordering instructions from least to most frequently changing, so stable steps like dependency installs stay cached.
For most instructions the cache key is the instruction text itself, but for COPY and ADD it also includes a checksum of the copied files' contents. So copying your whole source tree early busts the cache on every code edit, forcing dependency reinstalls. The fix is to copy only the dependency manifest (package.json, requirements.txt) and install first, then copy the rest of the source — code changes then invalidate only the cheap final layers.
- Dramatically faster rebuilds during development
- Avoids reinstalling dependencies on every code change
- Smaller CI pipeline times and bandwidth
- Predictable, reproducible builds
- Better use of BuildKit and registry cache
AI Mentor Explanation
Think of setting up a match: rolling the pitch and setting the boundary rarely change, but the batting order changes every game. If you redo the whole ground prep whenever a batter swaps, you waste hours. Smart groundskeeping locks the stable ground setup first and only reshuffles the lineup last — Docker caching works the same, keeping stable steps and rebuilding only what actually changed.
Step-by-Step Explanation
Step 1
Understand the cache key
Each layer's cache key is its instruction text, plus a file checksum for COPY/ADD.
Step 2
Know invalidation cascades
When one layer's key changes, that layer and every subsequent layer are rebuilt.
Step 3
Copy manifests first
COPY only package.json / requirements.txt, then run the install so it stays cached.
Step 4
Copy source last
COPY the rest of the code after installing deps so edits invalidate only cheap layers.
Step 5
Pin volatile steps late
Place frequently changing instructions (build, code copy) near the end of the Dockerfile.
Step 6
Verify with rebuilds
Edit a source file and rebuild; confirm dependency layers show 'CACHED' in the output.
What Interviewer Expects
- Cache key includes file content for COPY/ADD
- Invalidation cascades to all later layers
- Ordering least-to-most-frequently-changing
- Copying dependency manifest before source
- Awareness of BuildKit and cache mounts
Common Mistakes
- Copying the entire source before installing dependencies
- Thinking only the changed instruction rebuilds, not the ones after it
- Assuming COPY cache depends only on the path, not file contents
- Putting RUN apt-get update on its own line and hitting stale caches
- Ignoring .dockerignore, letting irrelevant files bust the COPY cache
Best Answer (HR Friendly)
“Docker remembers each build step, and reuses that memory as long as the step and everything before it hasn't changed. To keep builds fast, you put the parts that rarely change — like installing libraries — near the top, and the parts that change often, like your code, near the bottom.”
Code Example
FROM node:20-alpine
WORKDIR /app
# 1) Copy ONLY the manifest first — changes rarely
COPY package.json package-lock.json ./
# 2) Install deps — stays CACHED until the manifest changes
RUN npm ci --omit=dev
# 3) Copy the rest of the source LAST — code edits only bust this layer
COPY . .
RUN npm run build
CMD ["node", "dist/server.js"]FROM node:20-alpine
WORKDIR /app
# BAD: any source edit changes the checksum here...
COPY . .
# ...forcing a full reinstall on every single code change
RUN npm ci --omit=dev
RUN npm run build
CMD ["node", "dist/server.js"]Follow-up Questions
- How does the cache key differ between RUN and COPY instructions?
- What role does .dockerignore play in cache stability?
- How do BuildKit cache mounts (--mount=type=cache) help?
- Why can RUN apt-get update && apt-get install be a caching trap?
- How do multi-stage builds interact with layer caching?
MCQ Practice
1. When a middle layer's cache is invalidated, what happens?
Cache invalidation cascades: the changed layer plus every instruction after it must be rebuilt.
2. What is included in the cache key for a COPY instruction?
COPY/ADD cache keys include a checksum of the copied files, so content changes bust the cache.
3. Why copy package.json before the rest of the source?
Isolating the manifest keeps the install layer cached until dependencies actually change.
Flash Cards
What busts a COPY layer's cache? — A change to the checksum of the copied files' contents (not just the path).
Does invalidation stop at one layer? — No — it cascades to that layer and every instruction after it.
Ordering rule for cache efficiency? — Least-frequently-changing steps first, most-frequently-changing (source copy, build) last.
Why copy the dependency manifest first? — So the expensive install layer stays cached until dependencies change, not on every code edit.