Prepare for Docker interviews with 40+ questions on containers, images, networking, and best practices.
10 Questions
~30 min read
Image is a read-only template with application code, runtime, libraries, and dependencies. Container is a running instance of an image - it adds a writable layer on top. Multiple containers can run from same image. Images are built from Dockerfiles and stored in registries. Containers are ephemeral; data persists only with volumes or bind mounts.
Each Dockerfile instruction creates a layer. Layers are cached and reused across images. Read-only layers are shared; containers add writable layer on top. Order instructions: less-changing first (dependencies) then frequently-changing (code). Use multi-stage builds to reduce final image size. Combine RUN commands to reduce layers.
Multi-stage builds use multiple FROM statements. Build application in one stage with build tools, copy only artifacts to final stage with minimal runtime. Benefits: smaller images (no build tools), faster deployment, reduced attack surface. Example: build in node:18, copy to node:18-alpine. Each stage can use different base image.
Network drivers: (1) bridge (default) - isolated network, NAT to host, (2) host - shares host network stack, no isolation, (3) none - no networking, (4) overlay - multi-host networking for Swarm/Kubernetes, (5) macvlan - assign MAC address, appear as physical device. Use bridge for single-host; overlay for multi-host clusters.
Options: (1) Volumes - managed by Docker, stored in /var/lib/docker/volumes, best for persistence, (2) Bind mounts - map host directory, good for development, (3) tmpfs - in-memory, temporary. Volumes survive container removal; preferred for databases. Use volume drivers for cloud storage (AWS EBS, etc.). Name volumes for easy management.
Docker Compose defines multi-container applications in YAML. Manages: services, networks, volumes. Commands: up, down, build, logs, exec. Use cases: local development environments, testing, CI/CD pipelines. Features: environment variables, dependency ordering (depends_on), health checks, scaling. Not for production orchestration (use Kubernetes/Swarm).
Strategies: (1) Use minimal base images (alpine, distroless), (2) Multi-stage builds, (3) Combine RUN commands, (4) Use .dockerignore, (5) Order layers by change frequency, (6) Don't install unnecessary packages, (7) Clean up in same layer (apt clean), (8) Use specific tags, not latest, (9) Scan for vulnerabilities, (10) Run as non-root user.
COPY: simply copies files/directories from build context to image. ADD: also supports URL downloads and auto-extracts tar archives. Best practice: use COPY for most cases (explicit, predictable). Use ADD only when you need tar extraction. Avoid ADD for URLs (use curl/wget for better error handling and caching).
ENTRYPOINT: main command that always runs. CMD: default arguments to ENTRYPOINT or default command. CMD can be overridden at runtime; ENTRYPOINT cannot (without --entrypoint). Patterns: (1) ENTRYPOINT for executable containers, (2) CMD for default command that users might override. Combine: ENTRYPOINT ["python"] CMD ["app.py"] - user can replace app.py.
Security features: (1) Namespaces - process/network isolation, (2) Cgroups - resource limits, (3) Seccomp - syscall filtering, (4) AppArmor/SELinux - MAC, (5) Capabilities - fine-grained root powers. Best practices: don't run as root, use read-only filesystem, scan images, use trusted base images, limit resources, no privileged mode unless necessary.