Kubernetes interview questions: scenarios for experienced

Kubernetes interview questions for experienced engineers are mostly scenarios: a pod is stuck in CrashLoopBackOff, a Service has no endpoints, a node drain hangs, and you're asked what you would check first and why. Interviewers score the order you work in (symptom, command, cause, fix, prevention) more than the final answer. This guide gives you that order, then works through 15 scenarios in four groups (workloads, networking, security, cluster operations), each with the status or error you'd see, the command that confirms it, the usual cause and the fix.

Every command and error string here is from the kubernetes.io documentation for v1.37, the current stable release as of November 2026, and the version the CKA, CKAD and CKS exams are based on. At the end are the facts that date an answer, a word on the "Kubernetes vs Docker" question, and how to practise. For the wider DevOps interview (Linux, Git, CI/CD, Terraform), see DevOps interview questions.

How Kubernetes interview questions are scored

A good scenario answer follows the same five steps every time:

1. Read the symptom exactly. Pending, CrashLoopBackOff and ImagePullBackOff point to different layers. Say which layer you suspect before you touch anything.
2. Name the command that confirms it. Usually kubectl describe for events, kubectl logs --previous for a crashed container, and kubectl get events for the wider picture.
3. Give the likely causes, most common first.
4. Fix it, with the exact field or flag.
5. Say how you'd stop it happening again: a probe, a limit, an alert, a policy.

Seniority changes what the interviewer listens for. With two years of experience you're expected to get to the right command quickly. With five, you should also explain the trade-off in the fix. At staff or platform level, step 5 carries the answer: how you'd make the failure impossible for every team, not just fix it once. If your experience is mostly labs rather than production, say so and describe what you built; inventing an outage story rarely survives the follow-up questions.

Scenario-based Kubernetes interview questions: pods and workloads

A pod is in CrashLoopBackOff

CrashLoopBackOff is not an error in itself. It is a waiting state: the container keeps exiting, and the kubelet waits longer between restarts each time, from 10 seconds up to five minutes. Start with kubectl describe pod <pod> for the exit code and events, then kubectl logs <pod> -c <container> --previous to read the output of the run that crashed, since the current container may have no logs yet. The usual causes are the application failing at startup (a missing config value, a bad command) or a liveness probe killing a container that is simply slow to start.

The slow-start case is a favourite follow-up. The fix is a startupProbe, which holds off the liveness probe until the app is up. A practice question on startup probes for a slow-booting app sets this exact trap.

The container shows OOMKilled with exit code 137

kubectl describe pod shows Reason: OOMKilled and Exit Code: 137: the container used more memory than its limit and was killed. The fix is to right-size the memory limit from real usage, or find the leak, rather than delete the limit. A strong answer also mentions requests versus limits and what they mean for scheduling. A practice question on OOMKilled and memory limits covers it.

A pod is stuck in Pending or ImagePullBackOff

Pending means the scheduler found no node for the pod. kubectl describe pod shows a FailedScheduling event, such as 0/N nodes are available: N node(s) had untolerated taint or didn't match Pod's node affinity/selector, or a lack of CPU or memory. The fix depends on the message: add a toleration, correct a node label, soften a hard affinity rule, or add capacity. Restarting nodes is the wrong answer, as a practice question on reading Pending events shows.

ImagePullBackOff is the image layer instead: a wrong tag, a private registry without imagePullSecrets, or a registry the node can't reach.

A rollout broke production

Check kubectl rollout status deployment/<name> and kubectl rollout history deployment/<name>, then kubectl rollout undo deployment/<name> to return to the previous revision. The senior follow-up is prevention: readiness probes so a bad version never receives traffic, and rolling update settings so only some pods change at once. One dated detail: the old --record flag for recording the change cause is gone, so don't mention it.

Networking scenarios

A Service has no endpoints

kubectl describe svc <name> shows Endpoints: <none> and clients get Connection refused. Check kubectl get endpointslices -l kubernetes.io/service-name=<name>. The three usual causes are a Service selector that doesn't match the pod labels, pods that never pass their readiness probe, and a targetPort that isn't the port the container listens on. A practice question on a Service with no ready endpoints covers the readiness case.

DNS stopped working after a NetworkPolicy change

Clients get ** server can't find <name>: NXDOMAIN or connection timed out; no servers could be reached. Test from a debug pod with kubectl exec -i -t dnsutils -- nslookup <service>.<namespace> and read CoreDNS's logs with kubectl logs -l k8s-app=kube-dns -n kube-system. If a default-deny egress policy went in just before, that's almost certainly it: it blocks port 53 to CoreDNS too. The fix is an explicit egress rule allowing UDP and TCP port 53 to kube-dns. A practice question on default-deny egress and DNS is this scenario. Also check the name: a query across namespaces needs <svc>.<ns>.svc.cluster.local.

Traffic is silently dropped

Requests hang with Connection timed out, and there are no Kubernetes events, because NetworkPolicy drops packets without reporting them. Read the policies with kubectl describe networkpolicy <name> -n <namespace>. Two causes to name: a policy that doesn't select the sending pods, and a CNI plugin that doesn't enforce NetworkPolicy at all, in which case your policies do nothing. The Kubernetes network policies guide goes deeper.

Ingress returns 502 or 503

Clients get 502 Bad Gateway or 503 Service Temporarily Unavailable, and kubectl describe ingress <name> may show an empty Address:. The usual causes are no ingress controller installed, a backend Service whose selector matches nothing, or a missing TLS Secret. Expect the follow-up on Gateway API: it is GA in gateway.networking.k8s.io/v1, and the Ingress API is frozen, receiving no new features. For a Gateway, check kubectl describe gateway <name> and kubectl describe httproute <name>. The Kubernetes Service types guide covers the Service side.

Security scenarios

A user or service account gets Forbidden

The error reads Error from server (Forbidden): <resource> is forbidden: User "<user>" cannot <verb> resource .... Test with kubectl auth can-i <verb> <resource> --namespace <ns> --as <user>, or --as system:serviceaccount:<ns>:<sa> for a workload. Common causes: a ClusterRole bound with a namespaced RoleBinding when the resource is cluster-wide, the wrong API group, or a missing verb such as list. RBAC permissions are purely additive, so the fix is always a binding that grants exactly what's needed, never a deny rule. A practice question on ClusterRole binding scope tests the RoleBinding-versus-ClusterRoleBinding detail.

Pod creation is rejected by Pod Security

The API server says pods "<name>" is forbidden: violates PodSecurity "<level>:<version>". The namespace enforces a Pod Security Standard (Privileged, Baseline or Restricted) through the built-in Pod Security Admission controller. The fix is in the pod: runAsNonRoot: true, drop all capabilities, seccompProfile.type: RuntimeDefault. Before you tighten a namespace, test with kubectl label --dry-run=server ns <name> pod-security.kubernetes.io/enforce=restricted. A practice question on enforcing Pod Security Admission covers the labels.

"Are Kubernetes Secrets secure?"

Not by default: Secret values are base64-encoded, not encrypted, and stored in etcd. The full answer covers encryption at rest (the KMS v2 provider has been GA since v1.29), RBAC on Secrets, and short-lived ServiceAccount tokens from the TokenRequest API, which replaced the old auto-generated token Secrets. A practice question on Secrets encryption at rest goes further. If a pod can't find a Secret, look for CreateContainerConfigError or a FailedMount event: usually the Secret is in a different namespace or a key name is misspelled.

Cluster operations scenarios

HPA shows TARGETS unknown

kubectl get hpa shows <unknown>/50%, and events say FailedGetResourceMetric. Either Metrics Server is missing or unhealthy, or the containers don't set resources.requests.cpu, which a CPU-percentage target needs. The senior twist: the HPA adds replicas but they stay Pending because the Cluster Autoscaler has reached its node limit or the cloud quota.

A node drain is stuck

kubectl drain <node> --ignore-daemonsets --delete-emptydir-data hangs with Cannot evict pod as it would violate the pod's disruption budget. The PodDisruptionBudget allows zero disruptions, because it demands every pod stay up or because some pods are failing readiness and already count as down. Fixes: scale up before maintenance, loosen the budget, or set unhealthyPodEvictionPolicy: AlwaysAllow (GA since v1.31) so unhealthy pods don't block the drain.

Walk through a kubeadm upgrade

Upgrade one minor version at a time. Run sudo kubeadm upgrade plan, then sudo kubeadm upgrade apply <version> on the first control-plane node, then sudo kubeadm upgrade node on the others, and only then upgrade each node's kubelet, draining it first. The causes of failed upgrades are skipping a minor version, upgrading the kubelet before the API server, and expired certificates. A practice question on debugging the API server static pod is what you do when the control plane doesn't come back.

Back up and restore etcd

Take the snapshot with etcdctl snapshot save (with the endpoint and certificate flags), check it with etcdutl snapshot status, and restore with etcdutl snapshot restore into a new directory, then point the etcd static pod's hostPath in /etc/kubernetes/manifests/etcd.yaml at it. Say etcdutl for the restore: etcdctl snapshot restore has been deprecated since etcd v3.5. The failure symptoms to know are etcdserver: request timed out and database space exceeded, the latter from etcd's default 2 GB space quota.

Answers that date you: what changed by v1.37

Interviewers notice an answer learned from an old tutorial. As of v1.37:

• PodSecurityPolicy was removed in v1.25. Pod Security Standards with Pod Security Admission replaced it.
• The HPA API is autoscaling/v2; v2beta1 and v2beta2 are removed.
• The control-plane taint is node-role.kubernetes.io/control-plane; the old master taint is gone.
• kubectl rollout ... --record is removed.
• etcd restores use etcdutl, not etcdctl.
• Ingress is frozen and Gateway API is GA.
• kube-proxy uses EndpointSlices by default.

Kubernetes supports the latest three minor releases: v1.37, v1.36 and v1.35 as of November 2026.

Kubernetes vs Docker, the question that still comes up

It's usually asked of freshers, but experienced candidates get it as a test of precision. Docker builds and runs containers on one machine. Kubernetes schedules containers across a cluster and keeps them in the state you declared: it restarts them, scales them, routes traffic to them and rolls out new versions. They aren't alternatives: you package an image, and Kubernetes runs it. One container detail comes up in both worlds: a shell-form ENTRYPOINT makes /bin/sh process 1, so the stop signal never reaches your app and it is killed after the grace period, as a practice question on PID 1 signal handling shows.

How to practise

Reading answers is not enough for scenario rounds; you need to have broken a cluster and fixed it. Run a local cluster, then cause each scenario above on purpose: a bad image tag, a memory limit set too low, a default-deny policy, a PodDisruptionBudget that blocks a drain, an etcd snapshot and restore. Say each answer aloud in the five-step order.

The CNCF exam curricula are a good checklist even if you don't sit the exams. The CKA puts 30% on troubleshooting, 25% on cluster architecture and 20% on services and networking. The CKA cert page and CKA practice questions cover most of the operations and networking scenarios here; the CKAD cert page and CKAD practice questions cover probes, resources and Services; the CKS cert page and CKS practice questions cover the security group. The CKA exam guide and best Kubernetes certification explain the exams themselves.

Frequently asked questions

What Kubernetes questions are asked of experienced candidates?

Mostly scenarios: a pod in CrashLoopBackOff, a Service with no endpoints, DNS broken by a NetworkPolicy, a Forbidden error, a stuck drain, an upgrade or an etcd restore. You're judged on the order you investigate in and on how you'd prevent a repeat, not on definitions.

How do I answer a Kubernetes troubleshooting question?

Name the symptom exactly, give the command that confirms it, list the likely causes with the most common first, state the fix with the exact field or flag, and finish with prevention. Keep to that order even under pressure; it's what interviewers listen for.

What is the difference between liveness, readiness and startup probes?

A failing liveness probe restarts the container. A failing readiness probe takes the pod out of its Service's endpoints without restarting it. A startup probe delays the other two until a slow app has started, which stops liveness checks killing it during boot.

What is Kubernetes architecture, in one answer?

A control plane (the API server, etcd for state, the scheduler and the controller manager) and worker nodes running the kubelet, a container runtime and kube-proxy. Everything goes through the API server, and controllers keep moving the cluster toward the state stored in etcd.

Is a Kubernetes certification worth it for interviews?

It helps you get shortlisted, especially the CKA, because its exam is hands-on in a real cluster. In the interview itself, the scenarios above matter more than the badge, but preparing for the CKA is a structured way to learn them.