Deployment & Infra
Image layers: free-recall review
Retrieval beats re-reading. For each prompt, say or write a full answer from memory before you open the model answer — the effort of recall is what makes the mechanism stick when you are reviewing a real Dockerfile.
Reconstruct the unit’s core mechanisms — the cache as a content-keyed prefix, the order rule, multi-stage slimming, base-image tradeoffs, and the immutable-layer secret trap — without looking back at the lesson.
- 01What exactly is a Docker image layer, and what two inputs does the build cache key each layer on?
- 02State the cardinal ordering rule and explain why putting COPY . . before RUN npm ci wrecks build times.
- 03Why does 'RUN apt-get update' followed by a separate 'RUN apt-get install' serve stale packages, and how do you fix it?
- 04How does a multi-stage build shrink an image, and roughly what size deltas should you expect?
- 05Compare distroless and alpine as final-stage bases — when do you reach for each?
- 06Why does deleting a secret in a later layer not remove it, and what should you do instead?
If you could reconstruct each answer from memory, you hold the unit’s spine: a layer is a content-keyed diff, the cache is a strict prefix, RUN is keyed on text not effect, ordering least- to most-changing keeps the expensive install cached, multi-stage builds compile fat and ship slim, distroless trades the shell for a minimal attack surface, and a secret added then rm’d lives forever in an earlier layer — so it must never become a layer at all.