Top 30 Containers Interview Questions and Answers
30 multiple-choice questions on Containers, drawn from 30 bites out of the 76 tagged Containers 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
How did PR #729's use of Cloudflare Sandboxes eliminate the heartbeat and shutdown-if-idle plumbing required by the earlier Container approach?
Show the answer
Answer: b · By running sandbox.exec() as a one-shot command that naturally terminates when the task finishes.
PR #729 uses sandbox.exec() as a single command that exits when FFmpeg finishes, removing any need for long-lived service coordination. Option A is wrong because the worker does not send heartbeats for the sandbox; the one-shot model eliminates heartbeat logic entirely.
Read the full bite: Cloudflare Sandboxes Cut Container Heartbeat Plumbing
Question 4 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 5 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 6 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 7 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 8 of 30
What is the primary problem that Linux cgroups were designed to solve in a multi-tenant server environment?
Show the answer
Answer: c · Preventing a single application from consuming all available CPU or memory, thus starving other processes.
The card explicitly states that cgroups were introduced because 'a single runaway process could consume all available CPU or memory, starving every other process and crashing the system.' While cgroups are related to container isolation, their primary role is resource limiting, not network traffic isolation or secure communication.
Read the full bite: Linux cgroups: Resource Fences for Processes
Question 9 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 10 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 11 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 12 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 13 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 14 of 30
What is the immediate consequence when a process, protected by an active seccomp profile, attempts to execute a forbidden system call?
Show the answer
Answer: d · The kernel immediately terminates the offending process.
The card states that any attempt by a process to use a syscall not on the allowlist causes the kernel to terminate the process. Seccomp is an enforcement mechanism, not merely an audit tool that logs events.
Read the full bite: seccomp: A Kernel-Level Allowlist for Syscalls
Question 15 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 16 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 17 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 18 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 19 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 20 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 21 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 22 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 23 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 24 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 25 of 30
To ensure a Docker Compose service's image is rebuilt from its Dockerfile after changes, which command is necessary?
Show the answer
Answer: d · docker-compose up --build
The `docker-compose up --build` command explicitly instructs Compose to rebuild images defined with a `build:` key. Running `docker-compose up` without `--build` will use existing images, even if the Dockerfile has been modified, which is a common 'footgun'.
Question 26 of 30
In a hybrid Docker tagging strategy, what distinguishes the role of a Git SHA tag from a SemVer tag at production deployment time?
Show the answer
Answer: d · The Git SHA tag provides an immutable source-to-artifact mapping used in deployment manifests, while SemVer offers human-readable labels for promoted releases.
Git SHA tags are immutable pointers created on every build to provide exact source-to-artifact traceability in manifests, while SemVer tags are human-readable aliases added only to promoted releases. Distractor C reverses this workflow: SHA tags are generated automatically per build, and SemVer is reserved for promoted images.
Read the full bite: How do you version Docker images: Git SHA or SemVer?
Question 27 of 30
Why should a Dockerfile copy requirements.txt and install dependencies before copying the full application source?
Show the answer
Answer: d · It allows Docker to reuse the cached dependency layer when only source code changes
Copying requirements first lets Docker cache the expensive pip install layer and skip it when only application code changes. Image size is unaffected by copy order because the full source is still copied later.
Question 28 of 30
What is Docker Hub's primary role within the Docker ecosystem?
Show the answer
Answer: d · To act as a central, public registry for sharing and discovering container images.
Docker Hub is explicitly defined as a "central repository for finding, storing, and sharing pre-built software containers." It serves as the primary distribution channel for both official and community-contributed images, making it a central registry. The other options describe functions of other Docker components or related technologies like orchestration.
Read the full bite: Docker Hub: The Central Repository for Containers
Question 29 of 30
When an arm64 node pulls a multi-arch image by tag, what does the registry ultimately return?
Show the answer
Answer: a · The matching architecture-specific manifest so only relevant layers are fetched
The card states that after platform content negotiation via headers, the registry returns the matching manifest from the index, not the entire index or a monolithic bundle. While the tag resolves to a manifest list, the node only fetches the manifest and layers for its own architecture.
Read the full bite: How do you manage multi-arch container images under a single tag?
Question 30 of 30
Why does Kubernetes schedule Pods rather than individual containers onto Nodes?
Show the answer
Answer: d · A Pod groups tightly coupled containers that share network and storage as one schedulable unit
The Pod is the unit that bundles a shared IP, volumes, and lifecycle for co-located containers. Containers can run without Kubernetes (C), and a Node runs many Pods (B).
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.