How do container image layers work, and why do they matter for build speed?
Understand how Docker image layers are built, hashed, cached, and merged with OverlayFS — and how ordering speeds up builds.
Expected Interview Answer
A container image is a stack of read-only filesystem layers, each produced by one build instruction and identified by a content hash, that a union filesystem overlays into a single merged view — layers are cached so unchanged instructions are reused across builds instead of rebuilt from scratch.
Each Dockerfile instruction that modifies the filesystem (RUN, COPY, ADD) creates a new layer, while metadata-only instructions like ENV or CMD update image config without adding filesystem content. Layers are content-addressable: Docker hashes the layer’s contents and the preceding build context, and if that hash matches something already cached locally or in the registry, Docker reuses it instead of re-executing the instruction, which is why reordering a Dockerfile so rarely-changing steps come first dramatically speeds up rebuilds. At runtime, an overlay filesystem (typically OverlayFS) stacks all the read-only image layers and adds one thin writable layer on top for the container, presenting a single merged view to the process even though the files physically live in separate layers. Layers are also shared across images and containers on the same host — if two images both start `FROM node:20-alpine`, that base layer is stored and downloaded only once, which is why a well-layered base image saves both disk space and registry pull time across many images.
- Explains why Dockerfile instruction order affects build speed dramatically
- Shows why shared base images save disk space and registry bandwidth
- Clarifies the distinction between the immutable image layers and the writable container layer
- Helps diagnose bloated images caused by layers that add and then delete files
AI Mentor Explanation
Image layers are like a groundskeeper preparing a pitch in stacked stages — first rolling the base soil, then adding the grass layer, then marking the creases, each stage recorded and reusable. If only the crease markings need to change before the next match, the groundstaff reuse the already-rolled soil and grown grass layers instead of redoing the whole pitch from bare earth. Two different grounds using the identical base-soil preparation method can literally share that same prep recipe without repeating the work. The final surface a player bats on is the merged view of every stacked stage, even though each stage was prepared separately.
Step-by-Step Explanation
Step 1
Instruction executes in build context
Each RUN, COPY, or ADD instruction runs against the current merged filesystem view.
Step 2
Filesystem diff becomes a layer
Docker captures the changes that instruction made as a new, immutable, content-hashed layer.
Step 3
Layer is cached by hash
On the next build, if the instruction and its inputs hash identically, Docker reuses the cached layer instead of re-executing.
Step 4
Union filesystem merges at runtime
OverlayFS stacks all image layers plus a writable container layer into one merged view for the running process.
What Interviewer Expects
- Understanding that each filesystem-modifying instruction creates a distinct, hashed layer
- Explaining why instruction order affects cache hit rate and rebuild speed
- Knowledge that layers are shared across images on the same host via content addressing
- Awareness that a union/overlay filesystem merges layers at container runtime
Common Mistakes
- Believing every Dockerfile line creates a layer, including non-filesystem instructions like ENV
- Not knowing that deleting a file in a later layer does not shrink the image (the earlier layer still stores it)
- Putting frequently changing COPY instructions before stable dependency installs, breaking cache
- Confusing image layers (immutable, shared) with the container’s writable layer (ephemeral, per-container)
Best Answer (HR Friendly)
“Think of a Docker image like a layer cake, where each step in the build recipe bakes one layer and Docker remembers exactly what each layer looked like. If we only change the top layer — say, our application code — Docker reuses every layer underneath instead of baking the whole cake again, which is why ordering our Dockerfile so rarely-changing steps come first makes our builds dramatically faster.”
Code Example
# See every layer and the command that produced it
docker history myapp:1.0
# Bad ordering: source changes bust the dependency-install cache
# COPY . .
# RUN npm ci
# Good ordering: dependency layer stays cached across code changes
COPY package*.json ./
RUN npm ci --production
COPY . .
# Inspect layer sizes to spot bloat
docker image inspect myapp:1.0 --format "{{.RootFS.Layers}}"Follow-up Questions
- Why does deleting a file in a later RUN instruction not reduce image size?
- How does a multi-stage build help reduce the number of layers shipped?
- What is the difference between an image layer and a container’s writable layer?
- How would you diagnose which layer is bloating an image the most?
MCQ Practice
1. What determines whether Docker reuses a cached layer during a build?
Docker hashes each instruction and its build context; a matching hash means the cached layer can be reused instead of re-executed.
2. Why does deleting a file in a later layer not shrink the final image?
Layers are immutable and stacked; a later layer only marks a file as deleted in the merged view, but the earlier layer's data remains on disk.
3. What merges the read-only image layers with the writable container layer at runtime?
A union filesystem like OverlayFS stacks the immutable layers and the container's writable layer into a single merged view.
Flash Cards
What creates a new image layer? — Each filesystem-modifying Dockerfile instruction like RUN, COPY, or ADD.
How does Docker decide to reuse a layer? — By matching a content hash of the instruction and its inputs against a cached layer.
Why does deleting a file in a later layer not shrink the image? — The file still exists in the earlier immutable layer; only a deletion marker is added.
What merges layers at runtime? — A union filesystem (e.g. OverlayFS) stacking read-only layers plus one writable layer.