Docker & Kubernetes Interview Questions

Containers and orchestration come up in almost every modern DevOps interview. Interviewers want to know that you understand what a container actually is, how Docker builds and ships them, and how Kubernetes runs them at scale. This page walks through 12-18 common questions with clear, accurate answers and real commands you can run on Ubuntu 22.04 / 24.04 LTS. Read the prose first, then practice the commands on a real machine so the answers stick.

Containers and images basics

What is a container, and how is it different from a virtual machine (VM)?

A container is an isolated process running on your host operating system. It shares the host’s Linux kernel (the core of the OS) but has its own filesystem, network, and process space. A virtual machine instead emulates a whole computer, running a full guest operating system on top of a hypervisor (software that creates and runs VMs).

The key difference: containers share the host kernel, so they start in milliseconds and use very little memory. VMs boot a whole OS, so they are heavier but more strongly isolated.

Feature	Container	Virtual machine
Boots in	Milliseconds	Tens of seconds
Size	MBs	GBs
Isolation	Process-level (shared kernel)	Full hardware-level
Overhead	Very low	Higher
Use when	Microservices, CI/CD, packing many apps	Running different OS kernels, strong isolation

When to use which: Reach for containers when your apps run on Linux and you want density and speed. Use VMs when you need a different kernel (e.g. Windows on a Linux host) or hard security isolation between tenants.

What is a Docker image, and what are layers?

A Docker image is a read-only template that contains your application plus everything it needs to run: code, runtime, libraries, and config. A running container is just an image with a thin writable layer on top.

Images are built in layers. Each instruction in a Dockerfile (the build recipe) creates one layer, and layers are cached and reused. If you change a late instruction, only that layer and the ones after it rebuild. This makes builds fast and images small because shared layers are stored once.

What is the difference between an image and a container?

An image is the blueprint (on disk, immutable). A container is a running instance of that image (a live process with its own writable layer). You can start many containers from one image, just like many objects from one class.

docker run -d --name web1 nginx
docker run -d --name web2 nginx
docker ps

Output:

CONTAINER ID   IMAGE   COMMAND                  STATUS         PORTS     NAMES
a1b2c3d4e5f6   nginx   "/docker-entrypoint.…"   Up 3 seconds   80/tcp    web2
f6e5d4c3b2a1   nginx   "/docker-entrypoint.…"   Up 5 seconds   80/tcp    web1

Dockerfile and builds

What is a Dockerfile? Explain the common instructions.

A Dockerfile is a plain-text file with step-by-step instructions Docker uses to build an image.

Instruction	What it does
FROM	Sets the base image to start from
WORKDIR	Sets the working directory inside the image
COPY	Copies files from your machine into the image
RUN	Runs a command at build time (creates a layer)
EXPOSE	Documents which port the app listens on
CMD	Default command run when the container starts
ENTRYPOINT	The fixed executable the container runs

FROM node:20-alpine
WORKDIR /app
COPY package*.json ./
RUN npm ci --omit=dev
COPY . .
EXPOSE 3000
CMD ["node", "server.js"]

What is the difference between CMD and ENTRYPOINT?

ENTRYPOINT sets the executable that always runs. CMD sets default arguments that the user can override at docker run. A common pattern is ENTRYPOINT ["python"] with CMD ["app.py"], so docker run myimg other.py swaps the argument but keeps python.

What is a multi-stage build, and why use it?

A multi-stage build uses more than one FROM in a single Dockerfile. You build in a “heavy” stage (with compilers and dev tools), then copy only the finished artifact into a small final stage. The result is a tiny production image with no build tools inside.

Gotcha: Never copy secrets (like SSH keys or .env files) into an image layer. Layers are cached and shippable, so anyone with the image can extract them. Use build secrets or runtime environment variables instead.

Storage and networking

How do you persist data in Docker? What are volumes?

Containers are ephemeral (their writable layer disappears when removed). To keep data, use a volume (storage managed by Docker, living under /var/lib/docker/volumes) or a bind mount (a real host directory mounted into the container).

docker volume create pgdata
docker run -d --name db -v pgdata:/var/lib/postgresql/data postgres:16
docker volume ls

Output:

DRIVER    VOLUME NAME
local     pgdata

Use a volume for application data you want Docker to manage. Use a bind mount for source code during local development so edits show up instantly.

Explain Docker networking modes.

Mode	Behaviour	Use when
bridge	Default; private network, port mapping needed	Most single-host apps
host	Shares the host’s network directly	Need max network performance, no isolation
none	No networking at all	Fully isolated batch jobs
user-defined bridge	Custom network with DNS by name	Multi-container apps that talk to each other

On a user-defined bridge, containers can reach each other by name, which is why docker compose services find each other automatically.

Kubernetes objects

What is Kubernetes, and why use it?

Kubernetes (often shortened to K8s) is an open-source system for running containers across many machines. It handles scheduling (deciding where containers run), self-healing (restarting failed containers), scaling, and rolling updates. Use it when you have many containers across multiple servers; for a single server, docker compose is simpler.

What is a Pod?

A Pod is the smallest unit Kubernetes runs. It wraps one or more containers that share the same network address and storage. Most Pods hold a single container; a second “sidecar” container is added only when it must run alongside the main one (e.g. a logging agent).

What is a Deployment, and how does it differ from a Pod?

A Deployment manages a set of identical Pods for you. You declare how many replicas (copies) you want, and Kubernetes keeps that number running, replacing any that crash. It also performs rolling updates (swapping old Pods for new ones gradually with zero downtime). You almost never create bare Pods in production; you create Deployments.

kubectl create deployment web --image=nginx --replicas=3
kubectl get pods

Output:

NAME                   READY   STATUS    RESTARTS   AGE
web-7d9f8c6b54-2xk9p   1/1     Running   0          12s
web-7d9f8c6b54-8mn4q   1/1     Running   0          12s
web-7d9f8c6b54-q7rtz   1/1     Running   0          12s

What is a Service, and what types exist?

Pods get new IP addresses when they restart, so you cannot rely on them directly. A Service gives a stable name and IP that load-balances traffic across the matching Pods.

Service type	What it does	Use when
ClusterIP	Internal-only stable IP (default)	App-to-app traffic inside the cluster
NodePort	Opens a fixed port on every node	Quick external access, dev/testing
LoadBalancer	Provisions a cloud load balancer	Public production traffic on a cloud

apiVersion: v1
kind: Service
metadata:
  name: web
spec:
  selector:
    app: web
  ports:
    - port: 80
      targetPort: 80
  type: ClusterIP

What is a ConfigMap vs a Secret?

A ConfigMap stores non-sensitive config (like a log level or a URL) as key-value pairs. A Secret stores sensitive data (like passwords or API keys). Both are injected into Pods as environment variables or mounted files, keeping config out of your image.

Tip: Kubernetes Secrets are only base64-encoded by default, not encrypted at rest unless you enable encryption. Treat the cluster’s etcd store and RBAC permissions as part of your security boundary.

How do you check why a Pod is not starting?

kubectl get pods
kubectl describe pod web-7d9f8c6b54-2xk9p
kubectl logs web-7d9f8c6b54-2xk9p

describe shows scheduling and image-pull events; logs shows the app’s own output. Together they explain most failures (bad image, crash loop, missing config).

Best Practices

• Keep images small: use slim or alpine bases and multi-stage builds to drop build tools.
• Order Dockerfile instructions from least to most frequently changed so the cache works for you.
• Never bake secrets into images; pass them as runtime env vars or Kubernetes Secrets.
• Run containers as a non-root user (USER appuser) to reduce the blast radius of a breakout.
• Always set resource requests and limits on Kubernetes Pods so one app cannot starve others.
• Use Deployments (not bare Pods) and health probes so Kubernetes can self-heal and update with zero downtime.
• Pin image versions with explicit tags or digests instead of latest for reproducible deploys.

Related Topics

• DevOps interview questions
• CI/CD interview questions
• Linux interview questions
• Networking interview questions