18 Kubernetes Interview Questions With Answers, by Level

Kubernetes interviewers test whether you debug in the right order: first command, what its output means, the mechanism behind it, then the fix and the prevention. The tell of a strong candidate is knowing that the scheduler places Pods by requests, not actual usage. Below are eighteen questions grouped junior, mid and senior, with the answer that scores.

If you want the broader DevOps round, Terraform and CI included, our scenario-based DevOps interview questions cover twelve cross-tool incidents. This post goes deeper on Kubernetes alone.

Junior: the objects and the first command

1. What is the difference between a Pod, a Deployment and a Service? A Pod is one or more containers sharing network and storage. A Deployment manages ReplicaSets so a desired number of identical Pods exists and rolls them on change. A Service gives those Pods a stable name and virtual IP, selecting them by label. Strong answers mention that Pods are disposable and you never rely on a Pod IP.

2. A Pod has been Pending for ten minutes. What do you do? kubectl describe pod and read the Events. The docs define Pending as accepted by the cluster but not yet running, which includes waiting to be scheduled and pulling images. A FailedScheduling event names the reason: insufficient CPU or memory, an untolerated taint, an affinity rule, or an unbound PersistentVolumeClaim.

3. Why would a Pod be Pending when the nodes look mostly idle? Because the scheduler uses requests, not usage. The resource management docs say the scheduler uses the request to decide placement. A node at 10% CPU can still be full if its requests are committed. This answer separates juniors who have run clusters from those who have read about them.

4. How do you get logs from a container that already crashed? kubectl logs <pod> --previous. The current instance may not have logged anything yet.

5. What do readiness and liveness probes do differently? A failing readiness probe removes the Pod from Service endpoints and keeps it running. A failing liveness probe restarts the container. Mixing them up, with a liveness probe that checks a database, turns a database blip into a restart storm.

6. What happens when a container exceeds its CPU limit versus its memory limit? CPU is throttled: the docs call it a hard limit the kernel enforces. Memory over the limit can get the container OOM killed, but the docs note the kill happens when the kernel detects memory pressure, so enforcement is reactive.

Mid-level: crashes, rollouts and networking

7. Walk me through a CrashLoopBackOff. Read --previous logs, then the last state in describe. Explain the mechanism: after a container exits, the kubelet restarts it with exponential backoff of 10s, 20s, 40s and so on, capped at 300 seconds, and resets the timer once the container runs for 10 minutes without problems. Our CrashLoopBackOff guide has the exit-code table.

8. A Pod shows OOMKilled with exit code 137. What now? 137 is 128 plus signal 9, a SIGKILL. Compare the memory limit with real usage from kubectl top pod --containers, check whether the runtime sizes its heap from the limit, then raise the limit or fix the leak. The OOMKilled fix covers JVM and Node specifics.

9. A rolling update has been running for fifteen minutes. Is it stuck? Probably. progressDeadlineSeconds defaults to 600, after which the Deployment reports Progressing as False with reason ProgressDeadlineExceeded. The controller does not roll back on its own. New Pods failing readiness is the usual cause; kubectl rollout undo is the fast exit.

$ kubectl rollout status deployment/checkout --timeout=60s
$ kubectl get deployment checkout -o jsonpath='{.status.conditions[?(@.type=="Progressing")].reason}'
ProgressDeadlineExceeded
$ kubectl rollout undo deployment/checkout

10. What do maxSurge and maxUnavailable control? How many extra Pods a rollout may create and how many may be unavailable during it. Both default to 25%. Setting maxUnavailable: 0 keeps full capacity during a deploy, at the cost of needing room for surge Pods.

11. A Service exists but requests time out. Check kubectl get endpointslices -l kubernetes.io/service-name=<svc>. Empty means the selector does not match Pod labels or no Pod is Ready. Non-empty means look at targetPort, NetworkPolicies and DNS next.

12. A PVC stays Pending. Check for a default StorageClass and read the PVC events. With volumeBindingMode: WaitForFirstConsumer, Pending is expected until a Pod using the claim is scheduled; that is a feature, not a fault.

Senior: RBAC, capacity and design

13. A CI service account gets Forbidden. How do you debug it without its token? kubectl auth can-i create deployments --as=system:serviceaccount:ci:deployer -n prod. Explain that RBAC is purely additive, with no deny rules, so the fix is always a missing grant, never a conflicting rule.

14. When would you bind a ClusterRole with a RoleBinding? When you want one reusable set of permissions granted per namespace. A RoleBinding can reference a ClusterRole and scope it to the binding's namespace. A ClusterRoleBinding grants it everywhere, which is rarely what a team needs.

15. How do you choose requests and limits for a new service? Start from measured usage under load, set requests near typical usage so scheduling is honest, set memory limits with headroom, and be wary of CPU limits on latency-sensitive services because throttling shows up as tail latency.

16. How would you make a node drain safe for a critical service? PodDisruptionBudgets, more than one replica spread across zones with topology spread constraints, and readiness that reflects real dependencies.

17. How do you roll back a bad release in under a minute? kubectl rollout undo, which works because the Deployment keeps old ReplicaSets; revisionHistoryLimit defaults to 10. Then explain why GitOps teams revert the commit instead, so the controller does not reapply the bad version.

18. Design question: how would you stop one team's batch job from starving another team's API? Namespaces with ResourceQuotas and LimitRanges, PriorityClasses so the API preempts batch work, and separate node pools with taints for batch. A strong answer names the trade-off: quotas protect capacity but cause Pending Pods when set too tight.

Where this breaks

These answers assume upstream behavior on a standard managed or self-run cluster. Serverless Kubernetes offerings hide nodes, so drain and capacity questions change shape, and some clusters run feature gates that alter restart backoff. If the interviewer's stack is OpenShift or a heavily wrapped platform, say which assumption you are making.

Questions people ask

What Kubernetes questions are asked in interviews for freshers?

Freshers get object questions: Pod versus Deployment versus Service, what a namespace is, how labels and selectors connect things, and the difference between readiness and liveness probes. Expect at least one hands-on question such as reading kubectl describe pod output for a Pending Pod. Knowing that requests, not usage, drive scheduling puts you ahead of most candidates at that level.

How do I explain CrashLoopBackOff in an interview?

Say it is a state, not an error: the container keeps exiting and the kubelet waits longer between restarts, 10, 20, 40 seconds and up to 300 seconds. Then give your order: kubectl logs --previous, the exit code in describe, and the real cause, such as missing config or a failed dependency. End with how you would prevent it next time.

How should I prepare for a senior Kubernetes interview?

Run a kind cluster and break it on purpose: a Pod with a 64 CPU request, a bad image tag, a Deployment whose readiness probe never passes, and a service account with no grants. Fix each while talking aloud. Then prepare one capacity or multi-tenancy design story, because senior rounds weigh trade-offs and blast radius more than command recall.

The call we'd make

Learn the six scenarios in the table until the first command is reflex, then spend your remaining prep on the mechanisms behind them: requests and scheduling, restart backoff, rollout deadlines and additive RBAC. Interviewers forgive a forgotten flag. They do not forgive a candidate who would raise a restart policy to hide a crash.

Sources

• Kubernetes docs: Pod Lifecycle
• Kubernetes docs: Deployments
• Kubernetes docs: Resource Management for Pods and Containers
• Kubernetes docs: Using RBAC Authorization