Top 30 Docker & Kubernetes Interview Questions and Answers
30 multiple-choice questions on Docker & Kubernetes, of the kind that come up in a technical interview, drawn from 30 bites in the Docker & Kubernetes library. 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.
Containers, Helm, orchestration, service mesh
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
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 3 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 4 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 5 of 30
Once runc has started the container process, which statement accurately describes its subsequent behavior?
Show the answer
Answer: b · It exits and becomes stateless, leaving containerd to handle stop, delete, and event monitoring.
runc is a short-lived CLI tool that exits after starting the isolated process, while containerd retains lifecycle ownership. The belief that runc stays resident as a daemon is a common misconception; it is stateless and does not monitor cgroups or namespaces after launch.
Read the full bite: Describe the relationship between containerd and runc in starting a container.
Question 6 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 7 of 30
Why does an image built with Docker run correctly on a Kubernetes node that uses containerd and runc instead of the Docker daemon?
Show the answer
Answer: c · They all conform to OCI image and runtime specifications
Interoperability comes from shared OCI image and runtime specs, so any compliant tool can consume the same artifact; there is no rebuild or embedded Docker daemon involved.
Read the full bite: What is the OCI and why do its specs matter?
Question 8 of 30
Why can the host run strace against a container process even though strace is absent from the container image?
Show the answer
Answer: c · The container shares the host kernel, so the host PID can be traced directly
Containers are host processes under a shared kernel, so tracing the mapped host PID works from outside; nothing is injected into the image and strace is not hidden inside it.
Read the full bite: Trace a container process's syscalls from the host
Question 9 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 10 of 30
Which scenario is the legitimate reason to choose ADD over COPY in a Dockerfile?
Show the answer
Answer: a · Auto-extracting a local tar archive into the destination
ADD's distinguishing legitimate feature is auto-extracting local tar archives; plain file copies are exactly what COPY is for, and both support ownership flags so that is not a differentiator.
Question 11 of 30
If a Dockerfile has ENTRYPOINT ["ping"] and CMD ["localhost"], what happens when you run the container with the argument example.com?
Show the answer
Answer: d · It pings example.com, since the arg overrides CMD but appends to ENTRYPOINT
Run-time arguments replace CMD but are appended to ENTRYPOINT, so ping example.com runs; the arg does not replace the ENTRYPOINT executable nor cause a conflict.
Question 12 of 30
Why does copying all source before npm install slow down rebuilds after a code change?
Show the answer
Answer: a · The COPY of changed source invalidates the install layer and everything after it
Cache invalidation cascades from the first changed instruction, so copying edited source before install busts the install layer; npm install does respect the cache when its inputs are unchanged.
Read the full bite: Optimize Dockerfile layer caching for npm install
Question 13 of 30
What is the primary benefit of copying only the compiled binary into a minimal final stage of a multi-stage build?
Show the answer
Answer: d · It produces a smaller image with no toolchain or source, reducing attack surface
Discarding the compiler and source yields a small, hardened production image; multi-stage builds do not remove the kernel dependency, add encryption, or make a binary architecture-independent.
Read the full bite: Multi-stage builds for compiled languages
Question 14 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 15 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 16 of 30
After adding USER app to a Dockerfile, the container starts but the app cannot write to its own directory. What was most likely missed?
Show the answer
Answer: c · The application files were not chowned to the app user, leaving them root-owned
Switching USER without changing file ownership leaves files owned by root, so the unprivileged user cannot write them; USER belongs before CMD and non-root users can write to directories they own.
Question 17 of 30
Why is passing an NPM token via a Dockerfile ARG insecure even if you never reference it in the final stage?
Show the answer
Answer: a · The ARG value is recorded in image metadata and visible via docker history
ARG values persist in the image build history and can be inspected, so the secret leaks; BuildKit secret mounts avoid this by keeping the value in tmpfs only during a single RUN. The other claims are fabricated.
Read the full bite: Pass build-time secrets securely with BuildKit
Question 18 of 30
What is the main operational trade-off of using a distroless image instead of Alpine?
Show the answer
Answer: c · There is no shell or package manager, so debugging by exec is not possible
Removing the shell and package manager shrinks the attack surface but means you cannot exec a shell to debug; distroless is generally smaller, runs binaries fine, and does not require root.
Read the full bite: Distroless images: benefits and trade-offs
Question 19 of 30
Why is docker compose logs -f web preferred over docker logs web to follow a Compose service's output?
Show the answer
Answer: c · compose logs resolves the service name and aggregates its containers, even when scaled
Compose logs takes the service name from the YAML and aggregates all its containers (including scaled replicas), whereas docker logs needs a specific container name or ID; docker logs does support -f.
Read the full bite: Start Compose services detached and view one service's logs
Question 20 of 30
You mount a named volume at the Postgres data directory, then run docker compose down. Why does the data survive?
Show the answer
Answer: a · Named volumes are managed independently of containers, so removing containers leaves them intact
Named volumes have a lifetime separate from containers, so down (which removes containers) leaves the volume and its data; there is no snapshot, and down does remove containers unless you add -v which would also delete the volume.
Read the full bite: Persist PostgreSQL data across compose down
Question 21 of 30
In a Compose project, why does the web app use db (the service name) rather than localhost to reach the database?
Show the answer
Answer: d · From inside the web container, localhost is the web container itself; db resolves via Docker DNS to the database
Each container's localhost refers to itself, so the web container must use the database's service name, which Docker's embedded DNS resolves to the right container; the localhost-blocking and protocol claims are false.
Read the full bite: How Compose services reach each other by name
Question 22 of 30
Why can Compose services resolve each other by name on the default network but containers on Docker's legacy default bridge cannot?
Show the answer
Answer: a · Compose creates a user-defined bridge, which includes embedded DNS, unlike the legacy default bridge
Compose's per-project network is a user-defined bridge with embedded DNS enabling name resolution, whereas Docker's legacy default bridge lacks automatic DNS; Compose neither disables DNS nor uses host networking by default.
Question 23 of 30
Why does adding plain depends_on: [db] often fail to fix a web app crashing on startup against a slow database?
Show the answer
Answer: b · depends_on only orders container start; it does not wait for the database to become ready
Short-form depends_on controls start order but not readiness, so the app may start before the DB accepts connections; you need a healthcheck plus condition: service_healthy. depends_on is neither deprecated nor reversed.
Read the full bite: Manage startup order and readiness in Compose
Question 24 of 30
When should a Compose service use the build directive instead of image?
Show the answer
Answer: d · When the service runs your own application code with no published image
build compiles an image from your local Dockerfile, which is needed for custom application code; stock third-party services use image to pull from a registry, and the size and network claims are irrelevant.
Read the full bite: Compose image directive versus build directive
Question 25 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.
Question 26 of 30
When you run docker compose up with no -f flags in a directory containing both compose.yaml and compose.override.yaml, what happens?
Show the answer
Answer: d · Compose merges compose.override.yaml on top of compose.yaml automatically
Compose auto-loads and deep-merges compose.override.yaml over the base. It does not ignore it (A) nor wholesale-replace the base (C); merging is the defined behavior, not an error (B).
Read the full bite: Structuring Compose files across environments
Question 27 of 30
Why does copying the full source before installing dependencies hurt build caching when only one code line changes?
Show the answer
Answer: b · The changed source busts the COPY layer, invalidating the later install layer too
A changed layer invalidates itself and every subsequent layer, so installing after copying source forces a reinstall. Caching is not disabled by COPY (A) and does apply to intermediate layers (D).
Question 28 of 30
In a Compose file, a service has profiles: ["debug"] and another service has no profiles key. What does a plain docker compose up start?
Show the answer
Answer: c · Only the service without a profile
Services without a profile always start; profiled services stay off until their profile is activated. So only the unprofiled service runs, not both (B) and not nothing (D).
Read the full bite: Docker Compose profiles for optional services
Question 29 of 30
You run docker push my-app after building locally and get an authentication error. What is the most likely cause?
Show the answer
Answer: c · The bare name defaults to Docker Hub, where you lack push rights, instead of your private registry
An image reference without a registry host defaults to Docker Hub, so the push targets the wrong place. The image exists (D) and commit is unrelated (B); push is cross-platform (A).
Read the full bite: Tag and push an image to a private registry
Question 30 of 30
What is the core problem with deploying app:latest to production Kubernetes?
Show the answer
Answer: d · The tag is mutable, so the same reference can resolve to different code across pods and time
latest is a movable pointer, breaking reproducibility and rollbacks. It is not blocked by Kubernetes (A), unrelated to size (B), and does not affect health checks (C).
Read the full bite: Why :latest is a production anti-pattern
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.