100% Free
🎯 3200+ Questions. One Goal: Your Success Sign In Sign Up

Amazon Interview Docker Interview Questions

Curated Amazon Interview-level Docker interview questions for developers targeting amazon interview positions. 155 questions available.

Last updated:

Docker Interview Questions & Answers

Skip to Questions

Welcome to our comprehensive collection of Docker interview questions and answers. This page contains expertly curated interview questions covering all aspects of Docker, from fundamental concepts to advanced topics. Whether you're preparing for an entry-level position or a senior role, you'll find questions tailored to your experience level.

Our Docker interview questions are designed to help you:

  • Understand core concepts and best practices in Docker
  • Prepare for technical interviews at all experience levels
  • Master both theoretical knowledge and practical application
  • Build confidence for your next Docker interview

Each question includes detailed answers and explanations to help you understand not just what the answer is, but why it's correct. We cover topics ranging from basic Docker concepts to advanced scenarios that you might encounter in senior-level interviews.

Use the filters below to find questions by difficulty level (Entry, Junior, Mid, Senior, Expert) or focus specifically on code challenges. Each question is carefully crafted to reflect real-world interview scenarios you'll encounter at top tech companies, startups, and MNCs.

Questions

155 questions
Q1:

What problem does Docker solve compared to traditional application deployments?

Entry

Answer

Docker eliminates environment mismatch problems by packaging apps with all dependencies into portable containers that behave consistently across machines.
Quick Summary: Before Docker, "works on my machine" was a real problem — different OS, different libraries, different configs on dev vs prod. Docker packages your app and all its dependencies into one container that runs identically everywhere. No more environment drift, no more manual setup, no more surprise failures at deployment.
Permalink
Q2:

How is a Docker container different from a virtual machine?

Entry

Answer

Containers share the host OS kernel while VMs run a full OS. Containers start faster, use less memory, and are more efficient, while VMs provide stronger isolation with higher overhead.
Quick Summary: A VM runs a full guest operating system on top of a hypervisor — heavy, slow to start, GBs of disk. A container shares the host OS kernel and only packages the app and its libraries — lightweight, starts in milliseconds, uses far less disk and RAM. Containers are like isolated processes, not isolated computers.
Permalink
Q3:

What is a Docker image?

Entry

Answer

A Docker image is a read-only template containing application code, runtime, dependencies, filesystem, and configuration needed to run a container.
Quick Summary: A Docker image is a read-only, layered snapshot of your application — it includes the OS base, runtime, dependencies, and your code. Think of it as a blueprint. When you run it, Docker creates a live, writable container from it. The same image can spin up hundreds of identical containers.
Permalink
Q4:

What is the role of a Dockerfile?

Entry

Answer

A Dockerfile contains step-by-step instructions to build an image such as selecting a base image, installing packages, copying code, exposing ports, and defining entrypoints.
Quick Summary: A Dockerfile is a script of instructions telling Docker how to build your image — start from a base image, install packages, copy code, set the startup command. Every instruction creates a layer. Docker reads the Dockerfile top to bottom and assembles a ready-to-run image from it.
Permalink
Q5:

What does the FROM instruction do in a Dockerfile?

Entry

Answer

FROM sets the base image for your container, for example FROM node:20-alpine or FROM ubuntu:22.04.
Quick Summary: FROM sets the base image — the starting point for your new image. Everything you build on top (RUN, COPY, etc.) layers on top of this base. FROM ubuntu:22.04 starts with Ubuntu; FROM node:20-alpine starts with Node pre-installed on Alpine. Choosing the right base image affects size, security, and compatibility.
Permalink
Q6:

Why do Docker images contain multiple layers?

Entry

Answer

Each Dockerfile instruction creates a layer. Layers improve build speed via caching, reuse, and incremental distribution.
Quick Summary: Each instruction in a Dockerfile creates a separate layer. Layers are cached — if a layer hasn't changed, Docker reuses it from cache instead of rebuilding. This makes rebuilds fast. Layers are also shared between images — if two images use the same base, they share those layers on disk, saving space.
Permalink
Q7:

What is the purpose of the ENTRYPOINT instruction?

Entry

Answer

ENTRYPOINT defines the main command a container runs automatically, giving it a predictable default behavior.
Quick Summary: ENTRYPOINT sets the main executable that always runs when the container starts. It defines the container's purpose — like setting it to run nginx or a Python script. CMD provides default arguments to ENTRYPOINT, but they can be overridden at runtime. ENTRYPOINT is the fixed behavior; CMD is the flexible part.
Permalink
Q8:

What does docker run -p 8080:80 mean?

Entry

Answer

It maps host port 8080 to container port 80, allowing external traffic from the host to reach the container.
Quick Summary: -p 8080:80 maps port 80 inside the container to port 8080 on your host machine. Traffic hitting localhost:8080 on your machine is forwarded to port 80 in the container. Format is always host:container. Without -p, the container's port is unreachable from outside.
Permalink
Q9:

What is the difference between CMD and ENTRYPOINT?

Entry

Answer

ENTRYPOINT defines the primary executable, while CMD provides default arguments. If both exist, CMD arguments are passed to ENTRYPOINT.
Quick Summary: CMD sets the default command run at container startup — fully replaceable when you pass a command to docker run. ENTRYPOINT sets a fixed entry command that always runs — additional arguments from CMD or docker run are appended to it. ENTRYPOINT is for defining what the container IS; CMD is for its default behavior.
Permalink
Q10:

What is a container registry?

Entry

Answer

A container registry stores and distributes Docker images. Examples include Docker Hub, GitHub Container Registry, and AWS ECR.
Quick Summary: A container registry is a storage server for Docker images — you push images to it and pull them on other machines. Docker Hub is the public default. Companies use private registries (AWS ECR, Google Artifact Registry, Harbor) to store proprietary images securely and control access.
Permalink
Q11:

What is the difference between docker stop and docker kill?

Entry

Answer

docker stop sends SIGTERM for graceful shutdown, while docker kill sends SIGKILL for immediate forced termination.
Quick Summary: docker stop sends SIGTERM, giving the container's process time to shut down gracefully — it can save state, close connections, finish in-flight work. After a timeout (default 10s), it sends SIGKILL. docker kill immediately sends SIGKILL — instant termination with no cleanup. Always prefer stop for production workloads.
Permalink
Q12:

What does docker exec do?

Entry

Answer

docker exec runs a command inside a running container, such as docker exec -it myapp bash.
Quick Summary: docker exec runs a new command inside an already-running container. Most common use: docker exec -it bash — opens an interactive shell inside a live container for debugging. The container stays running; you're just attaching an extra process to it. Nothing in the container is interrupted.
Permalink
Q13:

What is a bind mount in Docker?

Entry

Answer

A bind mount attaches a host folder into a container. Changes are reflected both ways and commonly used in development.
Quick Summary: A bind mount maps a specific host directory or file directly into the container. Changes from either side are immediately visible to the other. Great for development (code changes reflect instantly) but fragile in production — it ties the container to a specific host path, reducing portability.
Permalink
Q14:

What is a Docker volume and why is it preferred over bind mounts in production?

Entry

Answer

A Docker volume is managed by Docker and provides independent, durable storage with better performance and isolation compared to bind mounts.
Quick Summary: A Docker volume is managed by Docker itself, stored in Docker's own area (/var/lib/docker/volumes). Unlike bind mounts, volumes work regardless of host directory structure, support backup drivers, and survive container deletion. They're the right choice for databases and persistent app data in production.
Permalink
Q15:

What is an image tag?

Entry

Answer

An image tag identifies the image version, such as nginx:1.25. Without a tag, Docker uses :latest.
Quick Summary: An image tag is a label that identifies a specific version of an image — like nginx:1.25 or myapp:v2.1. Without a tag, Docker defaults to latest. Tags are just pointers — they don't guarantee the image is the "latest" version unless you explicitly updated them. Tag images with commit hashes or version numbers for traceability.
Permalink
Q16:

What is the purpose of .dockerignore?

Entry

Answer

.dockerignore excludes files from the build context to speed up builds and reduce image size.
Quick Summary: .dockerignore tells Docker which files to exclude from the build context sent to the daemon. Without it, your entire project folder (including node_modules, .git, large test fixtures) gets sent on every build — slowing it down. It works like .gitignore — patterns of files/folders to skip.
Permalink
Q17:

What happens if you run a container without specifying --name?

Entry

Answer

Docker assigns a random name automatically, such as friendly_moose.
Quick Summary: Docker generates a random two-word name (e.g., "quirky_tesla"). The container still gets a unique ID regardless. The auto-generated name is for human convenience in docker ps — you can use it in commands instead of the full ID. Using --name yourself makes scripts and logs more readable.
Permalink
Q18:

What does docker ps -a show?

Entry

Answer

docker ps -a lists all containers including running, stopped, and exited ones, useful for debugging.
Quick Summary: docker ps shows running containers. docker ps -a shows ALL containers — running, stopped, and exited. Stopped containers still exist on disk with their data until you explicitly remove them with docker rm. This is how you recover a crashed container's logs or inspect what went wrong.
Permalink
Q19:

Why shouldn’t you install unnecessary packages inside a container?

Entry

Answer

Unnecessary packages increase image size, attack surface, and build time. Production images should be minimal.
Quick Summary: Every package you install adds to the image size, increases the attack surface, and takes longer to build and pull. A container should do one job. Extra tools (curl, wget, vim) are convenient during dev but become security risks in production — they give an attacker more tools to work with if they break in.
Permalink
Q20:

What is Alpine Linux and why is it popular in Docker?

Entry

Answer

Alpine Linux is a lightweight distribution (~5MB). Alpine-based images significantly reduce final image size.
Quick Summary: Alpine is a minimal Linux distro built for security and small footprint — the base image is about 5MB vs 100MB+ for Ubuntu. Popular in Docker because smaller images build faster, pull faster, and reduce the attack surface. Trade-off: it uses musl libc instead of glibc, which can cause compatibility issues with some software.
Permalink
Q21:

What is the Docker daemon and what role does it play?

Junior

Answer

The Docker daemon (dockerd) manages all Docker objects—containers, images, volumes, networks. It listens to the Docker API and executes client commands like building, running, or stopping containers.
Quick Summary: The Docker daemon (dockerd) is the background service that actually creates and manages containers, images, networks, and volumes. The Docker CLI talks to the daemon via a REST API. The daemon does all the heavy lifting — you just issue commands and it handles the rest.
Permalink
Q22:

Why is the Docker client and Docker daemon separation useful?

Junior

Answer

This separation allows remote container management, CLI running on a different machine, API-driven automation. Docker becomes a client–server architecture.
Quick Summary: The separation means you can run Docker from remote machines, CI systems, or scripts by pointing the client at a remote daemon. It also means the daemon can run as root (needed for kernel-level operations) while the client runs as a regular user. They communicate over a Unix socket or TCP.
Permalink
Q23:

What is the difference between a container’s “image layer” and “container layer”?

Junior

Answer

Image layers are read-only and shared among containers. Container layer is a thin writable layer on top where runtime changes occur.
Quick Summary: Image layers are read-only — they're shared across all containers using that image. The container layer is a thin, writable layer added on top specifically for that container. Any writes (new files, modified files) go into the container layer via copy-on-write. The image underneath is never modified.
Permalink
Q24:

What happens internally when you run docker build?

Junior

Answer

Docker sends build context to daemon, executes each Dockerfile instruction as a new layer, caches layers intelligently, and outputs a final image ID.
Quick Summary: docker build reads the Dockerfile, sends your project folder (build context) to the daemon, then executes each instruction in order. Each instruction creates a new layer. Docker checks its layer cache first — if the layer hasn't changed, it reuses it. The final result is a new image tagged with your name.
Permalink
Q25:

What does Docker’s copy-on-write mechanism do?

Junior

Answer

It avoids duplicating data. If many containers use the same layer, Docker creates a new copy only when modification occurs—saving disk space.
Quick Summary: Copy-on-write means containers share read-only image layers until they need to modify a file. When a container writes to a file from an image layer, Docker copies that file into the container's writable layer first — then modifies the copy. The original image layer stays unchanged, shared by all containers.
Permalink
Q26:

Why is docker build . slow when your project folder is huge?

Junior

Answer

Docker sends entire build context to the daemon. Without a .dockerignore, large directories dramatically slow down builds.
Quick Summary: docker build sends your entire project folder (the build context) to the Docker daemon before processing the Dockerfile. If your folder is huge (large node_modules, build artifacts, test datasets), that transfer alone takes seconds or minutes. A .dockerignore file filters out what doesn't need to be sent.
Permalink
Q27:

What is the purpose of multi-stage builds?

Junior

Answer

They split build and runtime stages to create smaller production images, remove build tools, and speed up CI/CD pipelines.
Quick Summary: Multi-stage builds let you use multiple FROM stages in one Dockerfile. Build tools, compilers, and test frameworks run in early stages; only the final artifact gets copied into a clean, minimal final image. Result: production images that are tiny and contain zero build tooling — smaller, faster, more secure.
Permalink
Q28:

What is the difference between ENTRYPOINT exec form and shell form?

Junior

Answer

Exec form uses no shell and passes signals properly. Shell form uses /bin/sh -c and makes signal forwarding harder.
Quick Summary: Shell form (ENTRYPOINT cmd arg) runs through /bin/sh -c — the shell interprets it, so signal handling is poor (PID 1 is the shell, not your app). Exec form (ENTRYPOINT ["cmd", "arg"]) runs the process directly as PID 1 — receives signals correctly for graceful shutdown. Always use exec form in production.
Permalink
Q29:

Why do production Dockerfiles avoid using ADD?

Junior

Answer

ADD auto-extracts archives and supports remote URLs, causing unpredictable builds. COPY is preferred unless extraction is needed.
Quick Summary: ADD can accept remote URLs and auto-extracts tarballs — which sounds useful but adds implicit behavior and is a security risk (fetching from remote URLs during build). COPY is explicit — it only copies files from the local build context. Prefer COPY; use ADD only when you specifically need tarball extraction.
Permalink
Q30:

What is Docker Hub rate limiting?

Junior

Answer

Unauthenticated users have pull limits. Exceeding limits prevents image pulls. Solutions include login, mirrors, or private registry.
Quick Summary: Docker Hub limits unauthenticated pulls (100/6h) and free account pulls (200/6h). In CI pipelines with many parallel jobs, you can easily hit the limit and get 429 errors. Solutions: authenticate with a Docker Hub account, use a pull-through cache, or mirror images to a private registry.
Permalink
Q31:

What is Docker Compose and why is it useful?

Junior

Answer

Compose defines multi-container apps via YAML, managing networks, volumes, dependencies, and startup order.
Quick Summary: Docker Compose defines and runs multi-container applications using a YAML file. Instead of manually running multiple docker run commands with all their flags, you declare all services, networks, and volumes in one docker-compose.yml and start everything with docker compose up. Great for local dev and simple deployments.
Permalink
Q32:

What is the difference between docker-compose up and docker-compose up --build?

Junior

Answer

up uses existing images. up --build forces image rebuild before starting services.
Quick Summary: docker compose up starts existing containers (or creates them if they don't exist) using the current images. docker compose up --build forces Docker to rebuild images before starting — picks up Dockerfile changes. Without --build, code changes in your Dockerfile won't be reflected in running containers.
Permalink
Q33:

How do Compose networks isolate containers?

Junior

Answer

Each project gets a dedicated bridge network. Containers communicate via service names, keeping environments isolated.
Quick Summary: Compose creates a private virtual network for your project. Services on the same network can reach each other by service name as the hostname (e.g., the web service reaches the DB as "db"). Services on different Compose networks or the host can't reach each other by default — clean isolation out of the box.
Permalink
Q34:

Why is it a bad practice to store secrets inside images?

Junior

Answer

Images can be extracted or shared, exposing secrets permanently. Secrets cannot be revoked once baked into images.
Quick Summary: Images are shareable and often public (or accessible to anyone with registry access). Baking secrets (API keys, DB passwords) into an image means everyone who pulls it gets the secrets — forever, even after you "delete" them, because they're in the layer history. Use environment variables or secrets managers at runtime instead.
Permalink
Q35:

What is the concept of image digest?

Junior

Answer

Digest uniquely identifies image content. Unlike tags, digests are immutable and ensure reproducible builds.
Quick Summary: A digest is a SHA256 hash of an image's content — it uniquely and immutably identifies an exact version of an image. Unlike tags (which can be moved), a digest never changes. Pinning by digest (image@sha256:abc123...) guarantees you always pull exactly the same image, even if someone updates the tag.
Permalink
Q36:

Why is latest tag dangerous in production?

Junior

Answer

latest is mutable; pulling it later may fetch a different version, causing inconsistent environments.
Quick Summary: latest is just a tag — it points to whatever image was last pushed with that tag. It gives no guarantee of stability, version, or compatibility. In production, if you pull latest and the image changed, your deployment behavior changes silently. Always pin to a specific version tag or digest.
Permalink
Q37:

How does Docker’s overlay filesystem affect performance?

Junior

Answer

OverlayFS adds extra read/write layers. Heavy writes slow performance compared to native filesystems.
Quick Summary: OverlayFS stacks read-only image layers under a writable container layer. File reads go through the layer stack — usually fast. Writes trigger copy-on-write: Docker copies the file from the image layer into the container layer, then modifies it. Frequent writes to many large files in a container can be slower than native disk I/O.
Permalink
Q38:

What does stateless container mean?

Junior

Answer

A stateless container does not store persistent data. Volumes or external services store data instead.
Quick Summary: A stateless container stores no persistent data internally — all data goes to external volumes, databases, or caches. When the container restarts or is replaced, nothing is lost. Stateless containers are easy to scale (just add more copies), update (replace without migration), and recover (restart instantly).
Permalink
Q39:

Why should you avoid running multiple processes in one container?

Junior

Answer

One process ensures clean logging, easier monitoring, simple restarts, and better scaling.
Quick Summary: One process per container keeps things focused and clean. Multiple processes in one container means you need a process supervisor (like supervisord), signals get complicated (PID 1 needs to handle them all), logs get mixed, and failure recovery is harder. If one process crashes, you can't restart just that part.
Permalink
Q40:

What is the difference between scaling at container vs node level?

Junior

Answer

Container-level scaling means more replicas on same node; node-level scaling distributes containers across nodes.
Quick Summary: Container scaling adds more container instances on the same node — uses more CPU/RAM on that host. Node scaling adds more physical or virtual machines to the cluster. Container scaling is fast (seconds); node scaling is slower (minutes). Orchestrators like Kubernetes do both automatically based on load.
Permalink
Q41:

What is the difference between a named volume and an anonymous volume?

Junior

Answer

Named volumes are persistent and reusable; anonymous volumes are temporary and often lost on container removal.
Quick Summary: Named volumes have an explicit name you give them — they persist after the container is removed and can be reused by name. Anonymous volumes are created without a name — Docker assigns a random ID, and they're harder to find and manage. Named volumes are always the right choice for data you want to keep.
Permalink
Q42:

What is a healthcheck in Docker?

Junior

Answer

A command that checks container health; orchestrators restart containers if unhealthy.
Quick Summary: A healthcheck is a command Docker runs periodically inside the container to verify it's working correctly. If it fails repeatedly, Docker marks the container as unhealthy. Orchestrators use health status to decide when a container is ready for traffic or needs to be restarted — far smarter than just checking if the process is running.
Permalink
Q43:

Why do some Docker images use non-root users?

Junior

Answer

Running as root is insecure. Non-root users reduce risk and prevent privilege escalation.
Quick Summary: Running as root inside a container means if an attacker escapes the container (container breakout), they're root on the host — catastrophic. A non-root user limits the blast radius. The process can still read and write its data but can't install system packages, modify critical files, or escalate privileges easily.
Permalink
Q44:

Explain the difference between docker logs and docker attach.

Junior

Answer

docker logs shows output; docker attach connects to live STDIN/STDOUT and may interfere with the process.
Quick Summary: docker logs reads the container's captured stdout/stderr output — non-interactive, shows historical output, can be filtered by time. docker attach connects your terminal directly to the container's running process I/O — interactive, real-time, but detaching requires Ctrl+P+Q or you'll stop the container. logs is safer for debugging.
Permalink
Q45:

Why does Docker cache layers but not RUN commands that modify external states?

Junior

Answer

Docker caches based on file changes only. External states do not invalidate cache.
Quick Summary: Docker caches layers based on the instruction and its context at build time. RUN commands that download from the internet (apt-get, curl) are cached based on the instruction text — not the external content. So if an apt package updates, Docker still uses the cached layer. To force a fresh download, break the cache manually.
Permalink
Q46:

What is an image base layer?

Junior

Answer

The base layer (like ubuntu:22.04) is the foundation layer on which all other layers build.
Quick Summary: The base layer is the foundation of every image — defined by the FROM instruction. It's the first layer, typically a minimal OS (Alpine, Debian, Ubuntu) or a language runtime (node, python, golang). Every other layer in your image builds on top of it. Choosing a good base image is the most impactful size decision.
Permalink
Q47:

Why is docker cp not preferred for production?

Junior

Answer

Copying files into containers breaks immutability and leads to unpredictable deployments.
Quick Summary: docker cp copies files between a running container and the host. It's a one-time manual operation — not automated, not version controlled, not part of the image build. In production, files should be in the image or in volumes from the start. Using docker cp to "fix" a running container creates snowflake servers and hides real problems.
Permalink
Q48:

How does Docker handle environment variables?

Junior

Answer

Variables passed with -e or Compose are injected at runtime and override image defaults without being stored in layers.
Quick Summary: Environment variables are passed to containers via -e VAR=value or --env-file. Inside the container they appear as normal env vars that the app reads. They're great for config (database URLs, ports, feature flags) but not for sensitive secrets — they show up in docker inspect and process listings.
Permalink
Q49:

What is the difference between restarting and recreating a container?

Junior

Answer

Restarting keeps container instance; recreating destroys and creates a new instance with updated config.
Quick Summary: Restarting a container (docker restart) stops and starts the same container — same container ID, same writable layer, same data. Recreating a container (docker rm + docker run) destroys the old container entirely and starts fresh from the image. Recreating picks up image changes; restarting does not.
Permalink
Q50:

Why do some images include an .env but avoid copying it?

Junior

Answer

.env provides build-time defaults; copying it exposes secrets and breaks environment separation.
Quick Summary: Some images ship with a sample .env file as documentation (shows which variables are expected). But you never COPY .env into the image itself — that would bake secrets into the image. The real .env gets injected at runtime via --env-file, keeping secrets out of the image and the registry.
Permalink
Q51:

How does Docker’s internal DNS resolve service names?

Junior

Answer

Docker assigns DNS records per network; services resolve each other by name.
Quick Summary: Docker's embedded DNS server (127.0.0.11) answers name lookups inside containers on user-defined networks. When container "web" queries "db", Docker's DNS returns the IP of the container named "db". On the default bridge network this doesn't work — only user-defined networks get DNS resolution by service name.
Permalink
Q52:

Why is ordering of layers important in Dockerfiles?

Junior

Answer

Lower layers cannot be changed without invalidating upper layers; ordering helps maximize caching.
Quick Summary: Each instruction in a Dockerfile creates a cached layer. If an early layer changes (like COPY package.json), all subsequent layers are invalidated and rebuilt. Put slow, rarely-changing steps (install OS packages) early; put fast, frequently-changing steps (copy your code) late. This keeps rebuilds fast during development.
Permalink
Q53:

What is the purpose of the WORKDIR instruction?

Junior

Answer

It sets the working directory for subsequent instructions to avoid long paths.
Quick Summary: WORKDIR sets the working directory for all subsequent RUN, CMD, COPY, and ENTRYPOINT instructions in the Dockerfile. If the directory doesn't exist, Docker creates it. Using WORKDIR is cleaner than cd commands inside RUN steps — it's explicit, readable, and applies consistently to all following instructions.
Permalink
Q54:

Why does docker system prune free so much space?

Junior

Answer

It removes unused images, networks, volumes, and stopped containers that accumulate over time.
Quick Summary: docker system prune removes: stopped containers, dangling images (untagged layers), unused networks, and build cache. All of these accumulate silently during development — especially build cache, which can grow to tens of GBs. Pruning is safe during development; in production, be more targeted (docker image prune, docker volume prune).
Permalink
Q55:

What happens when two containers expose the same host port?

Junior

Answer

Port conflict occurs; only the first container binds successfully while the second fails.
Quick Summary: Docker won't allow two containers to bind to the same host port — the second container fails to start with a "port already in use" error. Each service needs a unique host port. You can have many containers on the same internal container port (all using port 80 internally) as long as they map to different host ports.
Permalink
Q56:

How does Docker internally leverage Linux namespaces to isolate containers?

Mid

Answer

Docker uses namespaces for PID, NET, IPC, UTS, and MNT. Each container sees its own isolated OS view.
Quick Summary: Linux namespaces are kernel features that partition global resources into isolated views. Docker uses: PID namespace (container sees its own process tree), NET namespace (its own network stack), MNT namespace (its own filesystem view), UTS (its own hostname), IPC (its own inter-process communication). Each container gets a fresh set.
Permalink
Q57:

How does cgroups limit container resources?

Mid

Answer

cgroups enforce limits on CPU, RAM, I/O, and PIDs. Exceeding limits causes throttling or OOM kills.
Quick Summary: cgroups (control groups) are a Linux kernel feature that limits and monitors resource usage. Docker uses them to cap how much CPU, RAM, I/O, and network a container can consume. A container with --memory=512m cannot use more than 512MB of RAM — the kernel enforces it, not the app itself.
Permalink
Q58:

Why is OverlayFS used as Docker’s storage backend on Linux?

Mid

Answer

OverlayFS merges read-only image layers with a writable upper layer, reducing duplication and speeding up container creation.
Quick Summary: OverlayFS is a union filesystem that stacks layers on top of each other — perfect for Docker's layered image model. The lower directory (image layers) is read-only; the upper directory (container layer) is writable. Reads check upper first, then lower. OverlayFS is fast, well-supported in the Linux kernel, and Docker's default storage driver on most systems.
Permalink
Q59:

How do orphaned volumes accumulate if not managed properly?

Mid

Answer

Volumes persist after container deletion, accumulating unused data and consuming disk space.
Quick Summary: When you create a volume without naming it, Docker assigns a random ID. When you delete the container, the volume stays but becomes "orphaned" — no container references it, but it takes up disk space. Over time, hundreds of orphaned volumes accumulate. docker volume prune removes all that are unreferenced.
Permalink
Q60:

Why is docker exec not recommended for critical automation?

Mid

Answer

If a container restarts, exec commands break. Exec depends on runtime state and is nondeterministic.
Quick Summary: docker exec attaches a new process to a running container — great for one-off debugging. But it's interactive and ad-hoc, not reliable for automation. If the container restarts, your exec session is gone. For automation, bake the logic into the container startup or use proper orchestration rather than shelling in.
Permalink
Q61:

How does Docker handle DNS resolution for containers on user-defined networks?

Mid

Answer

Docker embeds a DNS server inside each network; containers register by name for service discovery.
Quick Summary: Docker's embedded DNS server (127.0.0.11) resolves container names to IPs on user-defined networks. When a container's IP changes (on restart), Docker updates the DNS entry automatically. This works only on user-defined networks — containers on the default bridge use IPs directly, not names.
Permalink
Q62:

Explain how Docker checks container health through health status propagation.

Mid

Answer

Healthchecks run periodically and transition through starting, healthy, and unhealthy states used by orchestrators.
Quick Summary: Docker's healthcheck runs a command periodically (default every 30s). After a configurable number of consecutive failures (default 3), the container's health status changes to "unhealthy." Orchestrators like Kubernetes or Docker Swarm use this to stop routing traffic to it and trigger a restart or replacement.
Permalink
Q63:

Why does Docker build cache break when COPY or ADD instructions change?

Mid

Answer

COPY/ADD track file checksums; any change invalidates following layers, causing rebuild.
Quick Summary: Docker layer caching is based on the content of the instruction and what was copied at that point. If you change any file that COPY or ADD includes, the hash of that instruction changes, invalidating that layer's cache and every layer after it. Even a timestamp change in a copied file busts the cache for the rest of the build.
Permalink
Q64:

What issues arise when storing logs inside container filesystem instead of stdout/stderr?

Mid

Answer

Logs fill the writable layer, degrade performance, and are lost when containers are deleted.
Quick Summary: Storing logs in the container filesystem fills the container's writable layer — you can't easily ship them, rotate them, or query them from outside. Logging to stdout/stderr lets Docker capture them via the log driver and forward to systems like CloudWatch, ELK, or Splunk. Containers should be observable, not self-archiving.
Permalink
Q65:

What is the significance of the container’s init process (PID 1)?

Mid

Answer

PID 1 does not forward signals properly; using tini or an init wrapper is recommended.
Quick Summary: PID 1 is the init process — it must handle signals properly and reap zombie child processes. In Docker, your app IS PID 1. Many apps aren't written to handle SIGTERM correctly as PID 1, causing containers to ignore graceful shutdown signals. Solutions: use ENTRYPOINT exec form, or prepend your command with tini (a minimal init).
Permalink
Q66:

Why is it dangerous to use containers with host networking mode?

Mid

Answer

Host networking bypasses isolation and exposes host ports, increasing attack surface.
Quick Summary: Host networking (--network=host) puts the container directly on the host's network stack — no isolation, no NAT, the container sees and can reach everything the host can. If the container is compromised, the attacker has full network access to the host environment. Only justifiable for very specific high-performance use cases.
Permalink
Q67:

What is the effect of using docker run --privileged?

Mid

Answer

This grants full host permissions and device access, defeating container security.
Quick Summary: --privileged gives the container nearly all Linux capabilities — it can mount filesystems, load kernel modules, and interact with hardware. Essentially the container becomes root on the host. Extremely dangerous in production — only ever needed for containers that legitimately need kernel-level access (like docker-in-docker setups).
Permalink
Q68:

Why do many companies prefer private container registries over Docker Hub?

Mid

Answer

Private registries provide access control, compliance, privacy, and no rate limits.
Quick Summary: Private registries give companies control over access, SLA, scanning, and retention. Docker Hub is public by default, has rate limits, and can go down (affecting all your deployments). Private registries (ECR, GCR, Harbor) live in your own infrastructure, support role-based access, and integrate with vulnerability scanners.
Permalink
Q69:

What performance impact occurs when containers run on Btrfs or ZFS storage drivers?

Mid

Answer

These drivers support snapshots but have slower random writes compared to overlay2.
Quick Summary: Btrfs and ZFS offer advanced features (snapshots, deduplication, checksumming) but are more complex than OverlayFS. They can have worse write performance in some workloads due to copy-on-write overhead at the filesystem level, especially with many small random writes. OverlayFS is faster and simpler for most container workloads.
Permalink
Q70:

How does Docker optimize repeated downloads using shared layers?

Mid

Answer

Layers with identical checksums are reused, saving storage and reducing pull times.
Quick Summary: Docker images are built from layers, each identified by a SHA256 hash. If two images share a layer (same base image, same dependencies), Docker downloads and stores that layer only once. When pulling a new image, Docker skips layers it already has. This saves significant bandwidth and disk space in large deployments.
Permalink
Q71:

What’s the difference between a dangling image and an unused image?

Mid

Answer

Dangling images are untagged leftovers; unused images are tagged but not referenced by containers.
Quick Summary: A dangling image is an untagged layer — it was previously tagged but got replaced when you rebuilt. It has no name or tag (:) and nothing uses it. An unused image has a tag but no running or stopped container is using it. docker image prune removes dangling images; --all removes unused ones too.
Permalink
Q72:

How does Docker ensure network isolation using iptables?

Mid

Answer

Docker configures NAT, forwarding, and bridge rules for container isolation.
Quick Summary: Docker uses iptables rules to control traffic between containers, from containers to the host, and from the host to containers. Each container network gets its own iptables chain. Docker adds rules that forward traffic appropriately, NAT outbound traffic, and drop connections that shouldn't cross network boundaries.
Permalink
Q73:

Why do CI pipelines use Alpine but production avoids it sometimes?

Mid

Answer

Alpine uses musl libc, causing compatibility issues; production prefers Debian/Ubuntu.
Quick Summary: Alpine is tiny and builds fast — great for CI where image size and pull time matter. In production, Alpine's musl libc can cause compatibility issues with software compiled for glibc (most Linux software). Debugging is harder too — no bash, no common tools. Production images often use debian-slim as a balance.
Permalink
Q74:

How does Docker ensure each container gets its own hostname and domain name?

Mid

Answer

UTS namespace provides isolated hostnames for each container.
Quick Summary: Docker assigns each container its own UTS namespace — it gets its own hostname (defaults to the container ID) and its own domain name. You set a custom hostname with --hostname. This means the container thinks it's on its own machine with its own identity, regardless of the host's actual hostname.
Permalink
Q75:

Why is it important to pin image versions in production?

Mid

Answer

Pinning ensures reproducible builds and stable environments.
Quick Summary: latest tag is mutable — it changes whenever someone pushes a new image. In production, a redeployment that pulls latest could get a completely different image than before. Pinning to a specific version (nginx:1.25.3 or an image digest) guarantees every deployment is identical and reproducible.
Permalink
Q76:

How can a misconfigured healthcheck cause a container to restart repeatedly?

Mid

Answer

If healthchecks fail repeatedly, orchestrators keep restarting the container.
Quick Summary: If a healthcheck command always fails (wrong command, wrong endpoint, wrong port), Docker marks the container unhealthy after the failure threshold. Some orchestrators then restart the container repeatedly — causing a crash loop. Always test your healthcheck command manually inside the container before deploying.
Permalink
Q77:

What happens if a container uses more memory than allowed by cgroup?

Mid

Answer

The kernel OOM killer terminates the container, logged as OOMKilled.
Quick Summary: The cgroup OOM (Out of Memory) killer terminates the container's process. Docker captures this and marks the container as exited with an OOM error. If the container has a restart policy, Docker restarts it — potentially in a loop if the memory limit is genuinely too small. Increase the limit or optimize the app's memory use.
Permalink
Q78:

How does Docker Compose handle service dependencies using depends_on?

Mid

Answer

depends_on controls startup order but doesn’t wait for health; healthchecks are needed.
Quick Summary: depends_on controls startup order — it waits for the dependent service container to start (not to be healthy or ready). So even with depends_on, a web container might start before the database is actually accepting connections. For true readiness, combine depends_on with condition: service_healthy using a healthcheck.
Permalink
Q79:

Why should build tools be removed from production images?

Mid

Answer

Build tools increase size and attack surface; multi-stage builds remove them.
Quick Summary: Build tools (compilers, make, npm in node_modules) are needed to build the app but not to run it. Including them bloats the image (hundreds of MBs) and adds unnecessary attack surface. Multi-stage builds solve this cleanly: build in a heavy stage, copy only the compiled artifact into a minimal final stage.
Permalink
Q80:

How does Docker clean up unused networks and why do they accumulate?

Mid

Answer

Networks persist after containers are removed; docker network prune cleans them.
Quick Summary: Docker creates a network for each Compose project or docker network create call. When containers are removed but networks aren't explicitly removed, the networks linger — empty but taking up namespace. docker network prune removes all networks with no containers. Many CI runs create networks without cleaning them up.
Permalink
Q81:

Why should environment variables never include multi-line secrets?

Mid

Answer

Env vars appear in inspect, process lists, and layer history; use secret managers.
Quick Summary: Environment variables are single-line strings. Multi-line secrets (certificates, private keys) break parsing and are easily exposed in logs, docker inspect output, or /proc/self/environ inside the container. Use Docker Secrets or volume-mount a secrets file for anything multi-line or sensitive.
Permalink
Q82:

How does Docker isolate container PIDs?

Mid

Answer

PID namespaces isolate process trees so containers cannot see each other’s processes.
Quick Summary: Docker uses PID namespaces to give each container its own process ID space. Inside the container, the main process is always PID 1. Processes in different containers have overlapping PID numbers that are completely separate — a PID 42 in container A has nothing to do with PID 42 in container B or the host.
Permalink
Q83:

What issue arises when running too many containers on one host?

Mid

Answer

Resource contention leads to CPU throttling, RAM pressure, IO saturation, and network slowness.
Quick Summary: Too many containers compete for CPU, RAM, disk I/O, and network bandwidth. The host kernel also has overhead per container (namespaces, cgroups, iptables rules). At extreme container counts, scheduling and networking overhead becomes significant. Right-size your containers and use orchestrators to spread load across multiple hosts.
Permalink
Q84:

Why is it recommended to use non-root users inside images?

Mid

Answer

Root in a container is root on the host kernel; escaping container compromises the host.
Quick Summary: Running as root inside a container means file ownership in volumes is root — complex permission issues on the host. More critically, if the container is exploited and there's a container breakout vulnerability, the attacker immediately has root on the host. Non-root users contain the blast radius of any compromise.
Permalink
Q85:

What’s the difference between soft and hard resource limits in Docker?

Mid

Answer

Soft limits may be exceeded temporarily; hard limits cannot be exceeded.
Quick Summary: Soft limits are advisory — the container can exceed them temporarily (memory soft limit = memory.soft_limit_in_bytes). Hard limits are enforced — the kernel kills processes that exceed them (memory hard limit = memory.limit_in_bytes). Docker's --memory flag sets the hard limit; --memory-reservation sets the soft limit.
Permalink
Q86:

How does Docker use union filesystems to support copy-on-write across multiple image layers?

Senior

Answer

Docker uses union FS (Overlay2) to merge read-only layers with a writable layer. Modifications occur only in the upper layer to preserve base layers.
Quick Summary: Union filesystems stack layers into one virtual filesystem view. OverlayFS has a lower dir (read-only image layers merged) and upper dir (writable container layer). Reads check upper first, then lower. Writes go to upper — but first Docker copies the file from lower to upper (copy-on-write) so the lower layer stays unchanged.
Permalink
Q87:

Why does modifying files in lower layers trigger whiteout files in OverlayFS?

Senior

Answer

OverlayFS creates whiteout entries to hide files from lower layers without altering immutable layers.
Quick Summary: When a container modifies a file that exists in a lower read-only image layer, OverlayFS can't just modify it in place (the layer is read-only). So it copies the file up to the writable upper layer first, then modifies the copy. Whiteout files are special markers in the upper layer that indicate a file from a lower layer was deleted.
Permalink
Q88:

How does Docker ensure that different containers do not exhaust host PIDs using PID cgroups?

Senior

Answer

PID cgroups apply limits on the number of processes so containers cannot consume all system PIDs.
Quick Summary: Docker uses PID cgroups to limit the number of processes a container can create. If a container spawns processes without bound (a fork bomb), PID cgroups cap the total and prevent the runaway from affecting the host or other containers. Set with --pids-limit on docker run.
Permalink
Q89:

What mechanisms map container UID/GID to host UID/GID?

Senior

Answer

User namespaces remap container root to unprivileged host users, improving isolation.
Quick Summary: By default, container UIDs map 1:1 to host UIDs — root in the container is root on the host. User namespace remapping changes this: container UID 0 maps to an unprivileged host UID (e.g., 100000). Even if the container is compromised and someone "escapes," they're an unprivileged user on the host.
Permalink
Q90:

Why can running many heavy containers on the same overlay network create large ARP tables?

Senior

Answer

Bridge networks and veth interfaces scale ARP/MAC tables, causing lookup latency and overhead.
Quick Summary: In overlay networks, each container advertises its MAC and IP via VXLAN. With many containers, the ARP table grows — switches and hosts track more entries. At extreme scale (thousands of containers on one overlay), ARP flooding and table overflow become real issues. Modern solutions use BGP or eBPF-based networking instead.
Permalink
Q91:

How does Docker prevent network isolation failures using iptables chains?

Senior

Answer

Docker configures NAT and DOCKER-USER chains to enforce container isolation.
Quick Summary: Docker inserts iptables rules into FORWARD, DOCKER, and DOCKER-USER chains to control traffic. DOCKER-ISOLATION chains prevent cross-network traffic. Docker manages these rules automatically when containers start and stop. Manually modifying iptables alongside Docker can break isolation if you interfere with Docker's chains.
Permalink
Q92:

Why can Docker DNS resolution slow down under high container counts?

Senior

Answer

Embedded DNS scales poorly with many services, causing latency without caching layers.
Quick Summary: Docker's embedded DNS runs as a goroutine in each container's network namespace, listening on 127.0.0.11. Under heavy load with thousands of containers, DNS query queuing and resolution latency increase. Service discovery via DNS works fine up to moderate scale; above that, service meshes or dedicated DNS servers perform better.
Permalink
Q93:

What happens when the Docker daemon crashes while containers run?

Senior

Answer

Containers continue running as normal processes but cannot be managed until dockerd restarts.
Quick Summary: Containers managed by dockerd are tracked with live-restore enabled — they continue running. Without live-restore, a daemon crash stops all containers. Containers have their own runc shim process that keeps them alive independently of dockerd. On restart, dockerd reconnects to running container shims and resumes management.
Permalink
Q94:

How does Docker daemon maintain internal state?

Senior

Answer

It stores metadata and image/layer information in /var/lib/docker.
Quick Summary: The Docker daemon persists state in /var/lib/docker — container configs, volume metadata, network definitions, image layers. On daemon start, it reads this state and reconciles with the actual running containers. This is how Docker survives restarts and knows which containers should be restarted automatically.
Permalink
Q95:

Why might bind mounts degrade container I/O performance?

Senior

Answer

Bind mounts rely on host FS performance; volumes use optimized drivers.
Quick Summary: Bind mounts bypass Docker's storage driver and go through the host filesystem directly. On Linux, this is generally fast. But crossing the VM boundary on Docker Desktop (Mac/Windows) — host filesystem → VM → container — adds significant I/O overhead. For heavy I/O workloads on Mac/Windows, volumes inside the VM are much faster.
Permalink
Q96:

How does Docker detect and garbage-collect orphaned build layers?

Senior

Answer

Unreferenced layers become dangling and are removed by docker system prune.
Quick Summary: Build layers that are no longer referenced by any image tag become dangling. Docker's garbage collector (triggered by docker image prune or BuildKit's own GC) identifies layers with no referencing manifests and removes them. BuildKit tracks layer dependencies more precisely than the classic builder and GC's more aggressively.
Permalink
Q97:

Why is disabling container swap recommended for latency-critical workloads?

Senior

Answer

Swapping introduces unpredictable latency and stalls microservices.
Quick Summary: When a container needs more memory than allocated, Linux uses swap space — writing memory to disk. This causes unpredictable latency spikes as memory pages are swapped in and out. For latency-sensitive workloads (databases, real-time APIs), swap introduces tail latency. Disabling swap forces OOM kills instead, which are faster to detect and recover.
Permalink
Q98:

What is the role of Docker’s shim process?

Senior

Answer

Shim keeps containers alive when dockerd exits and handles STDIO pipes.
Quick Summary: The container shim (containerd-shim) is a small process that acts as the parent of the container process. It sits between dockerd/containerd and runc. When dockerd restarts, the shim keeps the container running and reconnects. It also collects the container's exit code and relays I/O streams. One shim per container.
Permalink
Q99:

Why can log-driver misconfigurations crash hosts?

Senior

Answer

JSON logs fill writable layers, consuming disk and freezing hosts.
Quick Summary: Docker log drivers collect container stdout/stderr and forward them to logging backends (journald, syslog, fluentd, splunk). Some drivers buffer in kernel space. If the logging backend is slow or down, the kernel buffer fills, causing backpressure that blocks container writes to stdout — eventually blocking the container's app process.
Permalink
Q100:

How do image manifests ensure cross-architecture builds?

Senior

Answer

Manifest lists map architectures; clients pull correct images automatically.
Quick Summary: Multi-arch images use an OCI image index (manifest list) — a top-level manifest that points to platform-specific manifests (linux/amd64, linux/arm64). When you pull an image, Docker matches your platform to the right manifest and downloads that architecture's layers. buildx with --platform builds for multiple architectures in one push.
Permalink
Q101:

What causes layer invalidation storms during Docker builds?

Senior

Answer

Early layer changes force rebuild of all subsequent layers.
Quick Summary: Layer cache invalidation cascades: if an early layer changes, all subsequent layers must rebuild. An "invalidation storm" happens when a frequently-changing file (like a package lock) is copied early in the Dockerfile, busting the cache for all subsequent heavy install steps. Fix: copy package manifests first, install, then copy source.
Permalink
Q102:

How does Docker securely copy images between registries?

Senior

Answer

TLS and SHA256 digests ensure confidentiality and integrity.
Quick Summary: Copying images between registries (registry-to-registry) is done with tools like crane, skopeo, or docker pull + push. These transfer image manifests and only the layers the destination registry doesn't already have. TLS is used in transit; content-addressable SHA256 digests verify integrity on both ends.
Permalink
Q103:

Why can Docker services fail DNS lookups after IP churn?

Senior

Answer

Stale DNS caches break lookups; apps need low TTLs.
Quick Summary: Docker's overlay network uses VXLAN tunnels with a key-value store (e.g., etcd) tracking container IPs. After frequent container restarts (IP churn), stale VXLAN FDB entries can persist briefly. A new container gets an old IP, and DNS resolves to the old entry before propagation — causing brief DNS lookup failures.
Permalink
Q104:

How does Docker integrate with AppArmor or SELinux?

Senior

Answer

Security profiles restrict syscalls, capabilities, and filesystem access.
Quick Summary: AppArmor and SELinux are Mandatory Access Control (MAC) systems. Docker applies a default AppArmor profile (docker-default) to containers, restricting what system calls and filesystem paths they can access. SELinux applies type labels. Both add a security layer beyond namespaces — containers can't escape restrictions even as root.
Permalink
Q105:

Why is using network host insecure even internally?

Senior

Answer

It exposes host ports and allows traffic sniffing or injection.
Quick Summary: Host networking removes network isolation entirely — the container shares the host's IP, can listen on any host port, and can reach internal network services. Even on an "internal" network, this breaks multi-tenancy (multiple services fighting for ports), removes container firewall protection, and exposes the host to container vulnerabilities.
Permalink
Q106:

How does Docker sandbox capabilities using Linux capabilities API?

Senior

Answer

Docker drops powerful capabilities like SYS_ADMIN to limit root power.
Quick Summary: Linux capabilities break root's monolithic power into granular permissions: CAP_NET_ADMIN (network config), CAP_SYS_PTRACE (process tracing), CAP_CHOWN (file ownership). Docker drops most capabilities by default and adds only a safe minimal set. --cap-add and --cap-drop let you tune exactly what a container can do.
Permalink
Q107:

What are split DNS zones in Docker Enterprise?

Senior

Answer

Different networks get different DNS zones to avoid name collisions.
Quick Summary: In Docker Enterprise / Swarm environments with split DNS zones, some domain names resolve internally (to internal service IPs) while others resolve externally. Containers need to know which DNS server to query for which domains. Misconfigured DNS split-horizon setups cause containers to get wrong IPs for internal services.
Permalink
Q108:

How does Docker pause process freeze container execution?

Senior

Answer

Pause holds namespaces to checkpoint containers without stopping processes.
Quick Summary: docker pause uses the Linux cgroups freezer subsystem to suspend all processes in a container — they stop executing but stay in memory. The container's filesystem, network, and state remain intact. docker unpause resumes all processes exactly where they left off. Useful for momentarily freezing containers without killing them.
Permalink
Q109:

Why is mounting docker.sock dangerous?

Senior

Answer

Access to docker.sock gives full daemon control ? host root access.
Quick Summary: The Docker daemon socket (/var/run/docker.sock) gives full control over Docker — whoever connects to it can create containers with --privileged, mount host filesystems, read secrets, or even replace running containers. Mounting the socket inside a container grants root-equivalent host access. A well-known container escape vector.
Permalink
Q110:

Why does running many containers degrade overlay network performance?

Senior

Answer

VXLAN encapsulation overhead and endpoint scaling increase CPU usage and latency.
Quick Summary: Docker overlay networking uses VXLAN tunnels with software-defined routing. Every packet between containers on different hosts goes through VXLAN encapsulation and de-encapsulation — extra CPU and latency overhead vs native networking. More containers = more flows = more iptables rules to traverse per packet.
Permalink
Q111:

How do multi-stage builds solve dependency leakage?

Senior

Answer

They exclude build tools from final images and include only minimal artifacts.
Quick Summary: Multi-stage builds compile dependencies in a build stage that includes compilers, SDKs, and tools. Only the final artifact (compiled binary, dist folder) gets copied into a clean runtime stage. Build-time secrets, intermediate files, and tool vulnerabilities never reach the final image — they stay in the discarded build stage.
Permalink
Q112:

Why do rootless Docker installations reduce performance?

Senior

Answer

Rootless mode uses user namespaces and slower unprivileged I/O.
Quick Summary: Rootless Docker runs the daemon and containers as a non-root user using user namespace remapping. This improves security but trades off performance: user namespace UID/GID mapping adds syscall overhead, some storage drivers aren't fully supported, and nested namespaces have restrictions. Worth it in multi-tenant or high-security environments.
Permalink
Q113:

How does Docker handle secrets differently from environment variables?

Senior

Answer

Secrets live in RAM-backed storage and never appear in layers or logs.
Quick Summary: Docker Secrets (in Swarm mode) distribute secret values to containers as temporary in-memory filesystems mounted at /run/secrets/. They're never written to disk or stored in environment variables. Environment variables for secrets are readable via docker inspect and /proc/self/environ — Secrets avoid both exposure vectors.
Permalink
Q114:

Why does Docker prefer iptables for networking?

Senior

Answer

iptables provides NAT, filtering, and forwarding that routing tables cannot.
Quick Summary: iptables is built into the Linux kernel, always available, and supports the exact rules Docker needs: NAT (MASQUERADE for outbound), DNAT (port mapping), and FORWARD filtering for inter-container isolation. It's predictable, fast (kernel-level packet processing), and integrates cleanly with the Linux networking stack Docker builds on.
Permalink
Q115:

What happens when overlay networks have overlapping subnets?

Senior

Answer

IP conflicts break routing and containers become unreachable.
Quick Summary: If two overlay networks are configured with the same subnet (e.g., both using 10.0.0.0/24), containers on different networks can end up with the same IP. Routing breaks — packets destined for one network's container reach the wrong network. Docker doesn't always prevent this at creation time, so subnet planning matters.
Permalink
Q116:

Why does Docker use content-addressable storage for layers?

Senior

Answer

SHA256 layer hashes enable deduplication, integrity guarantees, and caching.
Quick Summary: Content-addressable storage means each layer is identified by the SHA256 hash of its content. Two identical layers (same files, same content) have the same hash and are stored only once — regardless of which image they came from. This enables deduplication across all images on a host and in registries without extra effort.
Permalink
Q117:

What is the difference between hard and soft quotas in cgroups v2?

Senior

Answer

Hard quotas strictly enforce limits; soft quotas allow temporary bursts.
Quick Summary: cgroups v2 uses a unified hierarchy. Soft quota (memory.low) is a best-effort lower bound — memory below this is less likely to be reclaimed under pressure. Hard quota (memory.max) is the hard ceiling — processes are killed if they exceed it. v2 also adds memory.high (soft max that triggers throttling before killing).
Permalink
Q118:

Why are runtimes moving to eBPF-based networking?

Senior

Answer

eBPF avoids iptables bottlenecks and provides high-performance packet filtering.
Quick Summary: eBPF programs run in the kernel and can intercept network packets at various hook points with near-zero overhead — no iptables rules to traverse, no userspace context switches. Networking tools like Cilium use eBPF to replace iptables for container routing, enabling faster packet processing and richer observability at scale.
Permalink
Q119:

How does Docker isolate IPC mechanisms?

Senior

Answer

IPC namespaces isolate shared memory and semaphore segments.
Quick Summary: Docker uses IPC namespaces to isolate System V IPC (message queues, semaphores, shared memory) between containers. By default each container gets its own IPC namespace — processes in different containers can't share memory or signal each other via IPC. --ipc=host or --ipc=container: relaxes this for specific use cases.
Permalink
Q120:

Why is building images directly on production servers discouraged?

Senior

Answer

Build contexts may leak secrets and introduce supply-chain risks.
Quick Summary: Building on production servers means the build process (which downloads packages, compiles code, runs scripts) runs on the same machine serving user traffic. A bad build can consume CPU/RAM, introduce partially-built artifacts, or install unwanted packages. Build on CI servers, push the image, pull and run on production.
Permalink
Q121:

How does Docker ensure layers pulled from registries are tamper-proof?

Senior

Answer

Layer digests are verified before extraction to detect tampering.
Quick Summary: Docker validates layers using SHA256 content digests from the image manifest. When pulling, Docker computes the SHA256 of each downloaded layer and compares it to the manifest's expected digest. If they don't match, the pull fails with a checksum error. This detects both transmission corruption and registry tampering.
Permalink
Q122:

Why can a container’s time drift from the host clock?

Senior

Answer

Timezone mounts or custom configurations may cause drift from host time.
Quick Summary: Containers share the host kernel and use the host's hardware clock. The container cannot modify the system clock (CAP_SYS_TIME is dropped by default). However, virtual machine environments running Docker can have clock drift between the VM's clock and the host. NTP sync inside the VM (not the container) is the fix.
Permalink
Q123:

How do overlay networks maintain VXLAN mappings across nodes?

Senior

Answer

Metadata stores exchange MAC-to-IP mappings for VXLAN routing.
Quick Summary: Docker overlay networks use VXLAN (Virtual eXtensible LAN) tunnels between hosts. Each host maintains a VXLAN Forwarding Database (FDB) that maps container MAC addresses to host IPs. When a container moves or restarts, the FDB entry is updated via the control plane (gossip protocol in Swarm, etcd in others).
Permalink
Q124:

Why avoid running databases in Docker without tuning storage drivers?

Senior

Answer

Overlay2 causes write latency and fsync issues affecting DB durability.
Quick Summary: Databases do heavy sequential writes and need low-latency fsync. Some storage drivers (devicemapper, btrfs) add copy-on-write overhead to every write, increasing latency. For databases in Docker, use a named volume mapped to a fast storage path (not the overlay filesystem), and choose OverlayFS2 or direct-lvm devicemapper.
Permalink
Q125:

How does Docker prevent container resurrection after deletion?

Senior

Answer

Docker deletes metadata so deleted container IDs cannot be reused.
Quick Summary: When you docker rm a container, Docker removes the container metadata and its writable layer. The container ID is freed. If a restart policy was set, the container is no longer tracked — it won't restart. The OCI state directory is cleaned up, and containerd removes the container record from its internal database.
Permalink
Q126:

How does runc actually create a container process from an OCI bundle?

Expert

Answer

runc reads the OCI spec, sets namespaces, configures cgroups, mounts rootfs using pivot_root, drops capabilities, and execve()s the entrypoint to create an isolated environment.
Quick Summary: runc receives an OCI bundle: a config.json describing the container spec (namespaces, cgroups, mounts, capabilities) and a rootfs directory. runc creates the Linux namespaces, applies cgroup limits, sets up mounts, drops capabilities, and then executes the container's entry process. After handoff, runc exits and the shim takes over.
Permalink
Q127:

Why is container root not equivalent to host root when user namespaces are enabled?

Expert

Answer

User namespaces remap UID 0 inside container to an unprivileged UID on host, preventing host-level root access.
Quick Summary: With user namespaces enabled, container UID 0 (root) maps to an unprivileged UID on the host (e.g., 100000). Inside the container, a process has full root capabilities within the namespace. But on the host, it's just a regular unprivileged user. Files created by "container root" are owned by UID 100000 on the host — not actual root.
Permalink
Q128:

What are the security weaknesses of Docker’s default seccomp profile?

Expert

Answer

It blocks dangerous syscalls but still allows many exploitable ones; hardened profiles are needed for secure environments.
Quick Summary: Docker's default seccomp profile blocks about 44 of the ~300+ Linux syscalls — ones rarely needed by containers but dangerous if available: keyctl, ptrace, kexec_load, mount, unshare. It doesn't block everything risky, leaving many syscalls open for compatibility. A custom, tighter profile significantly hardens containers.
Permalink
Q129:

How does Docker avoid race conditions between runc and dockerd during container creation?

Expert

Answer

Docker inserts a shim process between runc and dockerd so containers continue even if dockerd restarts.
Quick Summary: runc creates namespaces and the container process, then signals containerd-shim that it's ready. dockerd waits for the shim to confirm container start before returning. Internal locking and a handshake protocol prevent race conditions between runc exiting and the shim beginning to manage the container lifecycle.
Permalink
Q130:

Why does overlay networking introduce additional latency compared to direct bridge networking?

Expert

Answer

VXLAN encapsulation adds overhead and packets may cross nodes, increasing RTT and CPU cost.
Quick Summary: Overlay networking adds VXLAN encapsulation: each packet gets wrapped in a UDP/VXLAN header (50+ bytes of overhead), processed by the kernel's VXLAN driver, and decapsulated on the other end. This is 2-3 extra kernel operations per packet vs direct bridge networking. At high packet rates, this latency adds up.
Permalink
Q131:

How does Docker’s overlay implementation differ from Kubernetes CNI plugins?

Expert

Answer

Swarm uses libnetwork with built-in control plane; Kubernetes uses pluggable CNIs with independent data/control planes.
Quick Summary: Docker's overlay uses its own VXLAN control plane tightly coupled to the Docker daemon. Kubernetes CNI plugins are modular — any plugin implementing the CNI spec can manage networking (Flannel, Calico, Cilium, Weave). CNI plugins have richer policy support, eBPF options, and are decoupled from the container runtime.
Permalink
Q132:

What is an OCI image manifest and how does Docker validate it?

Expert

Answer

Manifest lists layers and digests; Docker verifies SHA256 digests before extraction to detect tampering.
Quick Summary: An OCI image manifest is a JSON document listing the image's config blob and all layer descriptors (digest + size). Docker computes the SHA256 of each downloaded blob and compares it against the manifest. If any digest mismatches, the pull fails immediately. The manifest itself is signed in trusted registries using Notary.
Permalink
Q133:

What causes multi-arch images to pull the wrong architecture occasionally?

Expert

Answer

Faulty manifest lists or CI misconfiguration lead clients to select incorrect architecture entries.
Quick Summary: Multi-arch images use a manifest list. If the registry or client has a bug in platform matching, it might resolve the manifest list to the wrong architecture. Also, if an image was pushed without a proper manifest list (just tagged with the wrong architecture label), Docker silently pulls and runs the wrong binary.
Permalink
Q134:

Why do Docker layers become unshareable across images even if identical?

Expert

Answer

Layer digests depend on metadata like timestamps and file order; differing metadata prevents sharing.
Quick Summary: Two images with identical layers (same files) would ideally share those layers. But if they were built separately with different build contexts or slightly different ordering, even identical-content layers get different SHA256 hashes due to metadata differences in the layer tar archive. Docker can only share layers with bit-for-bit identical tarballs.
Permalink
Q135:

How does buildx leverage BuildKit to execute builds in DAG form?

Expert

Answer

BuildKit builds a dependency graph, parallelizes stages, and caches keyed intermediate states.
Quick Summary: BuildKit models a Dockerfile as a DAG (Directed Acyclic Graph) of build steps. Independent steps (multiple COPY from different stages) run in parallel. buildx extends this to run DAG stages on multiple build nodes simultaneously — cross-platform builds run each architecture's stages in parallel, dramatically cutting multi-arch build time.
Permalink
Q136:

Why do Docker push and pull operations feel slow even for small layer files?

Expert

Answer

Registry communication involves multiple API calls and digest checks causing high latency.
Quick Summary: Docker push/pull transfers individual layer tarballs sequentially or in small batches. Network round-trips for manifest lookups, layer existence checks (HEAD requests), and actual data transfer all add up. Even a 50MB layer takes multiple round-trips. Content-delivery networks and regional registry mirrors cut pull times significantly.
Permalink
Q137:

How does Docker prevent cross-repo layer caching attacks in registries?

Expert

Answer

Layer digests require repo-scoped authorization; knowing a digest is not enough to download.
Quick Summary: A malicious image could include a layer that's identical (same SHA256) to a popular base image layer. If the registry allowed shared layers across repos, one user could trick another into trusting modified content. Registries use per-repository blob storage and validate that layers belong to the repo that uploaded them.
Permalink
Q138:

Why can Docker logging drivers cause kernel buffer pressure?

Expert

Answer

High log throughput stresses buffers, causing IO throttling, CPU spikes, and dropped logs.
Quick Summary: Docker log drivers (json-file, syslog, journald) write log data to kernel buffers. If the logging backend can't consume logs fast enough, kernel buffers fill up. Backpressure propagates to the container's write() calls — the app blocks on logging. In extreme cases this stalls the entire container, making it appear hung.
Permalink
Q139:

How are checkpoint and restore used for live migration?

Expert

Answer

CRIU saves process state, TCP sessions, and memory; Docker restores it on another host.
Quick Summary: CRIU (Checkpoint/Restore In Userspace) freezes a running container, captures its full memory state and process tree to disk, then restores it on another host. Docker supports experimental CRIU integration for container live migration. It's used for zero-downtime maintenance, workload migration, and speeding up slow startup apps.
Permalink
Q140:

What conditions cause CRIU checkpointing to fail?

Expert

Answer

Uncheckpointable operations like ptrace, inotify, special FDs, or kernel mismatches cause failure.
Quick Summary: CRIU fails when containers use kernel features it can't serialize: open network connections (TCP state is hard to migrate), GPU memory, kernel objects without CRIU support, or processes with kernel threads. Some syscalls are non-restartable. Containers using host networking or --privileged are also problematic for CRIU.
Permalink
Q141:

What is the attack surface of Docker’s network namespace sandboxing?

Expert

Answer

Misconfigured capabilities like CAP_NET_ADMIN allow route manipulation or packet sniffing.
Quick Summary: Docker uses separate network namespaces per container, but they share the host kernel's networking stack. Vulnerabilities in the host kernel's network code (iptables, VXLAN driver) can cross namespace boundaries. VXLAN traffic is unencrypted by default — an attacker on the same L2 network can sniff overlay traffic between containers.
Permalink
Q142:

How does Docker implement deterministic CPU throttling across containers?

Expert

Answer

cgroups v2 applies weighted fair sharing using quotas and CPU weights.
Quick Summary: Docker uses the cpu.cfs_period_us and cpu.cfs_quota_us cgroup parameters to implement CPU throttling using the Completely Fair Scheduler (CFS). A container with --cpus=0.5 gets 50ms of CPU time per 100ms period. This is deterministic and enforced by the kernel regardless of host CPU load.
Permalink
Q143:

How do registries deduplicate identical layers across millions of images?

Expert

Answer

Content-addressing stores each digest once and tracks references to avoid duplication.
Quick Summary: Registries use content-addressable storage: layers are stored by their SHA256 digest globally. When two images share an identical layer, only one copy is stored — any image manifest can reference it by digest. This massively reduces storage for large registries (like Docker Hub) where many images share the same base layers.
Permalink
Q144:

Why does Docker fail to garbage-collect layers sometimes?

Expert

Answer

Running or stopped containers still reference layers until removed.
Quick Summary: Docker's GC skips layers still referenced by any image manifest or build cache entry. If a manifest or BuildKit cache entry is corrupted or not properly cleaned up, it holds a reference forever — the layer is never collected. Clearing the build cache (docker builder prune) and dangling images usually resolves stuck GC.
Permalink
Q145:

How do kernel security modules secure Docker collectively?

Expert

Answer

AppArmor/SELinux enforce MAC, Seccomp filters syscalls, and capabilities reduce privileges.
Quick Summary: AppArmor restricts filesystem access, network operations, and capabilities via profiles. SELinux uses type enforcement labels — every process and file has a label, and policy defines allowed interactions. Seccomp filters system calls. Used together (AppArmor + seccomp OR SELinux + seccomp), they provide defense-in-depth beyond namespace isolation.
Permalink
Q146:

Why is host kernel version critical for Docker performance and security?

Expert

Answer

Kernel defines namespaces, cgroups, OverlayFS, eBPF, and seccomp features.
Quick Summary: Docker containers share the host kernel — there's no hypervisor between them. A kernel vulnerability (privilege escalation, namespace escape) affects all containers on that host. Newer kernel features (cgroups v2, eBPF, user namespaces) provide better isolation. Keeping the host kernel patched is critical for container security.
Permalink
Q147:

Why does running systemd inside Docker break container assumptions?

Expert

Answer

systemd expects full init control and multiple processes, conflicting with container isolation.
Quick Summary: systemd expects to be PID 1 with full access to cgroups, D-Bus, and systemd-specific kernel interfaces. Containers restrict all of these — no cgroup write access, no D-Bus, limited capabilities. systemd inside a container needs --privileged to work at all, which defeats container isolation. Use supervisord or tini instead for multi-process containers.
Permalink
Q148:

How do multi-tenant platforms prevent noisy-neighbor problems?

Expert

Answer

Strict CPU, memory, IO limits and cgroup throttling isolate resource usage.
Quick Summary: Noisy-neighbor prevention uses cgroups limits (CPU, memory, I/O) to cap each tenant's resource usage. Separate namespaces prevent process and network visibility. Separate Docker networks enforce traffic isolation. At the platform level, containers are scheduled on separate nodes or NUMA domains for the most sensitive tenants.
Permalink
Q149:

How does Docker isolate high-resolution timers?

Expert

Answer

Time namespaces provide isolated clocks preventing timing attacks.
Quick Summary: By default, containers share the host's clock and can read high-resolution timers. Docker doesn't expose a timer namespace (it's a newer kernel feature). A container can observe timing information useful for side-channel attacks (Spectre-class). Some hardened environments mount a fake /proc/timer_list to prevent this.
Permalink
Q150:

Why is Docker used with immutable infrastructure principles?

Expert

Answer

Containers are stateless and replaceable, minimizing configuration drift.
Quick Summary: Immutable infrastructure means servers are never modified after deployment — if you need a change, you build a new image and replace containers, never ssh in and patch. Docker makes this natural: images are versioned, containers are ephemeral, rollbacks are just pulling the previous image. State lives in external volumes or databases.
Permalink
Q151:

Why is image attestation important in enterprise pipelines?

Expert

Answer

Attestation proves who built the image and ensures supply-chain integrity.
Quick Summary: Image attestation is a signed statement (using Sigstore/cosign) proving an image was built from a specific source commit, by a specific CI pipeline, with a verified build process. It lets you verify supply chain integrity — not just that the image hash matches, but that it was built correctly and wasn't tampered with post-build.
Permalink
Q152:

How does Docker’s network sandbox interact with eBPF plugins like Cilium?

Expert

Answer

eBPF replaces iptables for fast packet filtering and direct routing.
Quick Summary: Docker's network sandbox creates a network namespace for each container. eBPF-based CNI plugins like Cilium attach eBPF programs to the veth interfaces at the namespace boundary, intercepting packets as they enter/leave. Cilium can enforce L7 policies (HTTP path filtering), collect observability metrics, and replace iptables entirely.
Permalink
Q153:

Why did orchestrators shift from Docker runtime to containerd and CRI?

Expert

Answer

containerd provides slim, fast, Kubernetes-native runtime integration.
Quick Summary: Docker's runtime (originally dockerd → runc) was tightly coupled. Kubernetes standardized the Container Runtime Interface (CRI), allowing any CRI-compliant runtime. containerd (Docker's own) and CRI-O emerged as lighter, purpose-built runtimes for Kubernetes — no docker CLI overhead, just the container lifecycle management Kubernetes needs.
Permalink
Q154:

How does Docker optimize overlay networks without full mesh tunnels?

Expert

Answer

Swarm uses gossip plus VXLAN mapping to create tunnels only when needed.
Quick Summary: Docker overlay uses VXLAN in multicast or unicast mode. For large clusters, full mesh unicast VXLAN tunnels between every pair of nodes scale as O(n²). Modern solutions use BGP EVPN to distribute MAC/IP mappings, eliminating the need for full mesh tunnels. Cilium replaces VXLAN entirely with direct routing using eBPF.
Permalink
Q155:

What causes fsync storms inside containers?

Expert

Answer

OverlayFS merges layers, causing heavy IO waits and slow database transactions.
Quick Summary: fsync storms happen when many processes inside a container simultaneously flush data to disk (database checkpoints, log rotation, package installs). The container's writes go through OverlayFS and the host filesystem — fsync calls queue up, saturating I/O. Databases inside containers need direct volume access, not the overlay filesystem, to avoid this.
Permalink

Curated Sets for Docker

No curated sets yet. Group questions into collections from the admin panel to feature them here.

People Also Ask - Related Docker Questions

What problem does Docker solve compared to traditional application deployments?
How is a Docker container different from a virtual machine?
What is a Docker image?
What is the role of a Dockerfile?
What does the FROM instruction do in a Dockerfile?
Why do Docker images contain multiple layers?
Ready to level up? Start Practice