Docker Interview Questions

Docker is an open-source platform for building, shipping, and running applications in containers. It solves the "works on my machine" problem by packaging an application with all its dependencies (runtime, libraries, config) into a portable unit that runs identically on any Docker-enabled host.

A VM includes a full guest OS with its own kernel, running on a hypervisor. A container shares the host OS kernel and isolates the application at the process level using Linux namespaces and cgroups. Containers are lighter (MBs vs GBs), start faster (seconds vs minutes), and more resource-efficient (100s per host vs ~10 VMs).

A Docker image is a read-only, layered template containing application code, runtime, system tools, libraries, and settings. Images are built from a Dockerfile and stored in a registry. Each instruction in the Dockerfile creates a new layer. Images are identified by repository:tag (e.g., python:3.12-slim).

A container is a running instance of an image. It adds a thin writable layer on top of the image's read-only layers. Multiple containers can share the same image. Containers are isolated processes with their own filesystem, network interface, and process tree, but they share the host kernel.

Each Dockerfile instruction creates a layer. Layers are read-only and cached. If a layer hasn't changed, Docker reuses it on the next build (cache hit). Multiple images can share base layers, saving disk space. This makes builds fast and storage efficient. Only the container's writable layer is unique per container.

Namespaces provide isolation: PID (process IDs), NET (networking), MNT (filesystem), UTS (hostname), IPC (inter-process communication), and USER (user IDs). Each container sees its own isolated view. Cgroups (control groups) limit and account for resource usage (CPU, memory, disk I/O). Together, they make containers lightweight and isolated.

The Docker daemon (dockerd) is a background service that manages Docker objects (images, containers, networks, volumes). The Docker CLI (docker) communicates with the daemon via a REST API. The daemon handles building images, running containers, and managing storage. It runs with root privileges, which is why rootless mode exists for security.

A Dockerfile is a text file containing instructions to build a Docker image. Each instruction (FROM, RUN, COPY, CMD) creates a layer. Docker reads it top-to-bottom, caching layers that haven't changed.

CMD provides a default command that can be overridden at runtime. ENTRYPOINT sets a fixed executable — runtime arguments are appended to it. Best practice: use ENTRYPOINT for the main executable and CMD for default arguments: ENTRYPOINT ["python"] + CMD ["app.py"].

COPY copies files from host to image — straightforward and predictable. ADD does the same but also supports URLs and auto-extracts tar archives. Best practice: always use COPY unless you specifically need tar extraction. ADD can introduce unexpected behavior.

Docker caches each layer. If an instruction and its inputs haven't changed, the cached layer is reused. When a layer changes, all subsequent layers are invalidated. Optimize by: 1) Putting rarely-changing instructions first (OS packages, dependencies). 2) Copying dependency files before source code. 3) Combining related RUN commands.

Multi-stage builds use multiple FROM instructions. You build in a "fat" stage with compilers and tools, then COPY --from=builder only the compiled output to a minimal final stage. This keeps build tools out of the production image, reducing size dramatically (e.g., Go: 1.2 GB → 12 MB with alpine).

.dockerignore specifies files excluded from the build context (the files sent to the Docker daemon). It prevents secrets (.env), large directories (.git, node_modules), and irrelevant files from entering the image. It speeds up builds and avoids leaking sensitive data.

bridge (default): single-host container-to-container. host: container shares host's network stack (no isolation, max performance). none: no networking. overlay: multi-host networking for Docker Swarm. macvlan: assigns a MAC address, making the container appear as a physical device on the network.

On a custom bridge network, containers communicate by container name. Docker runs an embedded DNS server that resolves names to IPs. On the default bridge, you must use IP addresses or --link (deprecated). For multi-host, use overlay networks or external service discovery.

EXPOSE is documentation only — it tells users which port the app listens on but doesn't actually open it. Publishing (-p 8080:80 or ports: in Compose) maps a host port to a container port, making the service accessible from outside. You need both: EXPOSE for documentation and -p for access.

Custom bridge networks provide: 1) Automatic DNS resolution by container name (the default bridge doesn't). 2) Better isolation — only containers on the same custom network can communicate. 3) Connect/disconnect at runtime without restarting containers.

Data stored in the container's writable layer is lost when the container is removed (docker rm). To persist data, use volumes (managed by Docker) or bind mounts (host directory). Volumes survive container removal and can be shared between containers.

Volumes: Managed by Docker, stored in /var/lib/docker/volumes/. Best for production data. Bind mounts: Map a specific host path into the container. Best for development (live code reload). tmpfs: Stored in memory only, never written to disk. Best for sensitive temp data (tokens, session files).

Use a named volume mounted into multiple containers. Example: docker run -v shared-data:/data container1 and docker run -v shared-data:/data container2. Both containers read and write to the same volume. Be careful with concurrent writes — use application-level locking if needed.

Run a temporary container that mounts the volume and a host directory, then tar the data: docker run --rm -v my-vol:/data -v $(pwd):/backup alpine tar czf /backup/backup.tar.gz /data. To restore: docker run --rm -v my-vol:/data -v $(pwd):/backup alpine tar xzf /backup/backup.tar.gz -C /.

Docker Compose is a tool for defining and running multi-container applications with a YAML file. Use it when your app needs multiple services (API + database + cache). One docker compose up command starts everything with proper networking, volumes, and dependency ordering.

depends_on controls startup order only. It does NOT guarantee the service is ready to accept connections. To wait for readiness, use depends_on with condition: service_healthy and define a healthcheck on the dependency. Your application should also implement connection retry logic.

Use file merging: compose.yaml (base config) + compose.override.yaml (auto-merged for dev) + compose.prod.yaml (explicit for prod via -f). Each file adds or overrides settings. Alternatively, use .env files with variable substitution: image: myapp:${TAG:-latest}.

exec runs a command in an existing, running container. run creates a new container from the service definition for a one-off command. Use exec for debugging a live service. Use run --rm for tasks like migrations, seed scripts, or running tests.

Compose: local development, CI/CD, small deployments, single-host. Simple, fast to set up. Kubernetes: production at scale, multi-host orchestration, auto-scaling, self-healing, rolling updates, service mesh. Compose for simplicity, K8s for scale and reliability.

If a container runs as root and an attacker exploits a vulnerability, they get root access inside the container. Combined with a kernel exploit, this could mean root on the host. Running as non-root (USER appuser) limits the blast radius. Use RUN groupadd/useradd in Dockerfiles.

Never put secrets in Dockerfiles or images. Options: 1) Environment variables at runtime (docker run -e SECRET=...). 2) Docker secrets (Swarm mode): mounted as files in /run/secrets/. 3) External secrets manager (Vault, AWS Secrets Manager). 4) .env files not committed to git.

Use docker scout cves <image> (built-in) or third-party tools like Trivy, Snyk, or Grype. Integrate scanning into CI/CD to catch CVEs before deployment. Also: use minimal base images (-slim, alpine, distroless) to reduce attack surface, and rebuild images regularly to pick up security patches.

DCT uses digital signatures to verify the integrity and publisher of images. When enabled (DOCKER_CONTENT_TRUST=1), Docker only pulls signed images. Publishers sign images with their private key; consumers verify with the public key. This prevents pulling tampered or malicious images.

1) docker stats for real-time CPU/memory/network. 2) Healthchecks in Dockerfile/Compose for service-level monitoring. 3) Centralized logging with Fluentd/Logstash + ELK or cloud providers. 4) Metrics with Prometheus + Grafana using cAdvisor for container metrics. 5) Container orchestrators (K8s) add pod-level monitoring.

1) docker logs <container> to check error output. 2) docker inspect <container> to see exit code and state. 3) Run interactively: docker run -it <image> bash to debug inside. 4) Check if it's an OOM kill: docker inspect shows OOMKilled: true. 5) Check resource limits, healthcheck config, and restart policy.

1) Use a reverse proxy (Nginx, Traefik) with multiple backend containers. 2) Start new container with updated image. 3) Wait for healthcheck to pass. 4) Route traffic to new container. 5) Drain and stop old container. Kubernetes automates this with rolling updates. Docker Swarm has built-in rolling update support.

docker system prune removes stopped containers, unused networks, dangling images, and build cache. Add -a to also remove all unused images (not just dangling). Add --volumes to include unused volumes. Schedule this in production to prevent disk space exhaustion.

docker stop sends SIGTERM first, giving the process time to gracefully shut down (close connections, flush data). After a timeout (default 10s), it sends SIGKILL. docker kill sends SIGKILL immediately — no graceful shutdown. Always prefer stop unless the container is unresponsive.

Logging drivers control where container logs go. json-file (default): writes JSON to host filesystem. syslog: sends to syslog daemon. fluentd: sends to Fluentd collector. awslogs: sends to CloudWatch. none: disables logging. Configure per container or globally in /etc/docker/daemon.json.