25 Kubernetes Interview Questions for DevOps & SRE

Kubernetes interviews test one thing above all: whether you've operated it, or merely read about it. Anyone can define a pod. The candidates who stand out can explain what happens when a node dies at 3 a.m., why a pod is stuck in CrashLoopBackOff, and how a request actually finds its way to a container. Talk like someone who's paged, and the interview is yours.

The core mental model: Kubernetes is a reconciliation loop. You declare desired state ("three replicas of this image"), and controllers continuously work to make actual state match. Almost every interview question is a variation on "what happens when reality and desire disagree?"

The question taxonomy

• Workload objects. Pod vs Deployment vs StatefulSet vs DaemonSet — and when each is the right tool.
• Networking. Services (ClusterIP vs NodePort vs LoadBalancer), Ingress, DNS, how kube-proxy routes traffic.
• Health and scheduling. Readiness vs liveness probes, resource requests vs limits, why OOMKilled happens.
• Configuration and security. ConfigMaps, Secrets, RBAC, network policies.
• Troubleshooting. The scenario questions: "a deployment isn't rolling out — walk me through your debugging."

Worked example: debugging a CrashLoopBackOff

"Your pod keeps restarting. Go." The interviewer is watching your sequence, not fishing for a magic command:

kubectl get pods                        # see the state and restart count
kubectl describe pod <name>             # events: probe failures, image pulls, OOM
kubectl logs <name> --previous          # logs from the crashed container
kubectl get events --sort-by=.lastTimestamp

Narrate the branches: logs empty? The container dies before logging — check the command and entrypoint. OOMKilled in events? Raise the memory limit or fix the leak. Liveness probe failing but the app is healthy? The probe is wrong — too aggressive, or hitting a slow endpoint. That structured reasoning is the answer.

How answers get scored

Rubrics reward operational instincts: you mention probes before restarts, requests/limits before "add more nodes," and you distinguish readiness (should this pod take traffic?) from liveness (should we kill and restart it?). Confusing those two is the fastest way to lose credibility. Security awareness — running as non-root, scoping RBAC tightly — is an increasingly common differentiator.

Common mistakes

• Setting liveness and readiness probes to the same endpoint with the same timing — a slow-starting app gets killed before it's ever ready.
• Setting resource limits without requests (or neither), then being surprised by eviction.
• Putting environment-specific config in the image instead of a ConfigMap.
• Reciting object definitions without being able to debug a single scenario.

The design question: "walk me through deploying this app"

At some point you'll get a greenfield scenario: containerise and deploy a small stateless web service with a database. The rubric rewards sequencing. Namespace and resource quotas first; a Deployment with requests, limits, and both probes; a Service in front; the database as a StatefulSet or — better — an honest "I'd use the managed service and say why." Config in a ConfigMap, credentials in a Secret, and a mention of RBAC scoping. Then the money question: "how do you roll out a new version safely?" Rolling update with maxSurge and maxUnavailable, readiness gating the rollout, and a rollback via kubectl rollout undo if error rates spike. Draw that arc without being prompted — build, expose, configure, secure, roll out safely — and you've demonstrated exactly the operational completeness the round exists to measure.

FAQ

Do I need to know Helm and service meshes? Helm at a "why templating matters" level, yes. Istio/Linkerd only if the role mentions them — know what problems meshes solve, not their internals.

How does this differ from Docker questions? Docker is about building and running one container; Kubernetes is about running many, reliably, across machines. See the Docker guide for the container fundamentals.

Build the broader operational picture with the DevOps engineer guide, and rehearse scenario answers with Aissence practice.