Docker Interview Questions

Both copy files into the image, but ADD has extra functionality that makes it unpredictable:

• ADD can fetch files from a URL
• ADD auto-extracts tar archives into the destination

Best practice: Always use COPY unless you specifically need the URL or auto-extraction features. COPY is explicit and predictable, which is better for reproducible builds.

CMD provides default arguments for the container. It can be overridden by passing arguments to docker run.

ENTRYPOINT defines the fixed command that always runs. It cannot be overridden without --entrypoint flag.

Best practice: Use ENTRYPOINT for the executable and CMD for default arguments, making the container behave like a command-line tool:

ENTRYPOINT ["python", "app.py"]
CMD ["--port", "8080"]
# docker run myapp --port 9090  ← overrides CMD only

A Docker image is a read-only template built from a Dockerfile. Think of it as a class definition. A container is a running instance of that image — a class instantiation. You can run many containers from the same image, each isolated from the others.

# Build an image
docker build -t my-app:1.0 .

# Run a container from that image
docker run -d -p 8080:80 my-app:1.0

A distroless image contains only your application and its runtime dependencies — no shell, no package manager, no OS utilities. This comes from Google’s distroless project.

Security benefits: You cannot exec into a distroless container and run arbitrary commands. The attack surface is dramatically reduced because there are no standard Unix tools an attacker could use to move laterally.

# Distroless multi-stage example
FROM golang:1.22 AS builder
WORKDIR /app
COPY . .
RUN CGO_ENABLED=0 go build -o server .

FROM gcr.io/distroless/static-debian12
COPY --from=builder /app/server /server
CMD ["/server"]

Image size directly affects pull times and attack surface. Key strategies:

1. Use minimal base images: alpine or distroless instead of ubuntu.
2. Multi-stage builds: Build in a full image, copy only the binary/artifact to a slim final image.
3. Combine RUN commands: Each RUN creates a layer. Chain commands with && and clean up in the same layer.
4. Use .dockerignore: Exclude node_modules, .git, test files from the build context.

# Multi-stage example
FROM node:20 AS builder
WORKDIR /app
COPY . .
RUN npm ci && npm run build

FROM node:20-alpine
WORKDIR /app
COPY --from=builder /app/dist ./dist
CMD ["node", "dist/index.js"]

The HEALTHCHECK instruction tells Docker how to test if a container is working correctly. Without it, Docker considers a container healthy as soon as the process starts — even if the app inside has crashed.

HEALTHCHECK --interval=30s --timeout=10s --start-period=5s --retries=3 \
  CMD curl -f http://localhost:8080/health || exit 1

In Kubernetes, this is replaced by Liveness and Readiness probes. In Docker Compose or standalone Docker, HEALTHCHECK is critical for orchestration tools to know whether to send traffic to a container.

Running containers as root is a significant security risk. If an attacker escapes the container, they have root on the host. Harden your images:

FROM node:20-alpine

# Create a non-root user
RUN addgroup -S appgroup && adduser -S appuser -G appgroup

# Set working directory and permissions
WORKDIR /app
COPY --chown=appuser:appgroup . .

# Switch to non-root user
USER appuser

CMD ["node", "index.js"]

Also enforce this at the Kubernetes level with a SecurityContext: runAsNonRoot: true.

Docker provides several networking modes (drivers) that control how containers communicate with each other and the outside world.

Network Modes Overview

1. Bridge (Default)

Containers on the same bridge network can communicate via IP or container name. Containers are isolated from the host network.

# Default bridge (docker0)
docker run -d --name web nginx

# Custom bridge network (recommended)
docker network create mynet
docker run -d --name web --network mynet nginx
docker run -d --name app --network mynet myapp
# 'app' can reach 'web' by hostname 'web'

Use when: Most container-to-container communication within a single host.

2. Host

Container shares the host’s network namespace. No network isolation, maximum performance.

docker run -d --network host nginx
# Now nginx listens on host's port 80 directly

Use when: High-performance networking, network monitoring tools, when you need host-level network access. Not available on Mac/Windows Docker Desktop.

3. None

Container has no network interface (only loopback). Complete network isolation.

docker run -d --network none myapp

Use when: Batch processing jobs that don’t need network access, maximum security isolation.

4. Overlay

Enables communication between containers on different Docker hosts. Used with Docker Swarm.

docker network create --driver overlay myoverlay

Use when: Multi-host deployments, Docker Swarm services that span multiple nodes.

5. Macvlan

Assigns a MAC address to a container, making it appear as a physical device on the network.

docker network create -d macvlan \
  --subnet=192.168.1.0/24 \
  --gateway=192.168.1.1 \
  -o parent=eth0 mymacvlan

Use when: Legacy applications that expect to be directly connected to the physical network, network monitoring.

6. IPvlan

Similar to Macvlan but containers share the host’s MAC address.

Use when: When MAC address proliferation is a concern on the network switch.

Comparison

Best Practice

Always use custom bridge networks over the default bridge. Custom networks provide:

• Automatic DNS resolution by container name
• Better isolation
• Dynamic connect/disconnect of containers

Multi-stage builds allow you to use multiple FROM statements in a Dockerfile, enabling you to use a large build image for compilation while producing a minimal final image.

The Problem Without Multi-Stage Builds

Traditionally, developers would need separate Dockerfiles for development and production:

• Development: Includes SDK, build tools, test dependencies
• Production: Should only contain the runtime artifact

Result: Large production images with unnecessary build tools, larger attack surface, slower deployments.

How Multi-Stage Builds Work

Each FROM instruction starts a new build stage. You can selectively copy artifacts from one stage to another, leaving behind everything you don’t need.

Example: Go Application

# Stage 1: Build
FROM golang:1.21 AS builder
WORKDIR /app
COPY go.mod go.sum ./
RUN go mod download
COPY . .
RUN CGO_ENABLED=0 GOOS=linux go build -o main .

# Stage 2: Production
FROM scratch
COPY --from=builder /app/main /main
COPY --from=builder /app/certs /etc/ssl/certs
EXPOSE 8080
CMD ["/main"]

Result: Builder image ~800MB → Production image ~10MB

Example: Node.js Application

# Stage 1: Dependencies
FROM node:20-alpine AS deps
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production

# Stage 2: Build
FROM node:20-alpine AS build
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build

# Stage 3: Production
FROM node:20-alpine
WORKDIR /app
COPY --from=deps /app/node_modules ./node_modules
COPY --from=build /app/dist ./dist
CMD ["node", "dist/server.js"]

Targeting Specific Stages

# Build only up to a specific stage (useful for testing)
docker build --target builder -t myapp:builder .

# Build the final production image
docker build -t myapp:latest .

Benefits

• Smaller images: Only production artifacts in final image
• Better security: No compilers, debuggers, or dev tools in production
• Single Dockerfile: No need to maintain separate dev/prod Dockerfiles
• Improved caching: Each stage caches independently
• Faster CI: Parallel stages with BuildKit

Docker Compose is a tool for defining and running multi-container applications using a YAML file. It is ideal for local development and testing where you need to spin up interdependent services (app + database + cache) with a single command.

docker compose up -d

It handles networking (all services in the same file can reach each other by service name), volume management, and environment variables. For production orchestration, use Kubernetes instead.

Docker Volumes are managed by Docker, stored in /var/lib/docker/volumes/, and are the recommended way to persist data. They are portable, easy to back up, and work well with Docker Compose.

Bind Mounts map a specific host path directly into the container. They are useful in development to sync source code in real-time but are host-dependent and harder to manage in production.

# Volume (recommended for production)
docker run -v mydata:/app/data myapp

# Bind mount (recommended for development)
docker run -v $(pwd)/src:/app/src myapp

Docker builds images layer by layer. If a layer hasn’t changed since the last build, Docker reuses the cached version. The trick is layer ordering:

Bad: COPY all files first, then run npm install. Any code change invalidates the npm install cache.

Good: COPY package.json first, run npm install, then COPY the rest of the source. Dependency installation only re-runs when package.json changes.

# Optimized layer order
COPY package.json package-lock.json ./
RUN npm ci
COPY . .
RUN npm run build

Image scanning should be a mandatory gate before pushing to production. Tools and integration steps:

• Trivy (Aqua): Fast, comprehensive, easy CI integration. trivy image myapp:latest
• Snyk: Deep dependency scanning with developer-friendly output.
• Docker Scout: Built into Docker Hub.
• Grype: From Anchore, works well with SBOM workflows.

# GitHub Actions example
- name: Scan image with Trivy
  uses: aquasecurity/trivy-action@master
  with:
    image-ref: myapp:${{ github.sha }}
    severity: CRITICAL,HIGH
    exit-code: 1  # Fail the pipeline on critical vulnerabilities

Dangling images are layers that have no associated tag — they appear as <none>:<none> in docker images. They accumulate over time from rebuilds and waste disk space.

# List dangling images
docker images -f dangling=true

# Remove all dangling images
docker image prune

# Nuclear option — remove all unused images, containers, networks, volumes
docker system prune -a --volumes

In CI/CD pipelines, always run docker system prune -f as a post-step to keep agents clean.