Kubernetes Interview Questions 2026: Docker and K8s Scenarios

Kubernetes interview questions in 2026 test three things: whether you understand how containers are built (Docker images, layers, multi-stage builds), whether you know how the cluster works (control plane, workloads, networking, storage), and whether you can fix a broken workload under pressure. The third part decides most offers. Expect at least one prompt like "this pod is in CrashLoopBackOff, walk me through it," where you are graded on the exact kubectl sequence you run and how you reason about each output.

Below are the questions DevOps, platform and backend engineers get, plus six drills to rehearse locally.

Key Takeaways

• Scenario questions now outweigh definitions. Memorize a fixed triage order: get, describe, logs --previous, get events, then targeted checks.
• Exit codes are free signal. 1 is an application error, 137 is SIGKILL (often OOMKilled), 143 is SIGTERM.
• Know when to pick a Deployment, StatefulSet, DaemonSet, Job or CronJob, and be ready to defend the choice with one concrete example each.
• For networking, explain the path from Ingress or Gateway to Service to EndpointSlice to pod. Most "the service is down" bugs are a selector or readiness problem.
• Mention that Ingress NGINX was retired in March 2026 and Gateway API is the successor. It signals you track the ecosystem.
• Production readiness means requests and limits, three kinds of probes, PodDisruptionBudgets, and autoscaling that is tuned rather than just enabled.

What Do Kubernetes Interviews Look Like in 2026?

A Kubernetes interview is usually one or two rounds inside a broader DevOps, SRE or backend loop. The format depends on the role.

Live troubleshooting is the format candidates underprepare for. If you are interviewing for an SRE seat, our site reliability engineer interview guide covers the incident and on-call rounds that sit around this one.

Docker Interview Questions: Images, Layers and Multi-Stage Builds

Docker questions open most container interviews because they test whether you understand what actually ships to the cluster.

What is a Docker image layer? An image is a stack of read-only layers, and each filesystem-changing instruction in a Dockerfile (RUN, COPY, ADD) creates one. Layers are content-addressed and cached, so if a layer's inputs have not changed, the build reuses it. A running container adds a thin writable layer on top.

Why does instruction order matter? Because a cache miss invalidates every layer after it. Copy dependency manifests and install dependencies before copying source code, so editing one source file does not reinstall every package.

What is a multi-stage build? A multi-stage build uses several FROM stages in one Dockerfile, compiles or bundles in a heavy builder stage, and copies only the output into a slim final image. Per Docker's multi-stage build documentation, this keeps build tools and source out of the shipped image. A typical answer looks like this:

FROM golang:1.25 AS build
WORKDIR /src
COPY go.mod go.sum ./
RUN go mod download
COPY . .
RUN CGO_ENABLED=0 go build -o /out/app ./cmd/app

FROM gcr.io/distroless/static-debian12
COPY --from=build /out/app /app
USER nonroot:nonroot
ENTRYPOINT ["/app"]

Call out dependency caching, a static binary on a distroless base, a non-root user, and exec-form ENTRYPOINT.

What is the difference between CMD and ENTRYPOINT? ENTRYPOINT sets the executable, and CMD provides default arguments that can be overridden at run time. Use the exec (JSON array) form so your process runs as PID 1 and receives SIGTERM directly. With the shell form, /bin/sh becomes PID 1 and may not forward the signal, so pods take the full grace period to die.

Other Docker questions that come up often:

• How do you shrink an image? Multi-stage builds, smaller bases (Alpine, distroless, slim variants), a .dockerignore, and combining cleanup into the same RUN as the install.
• Does Kubernetes still run Docker? No. Dockershim was removed in v1.24, and clusters use containerd or CRI-O. Docker-built images still work because they are OCI images.

How Does Kubernetes Architecture Work?

Kubernetes is a declarative system: you submit desired state to the API server, and controllers continuously work to make actual state match it. Every architecture question is a variation of explaining that loop.

The control plane components to name:

• kube-apiserver: the only component that talks to etcd. Every client, including kubectl and the kubelet, goes through it.
• etcd: a consistent key-value store holding all cluster state. Losing it without a backup means losing the cluster.
• kube-scheduler: assigns unscheduled pods to nodes based on resource requests, affinity, taints and tolerations, and topology spread.
• kube-controller-manager: runs the reconciliation loops for Deployments, ReplicaSets, Jobs, nodes and more.

On every worker node, the kubelet watches for pods assigned to its node and drives the container runtime to start them, kube-proxy (or an eBPF data plane such as Cilium) programs Service routing, and the runtime pulls images and runs containers.

The classic follow-up is "what happens when you run kubectl apply?" The API server authenticates, authorizes, runs admission control and persists the Deployment in etcd. The Deployment controller creates a ReplicaSet, the ReplicaSet controller creates pods, the scheduler binds each pod to a node, and that node's kubelet pulls the image and starts the containers. Readiness probes then decide when the pod joins Service endpoints.

Deployment vs StatefulSet vs Job: Which Workload When?

Choosing the right workload controller is a judgment question, and interviewers want a reason, not a definition.

Expect follow-ups on rollout mechanics. A Deployment's rolling update defaults to maxSurge: 25% and maxUnavailable: 25%. Setting maxUnavailable: 0 keeps full capacity during the rollout at the cost of needing spare room for surge pods. kubectl rollout undo deployment/api reverts to the previous ReplicaSet.

For StatefulSets, mention the headless Service that gives each pod a stable DNS name, and volumeClaimTemplates that give each replica its own PersistentVolumeClaim. Senior candidates also note that many teams use a managed database instead. For cloud-heavy loops, see our AWS interview questions guide.

Networking: Services, Ingress and Gateway API

Kubernetes networking questions test whether you can trace a request from the internet to a container. Learn the chain: external load balancer, Ingress or Gateway, Service, EndpointSlice, pod.

What are the Service types?

• ClusterIP: a stable virtual IP reachable only inside the cluster. The default.
• NodePort: exposes the Service on a static port on every node.
• LoadBalancer: asks the cloud provider for an external load balancer that forwards to the Service.
• ExternalName: a DNS CNAME to an outside hostname, with no proxying.
• Headless (clusterIP: None): no virtual IP. DNS returns pod IPs directly, which StatefulSets rely on.

How does a Service find its pods? Through a label selector. The control plane maintains EndpointSlices listing the IPs of pods that match the selector and are Ready. A pod that fails its readiness probe is removed from endpoints, which is why readiness bugs look like networking bugs.

What is the difference between a Service and an Ingress? A Service gives a set of pods a stable address at layer 4. An Ingress is a layer 7 routing rule set (hosts, paths, TLS) that an Ingress controller implements, usually fronting many Services behind one load balancer.

What is Gateway API? Gateway API is the successor to Ingress. It splits configuration into roles: GatewayClass for the infrastructure provider, Gateway for the platform team, and HTTPRoute or other route types for application teams. It supports header matching, traffic splitting and cross-namespace routing natively instead of through controller-specific annotations.

The Kubernetes project announced the retirement of the Ingress NGINX controller, with best-effort maintenance ending in March 2026 and no security fixes after that. Existing installs keep working, but a candidate who says "we would migrate to a Gateway API implementation or another maintained controller" sounds current. NetworkPolicies are the other common topic: by default all pods can reach all pods, and a default-deny policy per namespace is the usual baseline, enforced only if your CNI supports it.

Config, Secrets and Storage Questions

Configuration questions check that you separate code from config and understand where sensitive data actually lives.

ConfigMap vs Secret: both inject key-value data as environment variables or mounted files. Secrets are intended for sensitive data, but their values are only base64 encoded and stored in etcd. Real protection comes from encryption at rest (preferably with a KMS provider), tight RBAC on get secrets, and often an external secret manager synced in by a tool like External Secrets Operator.

A favorite detail: environment variables are read once at start, so ConfigMap updates need a pod restart. Mounted files refresh after a delay, unless mounted with subPath.

Storage vocabulary to get right:

• PersistentVolume (PV): a piece of storage in the cluster.
• PersistentVolumeClaim (PVC): a request for storage that binds to a PV.
• StorageClass: defines a provisioner and parameters so PVs are created dynamically when a PVC appears.
• Access modes: ReadWriteOnce (one node), ReadOnlyMany, ReadWriteMany, and ReadWriteOncePod (exactly one pod).
• Reclaim policy: Delete removes the backing disk when the PVC is deleted. Retain keeps it for manual recovery, which is what you want for production databases.

Kubernetes Troubleshooting Scenarios: Six Drills With kubectl

This section separates offers from rejections. Interviewers check whether you follow an order, read output instead of guessing, and state a hypothesis before each command. The same habits apply to any debugging interview.

Use this universal triage sequence on every scenario before going deeper:

kubectl get pods -n shop -o wide
kubectl describe pod <pod> -n shop
kubectl logs <pod> -n shop --previous
kubectl get events -n shop --sort-by=.lastTimestamp

describe gives you state, exit codes, restart counts and recent events. logs --previous shows output from the container instance that crashed, which matters because the current instance may have just started. The official pod debugging docs follow the same order.

Drill 1: "The pod is in CrashLoopBackOff. Walk me through it."

CrashLoopBackOff means the container starts, exits, and the kubelet restarts it with an exponential back-off that caps at five minutes. It is a symptom, not a cause.

1. kubectl describe pod and read Last State: the exit code and reason.
2. kubectl logs --previous to see why the process exited.
3. Branch on the exit code: 1 points to the app (missing env var, bad config, failed DB connection); 137 points to OOMKilled or a liveness kill; 143 means SIGTERM, often a liveness probe failing; 127 means the command was not found.
4. If logs are empty, check the command and args in the spec and whether a liveness probe is killing a slow-starting app. The fix for the latter is a startupProbe, not a longer liveness timeout.
5. For a distroless image with no shell, attach an ephemeral container: kubectl debug -it <pod> --image=busybox --target=<container>.

Drill 2: "The pod is stuck in Pending."

Pending means the scheduler has not placed the pod, or a volume cannot bind. The answer is almost always in the events at the bottom of describe.

• "Insufficient cpu" or "Insufficient memory": requests exceed free capacity. Check kubectl describe node allocations, lower the requests, or add nodes.
• "didn't match Pod's node affinity/selector" or "untolerated taint": fix the selector or add a toleration.
• "pod has unbound immediate PersistentVolumeClaims": check kubectl get pvc and the StorageClass.

Drill 3: "ImagePullBackOff or ErrImagePull."

Read the event message. It will say whether the tag does not exist, the registry denied access, or the registry is unreachable. Check the image name and tag, confirm imagePullSecrets exist in the same namespace, and verify node egress to the registry.

Drill 4: "The pod keeps getting OOMKilled."

describe shows Reason: OOMKilled and exit code 137. The container exceeded its memory limit, so the kernel killed it. Check actual usage with kubectl top pod (requires metrics-server), then decide: raise the limit, fix a leak, or tune runtime settings such as JVM heap so the process respects the container limit. Senior answer: memory is incompressible, so set the memory request equal to the limit for critical workloads to avoid node-level eviction surprises.

Drill 5: "The Service returns 503 or connection refused, but pods are Running."

Running is not Ready. Trace the chain:

kubectl get endpointslices -n shop -l kubernetes.io/service-name=checkout
kubectl get svc checkout -n shop -o yaml
kubectl get pods -n shop --show-labels
kubectl run tmp -n shop --rm -it --image=busybox -- wget -qO- checkout:8080/healthz

Empty endpoints mean the Service selector does not match pod labels, or pods are failing readiness. If endpoints exist, check that targetPort matches the container port and that no NetworkPolicy blocks traffic.

Drill 6: "A rollout is stuck."

kubectl rollout status deployment/api hangs or reports the progress deadline exceeded. New pods are failing readiness or cannot schedule, so old pods are never removed. Diagnose the new ReplicaSet's pods with the triage sequence, then kubectl rollout undo to restore service while you fix forward.

Scaling and Production Readiness Questions

Production-readiness questions ask whether you would trust this workload at 3 a.m. Answer with a checklist.

Requests and limits. Requests drive scheduling; limits cap usage. Exceeding a CPU limit causes throttling, while exceeding a memory limit causes an OOM kill. Many teams set CPU requests but omit CPU limits to avoid throttling latency-sensitive services, and they always set memory limits.

Probes. A startupProbe protects slow starters, a readinessProbe controls traffic, and a livenessProbe restarts deadlocked processes. Liveness should not check downstream dependencies, or a database blip restarts your whole fleet.

Autoscaling layers:

• Horizontal Pod Autoscaler (HPA): scales replica count on CPU, memory or custom metrics via autoscaling/v2. It needs requests set, since utilization is measured against them.
• Vertical Pod Autoscaler (VPA): recommends or applies right-sized requests.
• Cluster Autoscaler or Karpenter: adds and removes nodes when pods cannot schedule.

Availability. Spread replicas across zones with topology spread constraints, add a PodDisruptionBudget so node drains cannot take down too many replicas, and handle SIGTERM within terminationGracePeriodSeconds (30 seconds by default). A short preStop sleep lets endpoint removal propagate before the app stops accepting connections.

These topics overlap with infrastructure-flavored system design interviews. When designing something like a rate limiter, explaining how it deploys and scales on Kubernetes shows depth.

Kubernetes Interview Questions for Experienced Engineers

Senior and staff candidates get the same topics with harder follow-ups. Prepare crisp answers to these:

• How would you upgrade a production cluster with zero downtime? (Control plane first, then node pools via surge or blue-green, with PDBs respected and deprecated APIs checked beforehand.)
• How do you restore etcd, and how often do you test the restore?
• How do you enforce policy across teams? (RBAC, Pod Security Admission, and an admission policy engine such as Kyverno or OPA Gatekeeper, or built-in ValidatingAdmissionPolicy.)
• Helm or Kustomize, and how does GitOps with Argo CD or Flux change your rollback story?
• How do you cut cluster cost without hurting reliability? (Right-size requests from real usage, bin-pack with node autoscaling, use spot capacity for tolerant workloads.)
• One cluster per environment or namespaces in a shared cluster? Defend the blast-radius trade-off.

At this level, trade-offs matter more than commands. Our staff engineer interview guide covers how to frame them, and the backend engineer interview guide covers the surrounding loop.

A Two-Week Kubernetes Interview Prep Plan

Hands-on repetition beats reading. This plan assumes an hour or two a day.

1. Days 1-2: Write a multi-stage Dockerfile for a small service. Compare image sizes and confirm it stops cleanly on SIGTERM.
2. Days 3-4: Deploy it to a kind or minikube cluster with a Deployment, Service and ConfigMap. Explain the kubectl apply flow out loud.
3. Days 5-7: Break and fix each of the six drills using only the triage sequence. Time yourself.
4. Days 8-9: Add a StatefulSet with a PVC, a CronJob, an HTTPRoute or Ingress, and a default-deny NetworkPolicy.
5. Days 10-11: Add probes, requests, limits, an HPA and a PDB, then load test.
6. Days 12-14: Have a friend plant an unknown fault, and practice thinking out loud while you diagnose.

If your loop includes a coding round too, the language guides for Go and Python cover the languages most platform teams write tooling in.