Top 30 Docker Interview Questions and Answers
30 multiple-choice questions on Docker, drawn from 30 bites out of the 99 tagged Docker on Tezvyn. Answer them here or read straight down. Every question carries the correct option, why it is correct, and a link to the bite it came from.
30 questions. Pick an answer, or open “Show the answer” to read it.
Answers are graded in your browser. Nothing is saved, and no XP or streak is earned here. The app keeps score.
Question 1 of 30
What is the core architectural difference that makes a container lighter than a virtual machine?
Show the answer
Answer: c · Containers share the host kernel instead of booting a full guest OS
Containers share the host's kernel and isolate via namespaces and cgroups, avoiding a full guest OS; the compression claim is irrelevant since the weight savings come from not running a separate kernel.
Question 2 of 30
A developer needs to deploy a microservices application with minimal resource usage and fast startup times. Which technology is generally preferred and why?
Show the answer
Answer: a · Containers, because they share the host OS kernel, reducing overhead.
Containers are preferred for microservices due to their low overhead and fast startup times, achieved by sharing the host OS kernel. VMs, while offering strong isolation, incur significant resource overhead by emulating a full OS.
Read the full bite: VMs vs. Containers: Houses vs. Apartments
Question 3 of 30
When you run a container from an image, how does Docker handle the image layers and runtime file changes?
Show the answer
Answer: a · It keeps the image layers read-only and adds a writable layer on top for runtime changes.
A container mounts the image's read-only layers and adds a writable layer on top, allowing runtime changes without altering the original image. Option B is wrong because containers are isolated processes that share the host kernel, not mini-VMs that boot their own kernels.
Read the full bite: How do Docker images and containers differ and relate?
Question 4 of 30
What is Docker's primary method for resolving the 'Works on My Machine' problem?
Show the answer
Answer: a · It bundles the application with all its specific dependencies into a portable, consistent unit.
The card explicitly states Docker solves this by "packaging an application with all of its dependencies... into a single, isolated unit called a container image." This ensures the environment is consistent everywhere. While related to isolation, containers are distinct from full virtual machines, which are heavier and emulate entire hardware systems.
Question 5 of 30
A container needs its own eth0 and routing table while its init process appears as PID 1. Which clone flags are required to create it?
Show the answer
Answer: c · CLONE_NEWNET and CLONE_NEWPID
CLONE_NEWNET creates a new Network namespace for isolated interfaces and routing tables, while CLONE_NEWPID creates a new PID namespace so the container's init becomes PID 1. Option A is tempting because it includes the correct PID flag, but CLONE_NEWNS isolates mount points rather than network devices.
Read the full bite: Name three Linux namespaces and explain what each one isolates.
Question 6 of 30
Which statement accurately describes a key characteristic of Linux namespaces?
Show the answer
Answer: c · They enable processes to have isolated views of system resources while sharing the host's single kernel.
Linux namespaces provide isolated environments for resources like process IDs and network interfaces, but they all share the host's single kernel. This is a fundamental difference from virtual machines, which run their own independent kernels. The card explicitly states that namespaces are not a sole security boundary for untrusted code.
Read the full bite: Linux Namespaces: A Virtual Slice of the OS
Question 7 of 30
Which component ultimately enforces CPU and memory limits after the container runtime writes the cgroup configuration at startup?
Show the answer
Answer: d · The Linux kernel scheduler and memory manager, using the configured cgroup values
The Linux kernel scheduler and memory manager enforce cgroup limits continuously using values written by the runtime at startup. It is a common misconception that the Docker daemon actively monitors and throttles containers, but the daemon only configures limits while the kernel handles enforcement.
Read the full bite: How do containers enforce CPU and memory limits via cgroups?
Question 8 of 30
A team avoids public Docker images in their non-Docker runtime, believing the format is proprietary to Docker. Which statement corrects this misunderstanding?
Show the answer
Answer: a · Docker images are OCI-compliant bundles that run on any compliant runtime without conversion.
The card calls this belief a footgun, emphasizing that Docker images are OCI-compliant bundles executable by any compliant runtime, much like USB-C devices work with any compliant charger. Option C invents a translation step that the standard eliminates, and option B confuses interface compatibility with performance guarantees.
Question 9 of 30
Which statement correctly describes the relationship between OCI image layers and OverlayFS in container runtime?
Show the answer
Answer: b · OCI specifies layer tarballs and manifests, while OverlayFS is the in-kernel driver that assembles them at runtime
OCI governs the packaging and distribution of images as tarballs and manifests, while OverlayFS is solely a Linux kernel filesystem driver that mounts those layers at runtime. Distractor B is a common misconception that conflates the runtime driver with the image specification itself.
Question 10 of 30
What is the primary reason Union File Systems, like Docker's OverlayFS, can exhibit performance overhead for write-intensive applications?
Show the answer
Answer: a · Each modification to an existing file from a lower layer triggers a copy-on-write operation.
The card states that "The copy-on-write mechanism adds performance overhead for every initial write to a file that exists in a lower layer." This means files from read-only layers must first be copied to the writable layer before they can be modified, which is an extra I/O operation. Distractor A is incorrect because lower layers are read-only and not re-merged on write; changes are isolated to the top writable layer.
Read the full bite: Union File Systems: Docker's Layered Magic
Question 11 of 30
The OCI Runtime Spec primarily standardizes container execution by defining:
Show the answer
Answer: d · The structure of a filesystem bundle and a config.json for runtime instructions.
The OCI Runtime Spec defines the 'filesystem bundle' (a directory containing the root filesystem and a config.json) and the config.json file itself, which specifies how a low-level runtime should execute the container. Option B describes the OCI Image Spec, while options C and D refer to higher-level abstractions or user-facing tools, which the Runtime Spec is explicitly not.
Read the full bite: OCI Runtime Spec: The 'How to Run' Standard for Containers
Question 12 of 30
Which scenario best illustrates the primary benefit of a container runtime shim?
Show the answer
Answer: c · A container daemon crashes, but all running containers continue to operate unaffected.
The primary benefit of a runtime shim is to decouple the container daemon from the container's lifecycle, allowing the daemon to restart or crash without terminating running containers. Option B is incorrect because the daemon (e.g., containerd) prepares the container's filesystem and configuration, not the shim.
Read the full bite: Container Runtime Shim: Decoupling the Container Lifecycle
Question 13 of 30
In docker run -d -p 8080:80 my-app:1.0, what does the 8080:80 specify?
Show the answer
Answer: b · Host port 8080 forwards to container port 80
The -p flag uses host:container ordering, so host 8080 maps to container 80; reversing this is the classic mistake and the other options misread the syntax entirely.
Read the full bite: Build, tag, and run a container with port mapping
Question 14 of 30
What is the primary functional distinction between stopping a container and removing it?
Show the answer
Answer: d · Stopping a container allows it to be restarted later with its preserved internal state, whereas removing it permanently deletes the container instance and any data not on a volume.
The card explicitly states that stopping a container retains its state, allowing it to be restarted, while removing it permanently deletes the container and its non-volume data. Option A is incorrect because 'stop' sends a graceful shutdown signal (SIGTERM), not an immediate termination, and 'rm' deletes an already stopped container, it doesn't initiate the shutdown process itself.
Read the full bite: Container Lifecycle: From Create to Remove
Question 15 of 30
Which core problem in software development does a Dockerfile primarily address?
Show the answer
Answer: c · Guaranteeing that an application's runtime environment is identical everywhere it runs.
The card explicitly states Dockerfiles exist "To solve the classic 'it works on my machine' problem" and "ensure that an application and its dependencies are packaged together and run consistently everywhere." This aligns perfectly with guaranteeing an identical runtime environment. While Docker is used in CI/CD (which includes testing automation), the Dockerfile's direct role is defining the environment, not the testing process itself.
Read the full bite: The Dockerfile: A Recipe for Your Container
Question 16 of 30
What is the primary reason to avoid using the "latest" tag for Docker images in production or CI/CD pipelines?
Show the answer
Answer: b · The image associated with the "latest" tag can be updated at any time, leading to non-reproducible builds and unexpected behavior.
The card explicitly states that the image 'latest' points to can change without warning, leading to unexpected failures or behavior drift, making builds non-reproducible. This mutability is the core issue, not that it's inherently unstable or automatically purged.
Read the full bite: Docker Image Tagging: Versioning for Containers
Question 17 of 30
Why is docker exec -it preferred over docker attach when opening a shell to debug a running container?
Show the answer
Answer: d · exec starts a new process, leaving PID 1 untouched, while attach can kill it on Ctrl-C
exec spawns a separate process so the main process is unaffected, whereas attach connects to PID 1's stdio and Ctrl-C can terminate it; attach is not deprecated and exec does run inside the container.
Read the full bite: Debug a running container with the Docker CLI
Question 18 of 30
What fundamental problem are Docker Volumes primarily designed to solve?
Show the answer
Answer: a · The loss of data written inside a container's filesystem when the container is removed.
Docker Volumes exist because data written directly into a container's filesystem is lost when the container is removed, which is problematic for stateful applications. Option D describes the ephemeral nature of containers, which is the problem volumes counteract, not what they provide.
Read the full bite: Docker Volumes: Persistent Data for Ephemeral Containers
Question 19 of 30
How does docker image prune (without -a) differ from docker image prune -a?
Show the answer
Answer: d · prune removes only dangling images; -a also removes unused tagged images
Plain prune targets only untagged dangling images, while -a additionally removes any tagged image not referenced by a container; -a is not merely a prompt flag and neither command removes containers.
Read the full bite: What is a dangling image and how to prune it
Question 20 of 30
For multi-service applications on a single host, why are user-defined bridge networks preferred over the default bridge network?
Show the answer
Answer: b · They provide an internal DNS service for containers to resolve each other by name.
The card explicitly states that user-defined bridge networks are superior because they provide an internal DNS service, allowing containers to find each other by name, which is essential for multi-service applications. The default bridge network lacks this feature, making it brittle due to changing IP addresses.
Read the full bite: Docker Networking: How Containers Talk to Each Other
Question 21 of 30
To maximize Docker build cache efficiency, how should Dockerfile instructions be ordered?
Show the answer
Answer: c · Arrange instructions from least frequently changing to most frequently changing, top to bottom.
The card advises placing infrequently changing instructions at the top and frequently changing ones as late as possible to optimize cache. Placing frequently changing instructions early, as in option D, is identified as a 'footgun' that invalidates the cache for subsequent steps unnecessarily.
Read the full bite: Docker Build Cache: Don't Rebuild What Hasn't Changed
Question 22 of 30
What is the primary function of a .dockerignore file in a Docker project?
Show the answer
Answer: d · To prevent specific files from being included in the build context sent to the Docker daemon.
The .dockerignore file's main role is to instruct the Docker client to omit specified files and directories from the build context before it's archived and sent to the daemon. While this can lead to smaller final images (C) if those files would have been copied, its direct and primary function is to filter the build context itself, improving build speed and security.
Read the full bite: The .dockerignore File: Keep Your Build Context Lean
Question 23 of 30
What problem do Docker multi-stage builds primarily solve for application deployment?
Show the answer
Answer: b · The excessive size of Docker images due to included build-time dependencies.
The card clearly states that multi-stage builds exist because "creating small Docker images was clumsy" and they "keeps images small by excluding build-time dependencies," dramatically reducing the final image size. While consolidating Dockerfile logic (D) is a side benefit, the primary problem addressed is image bloat.
Read the full bite: Docker Multi-stage Builds: Slimmer, Faster Images
Question 24 of 30
What is the primary benefit of integrating Docker image scanning into a CI/CD pipeline?
Show the answer
Answer: c · It acts as a gate to prevent images with known security flaws from reaching deployment.
The card states that in a CI/CD pipeline, scanning acts as a gate to automatically fail builds containing critical vulnerabilities, preventing them from being deployed. Option D is incorrect because scanning identifies vulnerabilities; it does not automatically remediate or patch them.
Read the full bite: Docker Image Scanning: A Background Check for Your Code
Question 25 of 30
Which approach best balances speed and reliability when building a multi-arch CI pipeline for a compiled microservice targeting amd64 and arm64?
Show the answer
Answer: c · Use native runners for heavy builds, architecture-scoped remote caches, and manifest lists for distribution
The correct answer combines native runners for performance, architecture-scoped caches to prevent cross-arch poisoning, and manifest lists for clean distribution. Option A is tempting because centralizing on x86_64 seems simpler, but the card warns this causes a 5-10x QEMU slowdown and risks cache misses on one architecture invalidating another.
Read the full bite: How would you design a multi-arch build process and anticipate challenges?
Question 26 of 30
What is the main limitation of using Docker Compose alone for production environments?
Show the answer
Answer: c · It lacks features for high availability and automatic scaling.
The card explicitly states that Docker Compose should not be used alone for production because it lacks high-availability, fault tolerance, load balancing, and auto-scaling. The other options describe functionalities that Docker Compose is designed to handle, such as defining multi-service applications, managing networks, and supporting persistent data via volumes.
Read the full bite: The docker-compose.yml File: Your App's Blueprint
Question 27 of 30
What is the primary benefit of defining services in a Docker Compose file for an application?
Show the answer
Answer: c · It provides a declarative way to manage multiple interconnected containers as a single application.
The card states that Docker Compose's purpose is to "manage multi-container applications declaratively" and allows you to "spin up a complete, interconnected environment with a single command." Option A describes features of production orchestration tools like Kubernetes, which the card explicitly states Compose is not.
Read the full bite: Docker Compose Services: Defining Your App's Components
Question 28 of 30
For which scenario is Docker Compose most effectively utilized?
Show the answer
Answer: d · Orchestrating a multi-service application stack for local development and automated testing.
Docker Compose is explicitly designed for orchestrating multi-container applications in local development environments and for automated testing, simplifying the setup of complex service dependencies. It is not recommended for large-scale production deployments, which require more advanced cluster orchestrators.
Read the full bite: Docker Compose: Orchestrate Multi-Container Apps Locally
Question 29 of 30
In a Docker Compose application, how should one service (e.g., 'web') typically refer to another service (e.g., 'database') to establish a connection?
Show the answer
Answer: d · By using the service name 'database' as the hostname.
Docker Compose creates a private network with a built-in DNS service, allowing services to communicate by using their defined service names as hostnames. The card explicitly states that using 'localhost' is a footgun, as it refers to the container itself, not other services.
Read the full bite: Docker Compose Networking: How Services Talk to Each Other
Question 30 of 30
In a typical web-plus-database Compose setup, which storage choice fits each service best?
Show the answer
Answer: b · Bind mount the source code in dev; named volume for the database data
Bind mounts suit live-reloading source in development, while named volumes give Docker-managed, portable durability ideal for database data; bind-mounting production DB files couples data to a fragile host path.
Could you explain these out loud?
That is what an interview actually tests. Tezvyn gives you questions like these with what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.