Docker Interview Questions for DevOps Engineers

4. What is a Dockerfile and what are its most important instructions?

A Dockerfile is a text-based script of instructions that Docker reads to assemble an image. The key instructions interviewers expect you to know are:

• FROM — sets the base image (e.g., FROM node:20-alpine)
• RUN — executes a command during the build phase to install packages or compile code
• COPY / ADD — copies files from the build context into the image; ADD can also handle URLs and tar extraction
• WORKDIR — sets the working directory for subsequent instructions
• EXPOSE — documents which port the container listens on (it does not actually publish the port)
• ENV — sets environment variables
• CMD / ENTRYPOINT — defines the default command to run; ENTRYPOINT is the executable, CMD provides default arguments

A senior candidate should also mention the importance of multi-stage builds to keep production images lean — a pattern heavily used at companies like Meta and Uber to reduce image sizes from hundreds of megabytes to under 20 MB.

Intermediate Docker Interview Questions

5. What are Docker volumes and when would you use them over bind mounts?

Docker volumes are managed by Docker and stored in a dedicated part of the host filesystem (/var/lib/docker/volumes/). They are the preferred mechanism for persisting data because they are portable, can be backed up easily, and work seamlessly across platforms. Bind mounts map a specific host directory into the container — useful during local development when you want live code reloading, but problematic in production because they depend on the host's directory structure. In a Kubernetes-backed production environment at a company like Airbnb, you would typically use volumes backed by persistent volume claims rather than bind mounts.

6. Explain Docker networking modes.

Docker provides several network drivers, each suited to different scenarios:

• bridge — the default mode; containers on the same bridge network can communicate; isolated from external networks unless ports are explicitly published
• host — the container shares the host's network stack directly; maximum performance but zero network isolation
• none — completely disables networking; useful for batch processing containers that require no network access
• overlay — enables communication between containers across multiple Docker hosts; the backbone of Docker Swarm networking
• macvlan — assigns a MAC address to the container so it appears as a physical device on the network; used in legacy application migration scenarios

Interviewers at cloud-native companies will often follow this up with: "How would you allow two containers on different custom bridge networks to communicate?" The answer involves connecting them to a shared network using docker network connect.

7. What is Docker Compose and how is it used in a DevOps workflow?

Docker Compose allows you to define and run multi-container applications using a single YAML file (docker-compose.yml). It is ubiquitous in local development environments and CI pipelines. A typical microservices setup might define a web service, a PostgreSQL database, a Redis cache, and an Nginx reverse proxy — all starting with a single docker compose up command. In a DevOps context, Compose is invaluable for spinning up integration test environments in GitHub Actions or GitLab CI pipelines. Companies like HashiCorp and Twilio use Compose extensively in their developer experience tooling to reduce onboarding time from days to hours.

8. How do you reduce Docker image size?

Image bloat is a real problem — large images slow down deployments and increase attack surface. Experienced DevOps engineers should articulate these strategies:

1. Use minimal base images like alpine, distroless, or scratch
2. Implement multi-stage builds so build-time dependencies (compilers, test frameworks) never reach the production image
3. Chain RUN commands with && to reduce the number of layers and clean up package manager caches in the same instruction
4. Use a .dockerignore file to exclude unnecessary files from the build context
5. Avoid installing unnecessary packages — use --no-install-recommends in apt-get calls

Advanced Docker Interview Questions for Senior DevOps Roles

9. How do you handle secrets in Docker?

This is where many candidates stumble. Hardcoding secrets in Dockerfiles or environment variables is a security anti-pattern — a mistake that has caused high-profile breaches. The correct approach depends on the orchestration layer: in Docker Swarm, you use docker secret create to store encrypted secrets that are mounted as in-memory files inside containers. In Kubernetes, you use Kubernetes Secrets (ideally sealed with tools like Sealed Secrets or backed by Vault). In standalone Docker contexts, external secret stores like HashiCorp Vault, AWS Secrets Manager, or Azure Key Vault are the gold standard. The key point to make in an interview: never bake secrets into an image layer, because image history is inspectable.

10. Explain the difference between CMD and ENTRYPOINT.

Both define what runs when a container starts, but they behave differently. ENTRYPOINT sets the fixed executable that will always run — it cannot be overridden by arguments passed to docker run. CMD provides default arguments to the entrypoint (or is the default command if no entrypoint is set), and these can be overridden at runtime. The most robust pattern for production images is to use ENTRYPOINT for the executable and CMD for default flags, allowing operators to customise behaviour without modifying the image. For example: ENTRYPOINT ["nginx"] and CMD ["-g", "daemon off;"].

11. What is Docker layer caching and how do you optimise it in CI/CD?

Layer caching is Docker's mechanism for reusing previously built layers when nothing has changed. Each instruction in a Dockerfile creates a new layer; if the instruction and its context are identical to a previous build, Docker reuses the cached layer. To maximise cache hits in a CI pipeline, order instructions from least to most frequently changing — copy dependency manifests (package.json, requirements.txt) and install dependencies before copying application code. This way, a code change does not invalidate the dependency installation layer. In GitHub Actions, you can persist the Docker build cache across runs using cache-from and cache-to with the gha backend or by pushing cache layers to a registry like Amazon ECR.

12. How do you monitor and troubleshoot a running Docker container?

Interviewers want to know you can operate in production, not just build images. Key commands and approaches include:

• docker logs <container> — stream stdout/stderr; use --tail and --follow flags for live tailing
• docker inspect <container> — outputs detailed JSON metadata about the container's configuration, network settings, and mounts
• docker stats — live resource usage metrics (CPU, memory, network I/O, block I/O)
• docker exec -it <container> /bin/sh — opens an interactive shell inside a running container for ad-hoc debugging
• For production-grade observability, containers should export metrics to Prometheus and logs to a centralised aggregator like Elasticsearch via Fluentd or the Loki stack

Scenario-Based and Behavioural Docker Questions

Senior DevOps interviews at companies like Cloudflare, Datadog, or PagerDuty typically include open-ended scenario questions designed to test systems thinking rather than memorised answers.

13. "Our container keeps crashing in production — walk me through your debugging process."

A strong answer follows a structured runbook: first, check docker ps -a to confirm the exit code — a non-zero exit code tells you whether the crash was an OOM kill (exit 137), an application error, or a missing entrypoint. Then inspect logs with docker logs. If the container exits too fast to inspect, use --restart=no and override the entrypoint with a shell command to keep it alive for investigation. Check resource limits — OOM kills are common when memory limits are set too tightly. Finally, review the Dockerfile for issues like missing dependencies or wrong file permissions.

14. How would you implement a zero-downtime deployment with Docker?

This question tests your understanding of orchestration. With Docker Swarm, you use rolling updates via docker service update --update-parallelism 1 --update-delay 10s, which replaces containers one at a time. In a Kubernetes environment (the more common production answer), rolling deployments are native via Deployment resources, with readiness probes ensuring traffic only routes to healthy new pods. For standalone Docker hosts, a common pattern is a blue-green deployment behind an Nginx or Traefik reverse proxy — spin up new containers, run health checks, then update the proxy upstream and tear down old containers.

Make sure your resume reflects this kind of orchestration experience clearly. You can extract job keywords from the job description you are targeting to ensure your Docker and container orchestration experience aligns with what ATS systems and hiring managers are scanning for.

Docker Compose Deep-Dive Questions

15. What is the difference between depends_on and healthcheck in Docker Compose?

depends_on controls startup order — it ensures one service starts before another. However, it only waits for the container to start, not for the application inside it to be ready. This is a common source of race conditions, for example, a web app starting before its database is ready to accept connections. healthcheck, combined with condition: service_healthy in the depends_on block (available in Compose v3.9+), solves this by waiting until the dependency passes its health check before starting the dependent service. Knowing this distinction demonstrates production-level Compose experience.

16. How do you manage environment-specific configuration in Docker Compose?

Production-grade Compose setups use multiple override files: a base docker-compose.yml defines shared services, while docker-compose.override.yml adds development-specific settings (like bind mounts and debug flags), and a separate docker-compose.prod.yml adds production settings (resource limits, production registries). You merge them with docker compose -f docker-compose.yml -f docker-compose.prod.yml up. Environment variables are loaded from .env files, but sensitive values should always come from a secrets manager rather than committed dotfiles.

Preparing Your Application for Docker DevOps Interviews

Technical knowledge alone does not get you the offer. You need a resume that clearly communicates your containerization experience to both ATS systems and human reviewers. Use active, quantified language: not "worked with Docker" but "containerised a monolithic Node.js application into 12 microservices, reducing deployment time from 45 minutes to 8 minutes." Browse our collection of ATS resume templates designed specifically for DevOps and cloud engineering roles, with sections structured to highlight your infrastructure toolchain.

After your resume, you need a compelling cover letter that connects your Docker expertise to the specific company's engineering challenges. For a role at a cloud-native company, your cover letter should mention specific Docker patterns you have implemented in production — multi-stage builds, layer caching optimisation, secrets management — and relate them to the company's scale or tech stack.

Build your free ATS resume and make sure your Docker and DevOps experience stands out to every recruiter and hiring manager.

Quick Reference: Docker Commands Every DevOps Engineer Must Know

Interviewers will sometimes ask you to explain what a specific command does or to choose the right command for a given scenario. Make sure you are fluent with:

• docker build -t myapp:1.0 . — builds an image from the Dockerfile in the current directory
• docker run -d -p 8080:80 --name webserver nginx — runs a container in detached mode, mapping host port 8080 to container port 80
• docker image prune -a — removes all unused images to free disk space
• docker cp — copies files between a container and the host filesystem
• docker commit — creates an image from a running container (rarely recommended for production; Dockerfiles are always preferred)
• docker system df — shows disk usage by images, containers, and volumes
• docker buildx build --platform linux/amd64,linux/arm64 — builds multi-architecture images, essential for Apple Silicon development environments

Regional Considerations for Docker DevOps Interviews

While Docker knowledge is universal, there are regional differences in how interviews are conducted. In the United States, expect deep whiteboard-style system design questions where Docker is one component of a broader infrastructure discussion (e.g., "design a CI/CD pipeline for a microservices application"). In the United Kingdom and Australia, interviews tend to be more scenario-based and conversational, with emphasis on on-call experience and incident management using containerised workloads. In Canada, especially for roles at Shopify, Hootsuite, or financial technology firms in Toronto, expect questions that bridge Docker with Kubernetes and cloud-native tooling on AWS or GCP.

Regardless of geography, the trend is clear: Docker knowledge is now a minimum bar, not a differentiator. What differentiates strong candidates is demonstrating how Docker fits into a larger DevOps philosophy — immutable infrastructure, GitOps workflows, infrastructure as code, and continuous delivery pipelines that deploy containers reliably at scale.

Conclusion

Mastering Docker interview questions for DevOps roles requires more than memorising commands — it demands a deep understanding of containerization architecture, networking, security, and orchestration principles that you can apply to real production scenarios. Start with the foundational concepts, build confidence with intermediate topics like volumes and Compose, and then push into advanced territory with multi-stage builds, secrets management, and zero-downtime deployment strategies. Pair your technical preparation with a sharp, keyword-optimised resume that quantifies your container experience, and you will walk into any DevOps interview — whether at a Fortune 500 company or a high-growth startup — with genuine confidence.