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: Images That Don't Leak

Five scenario questions on capabilities, USER lines, port 80, digests and scan results. 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. A container runs as root with Docker's default capabilities. You add --cap-drop ALL and the app keeps working. What changed?
Nothing changed, because capabilities only matter on Linux servers. The process is still called root, but it lost the kernel permissions such as changing file owners, so a bug in it can do much less. The container can no longer use the network. The container now runs as a normal user.
2. You add USER app as the second line of your Dockerfile, before RUN apk add. The build fails with a permission error. What is the right fix?
Use sudo in the RUN line. Remove the USER line. Add --privileged to the build. Move USER app below the steps that need root, such as installing packages, so it is near the end.
3. A team says their app must run as root because it listens on port 80. On a current Docker version, what is true?
The app needs --privileged to listen on port 80. Non-root containers cannot publish any ports. Only root can ever listen on ports below 1024. A non-root user can bind port 80 inside the container, because Docker lowers the unprivileged port start for the container. If a platform does not allow it, publish a high port such as 8080 instead.
4. Your Dockerfile has FROM python:3.14-alpine@sha256 followed by a digest. A security fix for the base image is published next week. What happens to your next build?
Nothing changes. The digest keeps building the old base until you update it, so you need a bot or a schedule to move it. Docker updates the digest automatically. The tag wins over the digest, so you get the fix. The build fails because the digest is outdated.
5. A vulnerability scan of the same image gave 3 findings last month and 9 today. Nobody rebuilt the image. What is the most likely explanation?
Images get more packages as they age. The scanner is broken and should be ignored. The vulnerability database was updated with new CVEs for packages that are already in the image. Someone changed the image in the registry without a new digest.

About

Five scenario questions on capabilities, USER lines, port 80, digests and scan results. 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.