Deployment & Infra
Image layers: multiple-choice review
Crux Multiple-choice synthesis across the image-layers unit — cache prefix behaviour, instruction order, multi-stage builds, base-image tradeoffs, .dockerignore, and the secret that lives forever in history.
Your altitude — climbing toward senior
ZeroJuniorMiddleSenior
You are at senior altitude — in orbitSix questions that cut across the whole unit. Each one mirrors a decision you make while writing or reviewing a real Dockerfile — not a definition to recite, but a cache-and-image tradeoff to reason through.
Goal
Confirm you can connect the cache-prefix model, instruction ordering, multi-stage builds, base-image choice, build-context hygiene, and the immutable-layer secret trap — the synthesis the lesson built toward.
Quiz
Completed
A teammate moves RUN npm ci to sit just before the final CMD, reasoning that 'install is expensive so it should run last.' What actually happens to cache behaviour on a routine source edit?
Heads-up The cache is a strict prefix match — the first changed layer rebuilds itself and everything after. Position in the file is irrelevant; what matters is whether a layer sits before or after the layers that change often. Install must precede COPY . .
Heads-up RUN npm ci is cached on its inputs and on every prior layer. If an upstream COPY . . layer invalidates, npm ci is downstream of the miss and re-runs even though its own command text is unchanged.
Heads-up Reordering instructions does not change image size — the same layers exist. It changes only which layers stay cached. Here the reorder hurts cache, and size is unaffected either way.
Quiz
Completed
A Dockerfile has these two lines as separate instructions. Builds keep installing months-old package versions even after the upstream repo updated. Why? RUN apt-get update RUN apt-get install -y curl
Heads-up The caching is working exactly as designed — too well. Docker reuses the update layer because its instruction string never changed. The issue is splitting update and install into two cache keys, not non-determinism.
Heads-up The mirror is not the cause; the cached 'apt-get update' layer is. Even with a fresh mirror, a cache-hit update layer still serves a stale index. Combine update and install in one RUN.
Heads-up --no-cache discards all caching and defeats the point of layer caching. The targeted fix is to merge update and install so the index refresh and the install invalidate as a unit.
Quiz
Completed
A single-stage Go build ships a ~180 MB image. A teammate proposes appending 'RUN apt-get remove -y build-essential && rm -rf /usr/local/go' at the end to slim it. Will the image shrink?
Heads-up Layers are immutable, append-only diffs. A delete in a later layer hides files in the merged view but never edits earlier layers, so the bytes — and the image size — persist. Only a fresh final stage actually drops them.
Heads-up Same-RUN cleanup helps only for files created and removed inside that one instruction. Here the toolchain came from the base image and earlier layers, so a removal RUN cannot shrink it. Multi-stage is the correct tool.
Heads-up A larger base makes the image bigger, not smaller. The fix is the opposite direction: build in a fat stage, then COPY the artifact into a minimal final stage like scratch or distroless/static.
Quiz
Completed
You need the smallest, most hardened production image for a self-contained compiled service, and CVE-scan noise must be near zero. Which final-stage base is the senior default, and what cost do you accept?
Heads-up Alpine is small and convenient, but it ships a shell and package manager (more attack surface than distroless) and its musl libc can break native modules and cause DNS/perf surprises. Good when you genuinely need a shell, not the most-hardened pick.
Heads-up That is the exact anti-pattern multi-stage builds exist to fix — you ship compilers, dev deps, and apt caches into production: hundreds of MB of bloat and attack surface that never serve a request.
Heads-up Removing tools in a later layer does not shrink the image (the bytes stay in earlier layers) and keeps a large glibc base with a shell and package manager. A fresh distroless or scratch final stage is both smaller and more hardened.
Quiz
Completed
During CI a build needs a private-registry token to fetch dependencies. An engineer writes COPY token.txt /tmp/token, uses it in a RUN, then RUN rm /tmp/token in the next instruction. The final image is published. What is the exposure?
Heads-up Layers are stacked immutable diffs. The rm adds a new diff marking the file deleted in the merged tree but cannot erase the earlier layer, which still physically holds the token. It is recoverable regardless.
Heads-up A private registry controls who can pull, not whether the secret is in the layers. Anyone who can pull (or who has the local image) can extract it. The secret should never have become a layer.
Heads-up The ephemeral-at-runtime semantics of /tmp are irrelevant to the build: COPY wrote the file into a persisted image layer at build time. The path does not exempt it from layer history.
Quiz
Completed
docker build is slow to even start — several seconds elapse before the first instruction runs — and COPY . . occasionally pulls a developer's local .env into the image. The repo has no .dockerignore. What single change addresses both?
Heads-up ADD adds URL/auto-extract behaviour, not a smaller context. The slow start is the context tar being sent to the daemon, and ADD . . would still copy .env. A .dockerignore is the fix for both symptoms.
Heads-up Base-image size affects pull and final-image size, not the pre-build context upload or what COPY . . includes. The slow start and the leaked .env both come from an unfiltered build context.
Heads-up --no-cache forces full rebuilds and re-sends the same bloated context — it makes the slow start worse and does nothing about .env leaking. Filtering the context with .dockerignore is the correct lever.
Recap
The through-line is one model: an image is immutable stacked layers, the cache is a strict prefix, and RUN is keyed on command text rather than effect. Order least- to most-changing so the expensive install stays a cache hit; merge update-and-install so they invalidate together; multi-stage so you compile fat and ship slim instead of deleting bytes that never leave history; pick distroless when you want minimal attack surface and accept losing the shell; and keep the build context lean with .dockerignore. The hardest trap — a secret added then rm’d — falls out of the same immutability rule: you cannot delete it back out, so it must never become a layer.