Skip to Content
Docker Advanced: Builds and Containers That Hold Up in Production
Advanced
0 likes
Courses
Docker Advanced: Builds and Containers That Hold Up in Production

Check Yourself: Faster Builds

Five scenario questions on layer order, cache mounts, multi-stage builds and static binaries. If you miss more than one, reread the lessons in this section.

5 min DockerSecurityPerformance OptimizationDeployment and Containers Advanced
Prev Next
Fullscreen Share
Course content

Sign in to save your progress.

Course Home
1. Your Dockerfile has COPY . . on line 3 and RUN pip install -r requirements.txt on line 4. Every time you change one line of Python code, the build downloads all packages again. What is the best first fix?
Merge all RUN lines into one. Switch to a bigger base image that already has the packages. Copy requirements.txt first, run pip install, and copy the rest of the code after that. Add --no-cache to the build command.
2. You fixed the line order, and code edits are fast now. But when you add one package to requirements.txt, pip downloads every package again, including a large one that did not change. What helps here?
Moving COPY requirements.txt further down in the Dockerfile. Adding --no-cache-dir to pip install. A BuildKit cache mount on the pip install step, pointing at pip's cache folder. Building with --pull every time.
3. A teammate puts files into a cache mount folder during the build and expects the program to read them at run time. The build passes, but the program fails in the container. Why?
Cache mounts are read-only during the build. The cache mount is deleted every time the image is pushed. The program needs to be rebuilt with --no-cache to see the files. A cache mount exists only while that RUN step runs. Nothing in it ends up in the image.
4. You build a Go service in one stage on golang:1.26-bookworm and copy the binary into a scratch image. The container fails to start with no such file or directory, even though the binary is clearly there. What is the most likely cause?
The binary was built with cgo enabled and needs a C library and loader that scratch does not have. Build with CGO_ENABLED=0 or use a runtime base that has the library. The binary is in the wrong folder, it must be in /bin. scratch images cannot run Go programs. The image is too small for the program.
5. Why does a multi-stage build make an image safer, not only smaller?
Docker refuses to run a shell in images built with more than one stage. The final image has no compiler, package manager or shell that the program does not need, so an attacker who gets in has fewer tools to use. Each stage runs on a different machine. Multi-stage builds encrypt the final image.

About

Five scenario questions on layer order, cache mounts, multi-stage builds and static binaries. If you miss more than one, reread the lessons in this section.

Duration
5 min
Last update
08/01/2026
Was this helpful?
​ 0 ​ 0

Comments (0)

Sign in to comment

No comments yet.