The Kubernetes interview question pool has gotten strange. Half the questions floating around online are leftovers from 2019 when “what is a pod” counted as a hard question. The other half are so abstract (“design a multi-region autoscaling strategy”) that they wouldn’t fit in a 45-minute screen.
What actually gets asked, in most mid-level to senior SRE and platform engineering interviews, sits somewhere in the middle: can you debug what you can’t see, do you understand the control plane without having memorized the source code, and have you actually run this in production rather than just a tutorial cluster.
The concepts that come up most
Based on what platform engineers describe in engineering forums and the patterns visible in company engineering blogs, a few areas dominate:
Scheduling and resource management. How does the scheduler decide where to place a pod? What happens when a node runs out of memory? The difference between Requests and Limits trips up a lot of candidates. Requests affect scheduling; Limits affect runtime behavior. A pod can be scheduled onto a node based on its Requests but then OOM-killed if it exceeds its Limits. That distinction matters in production.
Networking. How does a Service actually route traffic? What’s the difference between ClusterIP, NodePort, and LoadBalancer types in practice, not just definitions? What does kube-proxy do and what are the failure modes? Interviewers at companies running real Kubernetes workloads care more about this than YAML syntax.
The control plane. Know what the API server, etcd, scheduler, and controller manager each do. Know which one is the single point of failure in a naive setup and how people handle that. You don’t need to have read the Go source, but you should be able to reason about what breaks first when different components have issues.
Questions that actually distinguish candidates
These are the ones that separate people who’ve run clusters from people who’ve read about clusters.
“A deployment is stuck at 50% rollout. Nothing is crashing. How do you debug it?” The answer isn’t just “kubectl describe.” It starts with checking pod conditions, then PodDisruptionBudgets, then resource quotas, then potentially webhook admission controllers blocking the new pod spec. The candidate who walks through that sequence without being prompted has seen this problem before.
“Your pods are being evicted intermittently on one node. What do you look at first?” Node-level disk pressure or memory pressure, usually visible through node conditions. Then check whether the evicted pods have resource Requests set at all. Pods without Requests are the first to go under pressure; this is documented behavior and a common gap in clusters that started small.
“How does a Horizontal Pod Autoscaler know when to scale?” It polls metrics from the metrics server (or a custom metrics API) at a configurable interval, defaults to 15 seconds. It compares current utilization to the target, applies a stabilization window to avoid thrashing, and calculates new replica counts. Knowing the stabilization window exists is the marker of someone who’s actually debugged flapping HPAs.
“What’s a DaemonSet and when would you use one instead of a Deployment?” Logging agents, node-level monitoring, network proxies. One pod per node, scheduled even to nodes added after the DaemonSet was created. Follow-up: what happens to the DaemonSet pod if you taint a node? (It gets evicted unless the DaemonSet tolerates the taint.)
The CKAD vs CKA distinction
If you have a CKAD, expect questions that assume you can write and debug YAML quickly, work with ConfigMaps and Secrets, and handle multi-container pod patterns. If you have a CKA or are interviewing for an SRE role, the questions go deeper into cluster administration: certificate rotation, etcd backup and restore, node troubleshooting, RBAC at the cluster level.
The Stack Overflow 2024 Developer Survey found Kubernetes among the most commonly used tools in the “other frameworks and libraries” category for DevOps and SRE practitioners, which tracks with how saturated the interview market has gotten. Everyone lists it now. The interviews have had to get harder to differentiate.
What to actually practice before the interview
Run a cluster. Seriously. Minikube or kind on your laptop, or a cheap single-node setup on a cloud provider. Break things intentionally. Set a memory Limit lower than the application actually needs and watch it OOM. Delete the kube-proxy pod on a node and observe what happens to service routing. Create a PodDisruptionBudget that blocks a rolling update and step through why the rollout stalls.
The CNCF Annual Survey consistently finds that Kubernetes adoption has spread well beyond Google-scale companies into mid-size teams, which means interviewers are increasingly drawn from engineers who learned on the job rather than in academic settings. They’re going to ask you the things that bit them in production. Breaking things in a test cluster is the fastest way to accumulate those answers.
What interviewers are really checking
This is my opinion and I could be wrong, but I think the best Kubernetes interviewers aren’t actually testing whether you’ve memorized the scheduler algorithm. They’re testing whether you can reason under uncertainty, walk through a problem methodically when the answer isn’t obvious, and know the limits of your own knowledge. The candidate who says “I don’t know how that specific controller works, but here’s how I’d figure it out” often does better than the candidate who guesses confidently and gets it wrong.
Know the fundamentals well. Know the failure modes. Be honest about what you haven’t touched. That combination is harder to fake than a rehearsed answer bank.