10 Docker Interview Questions & Answers for DevOps & Cloud Engineers

First, A Quick Refresher: What Is Docker?#

Docker is a platform that runs your apps inside isolated little boxes called containers.

The magic part? A container behaves the same no matter where it runs. Your laptop, a test server, production, doesn’t matter. None of that “but it worked on my machine” drama. 😅

And in actual DevOps work, you’ll find it pretty much everywhere: app development, testing, CI/CD pipelines, cloud deployments. The whole pipeline, really.

Question 1: What’s the difference between an image and a container? And what happens if you delete the image?#

Okay so think of a Docker image as a frozen recipe for your app. It packs everything the app needs to run, code, libraries, environment settings, all of it.

A container is what shows up when Docker actually cooks that recipe. The recipe becomes a real dish, sizzling on the stove. 🍳

The image stays read-only and you can reuse it as many times as you want. The container, on the other hand, gets its own writable layer and runs as an isolated process. Here’s the fun bit interviewers love: delete the image while the container is already running, and the container just… keeps going. It doesn’t care, because the image already lives in memory.

But stop that container and try to start it back up? Now Docker goes looking for the image, can’t find it, and the restart fails. Womp.

🚀 Pro Tip:

Tag your images properly (my-app:latest, my-app:v1.2) and regularly prune unused ones — but avoid deleting images used by running containers.

Question 2: What actually happens when you run docker run?#

When I run docker run, the first thing Docker does is check whether the image is sitting on my machine already.

Nope? Then it pulls the image down from a registry like Docker Hub. After that it spins up a container, which is basically an isolated process with its very own filesystem, networking, and slice of resources.

The isolation itself comes from Linux namespaces and cgroups. That’s the secret sauce.

Then, last step, it fires off whatever default command the image was built to run.

📌 Example:

Running docker run nginx pulls the nginx image (if it’s not local), creates a container, and starts the Nginx server inside that isolated environment.

🚀 Pro Tip:

Use --rm with docker run to automatically clean up the container after it exits — so your system doesn’t get cluttered with stopped containers.

Question 3: COPY vs ADD — what’s the difference, and when would you use each?#

Both COPY and ADD move files into your image. So far, twins.

• COPY simply copies files and folders — no surprises.
• ADD does more: it can unpack compressed files like .tar.gz and download files from URLs.

That “extra” behavior from ADD is exactly why I keep my distance. It does things you didn’t always ask for, which makes Dockerfiles harder to read. I reach for COPY by default, and only bring in ADD when I genuinely need one of those tricks.

📌 Example:

1
# Preferred
2
COPY ./app /app
3

4
# Only if needed (auto-extracts)
5
ADD archive.tar.gz /app/

🚀 Pro Tip:

Simplicity is security — prefer COPY unless you have a very good reason.

Question 4: What’s a multi-stage build, and when would you use it?#

A multi-stage build just means you’ve got more than one FROM in your Dockerfile. Sounds fancy. It’s not, I promise.

• The first stage does heavy work — installing dependencies, building code.
• The final stage copies only the necessary artifacts into a clean, minimal base image.

The payoff is a lean image. All those build tools and temp files that production never needed? Gone. Left behind in the first stage where they belong.

📌 Example:

1
# Stage 1 — build
2
FROM node:20 AS builder
3
WORKDIR /app
4
COPY package*.json ./
5
RUN npm ci
6
COPY . .
7
RUN npm run build
8

9
# Stage 2 — production
10
FROM node:20-slim
11
WORKDIR /app
12
COPY --from=builder /app/dist ./dist
13
COPY --from=builder /app/node_modules ./node_modules
14
COPY --from=builder /app/package.json ./
15
CMD ["node", "dist/index.js"]

🚀 Pro Tip:

Smaller images = faster deployments + fewer vulnerabilities.

Question 5: CMD vs ENTRYPOINT — how do they work together?#

ENTRYPOINT is the thing that runs. Your main executable. The star of the show.

CMD hands it the default arguments.

Now the part people trip on. When you call docker run and pass your own arguments, those override CMD. ENTRYPOINT stays put.

Put them together and you’ve got a sensible default that you can still bend at runtime. Best of both, honestly.

📌 Example:

1
FROM nginx:1.28.0-alpine-slim
2

3
ENTRYPOINT ["nginx"]
4
CMD ["-g", "daemon off;"]

🚀 Pro Tip:

Want full control at runtime? Use only CMD — and leave out ENTRYPOINT.

Question 6: Volumes vs Bind Mounts — which would you use in production, and why?#

For production, I go with Docker-managed volumes every time. They stay tucked away from the host OS, they’re easy to back up, and they hold up nicely over the long haul.

Bind mounts lean on specific host paths. That makes them brittle, and very tied to one machine’s setup. They shine for local dev, though. Just keep them out of production, sis.

📌 Example:

1
services:
2
  db:
3
    image: postgres
4
    volumes:
5
      - pg-data:/var/lib/postgresql/data
6

7
volumes:
8
  pg-data:

🚀 Pro Tip:

Volumes are portable, reliable, and more future-proof across hosts and clusters.

Question 7: How does networking between containers work?#

Out of the box, Docker drops your containers onto a bridge network and hands each one a private IP.

Catch is, on that default network they can only find each other by IP. Not great. The fix is a user-defined bridge network.

On a user-defined bridge, containers can talk to each other by name. Suddenly service discovery just works, and your life gets so much easier. 💕

📌 Example:

1
services:
2
  app:
3
    image: my-app
4
    environment:
5
      DB_HOST: db
6
      DB_USER: appuser
7
      DB_PASSWORD: secret
8
    networks:
9
      - app-net
10

11
  db:
12
    image: postgres
13
    environment:
14
      POSTGRES_DB: mydb
15
      POSTGRES_USER: appuser
16
      POSTGRES_PASSWORD: secret
17
    networks:
18
      - app-net
19

20
networks:
21
  app-net:

🚀 Pro Tip:

Always use user-defined networks — the default bridge network doesn’t support automatic name-based discovery and can lead to frustrating connection issues.

Question 8: How do you reduce Docker image size, and why should you care?#

Smaller images build faster, deploy faster, and give attackers way less to chew on. Win, win, win.

• I start with a minimal base image — like alpine:3.21.3, python:3.12-slim-bookworm, or node:20.13.1-alpine.
• I combine RUN instructions to reduce layers, and clean up any temp files or caches.
• I always use a .dockerignore file to exclude things like .git, node_modules, and test data.

And when a build gets gnarly, multi-stage is my go-to. It keeps the build tools out of the final runtime, which is exactly where the bloat usually hides.

📌 Example:

A Node.js app image can shrink from 1.2 GB to under 200 MB by switching to node:20.13.1-alpine and cleaning up properly.

🚀 Pro Tip:

Smaller images = faster pipelines, quicker deploys, and fewer security issues.

Question 9: What is BuildKit, and why use it?#

BuildKit is Docker’s modern build engine, and it’s a serious step up for performance, security, and flexibility.

It runs independent build steps in parallel, caches way more cleverly, and handles secrets safely while building. It’ll also do multi-platform builds and manage storage efficiently. Lots packed in there.

Good news for most of us: on recent Docker versions BuildKit is already on by default, so there’s nothing to set up. Stuck on something older? You can still switch it on with DOCKER_BUILDKIT=1, or by tweaking the Docker daemon config.

📌 Example:

With BuildKit, multi-stage builds can run steps in parallel, reducing build times significantly.

🚀 Pro Tip:

Lean on BuildKit for builds that are faster, safer, and a whole lot more efficient.

Question 10: How do you handle sensitive data (like secrets) in Docker?#

Hardcoding secrets into Dockerfiles or images? Never. Not once. Don’t do it, darling.

For local runs I pass secrets in as environment variables, either inline or through a .env file. And if I use a .env file, it goes straight into .dockerignore so it never sneaks into the image by accident.

In production it’s a different game. I lean on proper secret managers, HashiCorp Vault, AWS Secrets Manager, or Kubernetes Secrets, and let them inject the secrets at runtime.

The rule is simple. Secrets live outside the image, never baked inside it.

📌 Example:

Pass database passwords using environment variables in staging, and HashiCorp Vault in production.

🚀 Pro Tip:

Good secret management = safer deployments and easier key rotations.

Thanks for reading! Be sure to watch the video version for extra insights and helpful visuals.