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

Final Check: Docker Advanced

Fifteen scenario questions across the whole course. If you get twelve or more right, you can build fast and lean images, run them safely under load and deploy them without surprises.

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

Sign in to save your progress.

Course Home
1. A build log shows the base image and WORKDIR steps as CACHED, then COPY . . runs, then pip install runs again. You only changed a README file. What would have kept pip install cached?
Copy only requirements.txt before the install step, and add files like the README to .dockerignore if the image does not need them. Running the build with more CPUs. Pinning the base image by digest. Using --no-cache.
2. Which statement about a BuildKit cache mount is true?
It replaces the need to order Dockerfile lines carefully. It is kept by the builder between builds and is never part of the image. It is pushed to the registry together with the image. It is created with the CACHE instruction in the Dockerfile.
3. A Go service image is 950 MB. The Dockerfile is a single stage on golang:1.26-bookworm. What change shrinks it the most?
Deleting the Go cache in a later RUN step. A multi-stage build that compiles in the Go image and copies only the static binary into scratch or a small base. Compressing the image before pushing. Adding -ldflags with s and w to the build.
4. docker run --rm --entrypoint id myimage prints uid=0(root). What should you do before this image goes to production?
Nothing, root inside a container is the same as a normal user on the host. Add a user in the Dockerfile and a USER line after the install steps, and give that user only the folders it must write to. Run it with --privileged so it does not need root. Delete the id program from the image.
5. You run a container with read-only and with --cap-drop ALL. Which protection does each give?
read-only also drops all capabilities. read-only stops writes to the image's files. Dropping capabilities stops root-only kernel actions such as changing file owners. Together with a non-root user they cover different risks. Both do the same thing, so one is enough. --cap-drop ALL makes the root filesystem read-only.
6. Your Dockerfile pins alpine 3.24 by digest. Six months later a scan shows several fixed vulnerabilities in the base image. What is the right response?
Ignore the scan, because a pinned image cannot change. Switch to the latest tag. Update the digest to the current one for the same tag, rebuild, test, and set up a bot or schedule so it does not happen again. Remove the digest and use the tag only, so it never gets old again.
7. An image pushed to a private registry includes the line COPY config.json /root/.docker/config.json. What is the risk?
Docker strips config.json automatically during the build. Anyone who can pull the image can read the registry credential in that layer, because auth values are only Base64. None, private registries encrypt layers. The image will not start because the file is in the wrong place.
8. Which docker login form is safe to use in a CI script?
docker login with -p followed by the token in plain text. docker login without arguments, typing the password when asked. Writing the token into a file in the repository and reading it with cat. The token piped into docker login with --password-stdin, from a variable filled by the CI secret store.
9. A container with memory 256m keeps dying under load with exit code 137, while the host has plenty of free memory. What should you do first?
Remove the memory limit for good. Raise the CPU limit. Add restart always so it comes back. Measure the real usage under load with docker stats, then set the limit with room above that, or fix the leak if usage keeps growing.
10. A health check uses curl, but the image is based on python alpine without curl. What will the container show?
unhealthy all the time, even when the app works, because the check command itself fails with not found. The container will refuse to start. healthy, because Docker ignores missing commands. starting forever.
11. Two containers on one Docker Desktop machine both have memory limits of 8 GB, and the WSL 2 VM has 8 GB in total. What does that mean?
Each container gets its own 8 GB from Windows. Docker refuses to start the second container. The limits are ignored on Docker Desktop. The limits do not create memory. Both share the VM's 8 GB, and if they use it together, the VM runs out.
12. You set the json-file driver with max-size 10m and max-file 5 for 40 containers. How much disk can their logs use in total?
50 MB in total for all containers. Up to about 2 GB, because the limit is per container: 40 times 50 MB. Nothing, logs are kept in memory. 10 MB, because max-size is the total.
13. Your production Compose file uses host.docker.internal to reach a service on the host. It works on every laptop and fails on the Linux server. Why?
That name is added by Docker Desktop. On Docker Engine on Linux it exists only if you add it, for example with extra_hosts set to host-gateway. Linux servers block all host traffic from containers. Linux needs the IPv6 version of the name. The server has an older Compose version.
14. In a blue and green deployment with an nginx proxy, why is nginx -s reload used instead of restarting the proxy container?
A reload starts new workers with the new config and lets the old ones finish their requests, so nothing is dropped. A restart stops the proxy for a moment. A restart would delete the blue container. nginx cannot be restarted inside Docker. A reload also updates the app image.
15. You export an SBOM from today's build and scan it today and again in three months. The second scan finds more problems. What should you conclude?
The SBOM file was changed. The first scan was wrong and should be deleted. New vulnerabilities were published for packages in that build. Keep the date and scanner version with every scan result, and rebuild with updated packages. Scanners are random, so scan results are meaningless.

About

Fifteen scenario questions across the whole course. If you get twelve or more right, you can build fast and lean images, run them safely under load and deploy them without surprises.

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

Comments (0)

Sign in to comment

No comments yet.