These Kubernetes interview questions help hiring managers screen platform engineers, SREs and DevOps engineers, and help candidates see what a confident answer sounds like. They assume a current cluster (Kubernetes 1.3x) with containerd as the runtime, but the most useful ones are about judgment: how someone debugs a failing pod, sizes resources, or rolls out a change without an outage. Pick 6 to 8 at the right level for your role. When an answer sounds memorized, ask "what would you check first?" and listen for a real sequence of commands and reasons.
What a strong Kubernetes interview checks
- Core objects: pods, Deployments, StatefulSets, DaemonSets, Jobs and Services, and when to use each.
- Debugging: a calm, ordered approach to CrashLoopBackOff, Pending pods, failed probes and broken networking.
- Resource and scheduling sense: requests, limits, autoscaling, affinity and disruption budgets.
- Security: RBAC, service accounts, Pod Security Admission, Secrets and network policies.
- Safe change: rollouts, rollbacks, cluster upgrades and infrastructure as code.
- Collaboration: running incidents, writing runbooks and helping app teams use the platform well.
Kubernetes interview questions: core concepts
1. What is a pod, and why doesn't Kubernetes schedule containers directly?
What good looks like: a pod is the smallest unit Kubernetes schedules. It holds one or more containers that share a network namespace (one IP, talking over localhost) and can share volumes. Grouping them lets tightly coupled helpers, like a log shipper or proxy, live and die with the main container. A strong candidate adds that you rarely create bare pods, because nothing recreates them if a node fails.
2. Deployment, StatefulSet or DaemonSet: how do you choose?
What good looks like: a Deployment runs interchangeable replicas of a stateless app and manages rollouts through ReplicaSets. A StatefulSet gives each pod a stable name, stable network identity and its own PersistentVolumeClaim, and starts them in order, which suits databases and quorum systems. A DaemonSet runs one pod per node (or per matching node), which suits log agents, node exporters and CNI components.
Red flag: "StatefulSets are for anything that writes to disk," with no mention of identity or ordering.
3. Explain the Service types and how traffic reaches a pod.
What good looks like: a ClusterIP Service gives a stable virtual IP and DNS name inside the cluster, and routes to pods that match its selector through EndpointSlices. NodePort opens a port on every node. LoadBalancer asks the cloud provider for an external load balancer. A headless Service (clusterIP: None) returns pod IPs directly, which StatefulSets use. kube-proxy, or an eBPF-based CNI in its place, programs the routing on each node.
4. What's the difference between Ingress and the Gateway API?
What good looks like: both route outside HTTP traffic to Services. Ingress is the older, simpler API, and many features live in controller-specific annotations. The Gateway API splits the job into roles (GatewayClass, Gateway, HTTPRoute and others), supports traffic splitting and header matching natively, and is where new work is happening. A strong candidate knows either one needs a controller installed to do anything.
5. What do liveness, readiness and startup probes each do?
What good looks like: a failing readiness probe removes the pod from Service endpoints but doesn't restart it. A failing liveness probe makes the kubelet restart the container. A startup probe holds off the other two until a slow app has started. Strong candidates warn against liveness probes that check a database, since one database blip can then restart every pod at once.
Red flag: identical liveness and readiness probes on every service "to be safe."
6. How do resource requests and limits work?
What good looks like: the scheduler places pods using requests. Limits cap usage at runtime. Going over the CPU limit causes throttling, while going over the memory limit gets the container OOMKilled. Requests and limits together set the QoS class (Guaranteed, Burstable or BestEffort), which affects which pods are evicted first under node pressure. Many teams set memory limits but skip CPU limits to avoid needless throttling, and a strong candidate can explain that trade-off.
7. How should you handle configuration and secrets?
What good looks like: ConfigMaps for plain settings and Secrets for sensitive values, mounted as files or environment variables. A Secret is only base64-encoded by default, so the candidate mentions encryption at rest for etcd, tight RBAC on who can read Secrets, and often an external secret manager synced in by an operator.
Red flag: "Secrets are encrypted, so it's fine to give everyone read access."
8. What are native sidecar containers?
What good looks like: a sidecar is an init container with restartPolicy: Always. It starts before the main containers, keeps running alongside them, and shuts down after them. This fixed old problems, such as a log or proxy sidecar keeping a Job from completing. The feature is stable in recent releases (GA in 1.33).
Operations, scaling and security
9. How does the Horizontal Pod Autoscaler decide to scale?
What good looks like: the HPA compares a metric, often CPU or memory utilization as a percentage of requests, against a target, and changes the replica count within set bounds. It needs the metrics server, or a custom or external metrics adapter for things like queue depth. A strong candidate notes that HPA on CPU is meaningless if requests aren't set, and that the Cluster Autoscaler or Karpenter adds nodes when pods can't be placed.
10. What controls where a pod gets scheduled?
What good looks like: requests must fit on the node, then node selectors, node affinity, taints and tolerations, pod affinity and anti-affinity, and topology spread constraints shape the choice. Taints keep pods off a node unless they tolerate it, which suits GPU or dedicated nodes. Topology spread keeps replicas across zones.
11. What is a PodDisruptionBudget, and when does it matter?
What good looks like: a PDB sets how many replicas must stay available during voluntary disruptions, such as node drains in an upgrade. It doesn't protect against node crashes. Strong candidates have seen a PDB with maxUnavailable: 0 block a drain forever and know to set it so a drain can still make progress.
12. How do you limit what a workload can do in the cluster?
What good looks like: give each workload its own service account with a Role or ClusterRole granting only the verbs and resources it needs. Turn off token automounting when a pod doesn't call the API. Enforce Pod Security Admission at the restricted or baseline level per namespace (PodSecurityPolicy was removed in 1.25). Add NetworkPolicies, which only take effect if the CNI enforces them.
13. How do you roll out a change safely and roll it back?
What good looks like: a rolling update with sensible maxSurge and maxUnavailable, readiness probes so bad pods never receive traffic, and kubectl rollout status to watch it. kubectl rollout undo returns to the previous ReplicaSet. Strong candidates mention GitOps (Argo CD or Flux) so the cluster matches a reviewed Git state, and canary or blue-green releases for risky changes.
14. How do you upgrade a cluster without downtime?
What good looks like: read the release notes for removed APIs and check manifests and Helm charts for them first. Upgrade the control plane, then node pools one at a time, cordoning and draining nodes while PDBs keep services up. Stay within the supported version skew between control plane and kubelets, take an etcd backup on self-managed clusters, and rehearse in staging.
Practical scenarios
15. A pod is in CrashLoopBackOff. Walk me through your first five minutes.
What good looks like: kubectl describe pod for events, exit codes and probe failures, then kubectl logs with --previous to see the crashed container's output. Exit code 137 often means OOMKilled. They check recent changes to the image, config or Secrets, and use kubectl debug with an ephemeral container if the image has no shell.
Red flag: deleting the pod repeatedly and hoping.
16. A new pod is stuck in Pending. What are the likely causes?
What good looks like: the events in kubectl describe usually say. Common causes are requests that no node can fit, taints with no matching toleration, affinity rules nothing satisfies, a PersistentVolumeClaim that can't bind (wrong StorageClass or zone), or a namespace ResourceQuota that's full.
17. Service A suddenly can't reach Service B. How do you narrow it down?
What good looks like: work up the layers. Check that B's pods are Ready and that the Service has endpoints (a selector typo leaves it empty). Test DNS from a debug pod, then connect to the ClusterIP and to a pod IP directly. Then look for a new NetworkPolicy, a port or targetPort mismatch, or a CNI problem on one node.
18. Your team wants to run PostgreSQL on Kubernetes. What do you ask before agreeing?
What good looks like: who owns backups, restore tests, failover and upgrades, and whether a managed database is the simpler choice. If they go ahead, they'd use a mature operator, StatefulSets with storage that suits the workload, and tested backups, not a hand-written StatefulSet and hope.
Behavioral (STAR)
19. Tell me about a production incident you helped resolve.
What good looks like: a clear Situation and their role in it, the steps they took and why, how they communicated during the incident, and a Result that includes the fix and the follow-up, such as a new alert, runbook or blameless review.
Red flag: a story with no follow-up, or one that blames a single person.
20. Describe a time you made the platform easier for app developers.
What good looks like: they noticed a real pain (slow deploys, confusing manifests, unclear on-call), built something specific such as a Helm chart, template or golden path, and measured adoption or time saved.
21. Tell me about a time you said no to a risky change.
What good looks like: they explained the risk with evidence, offered a safer path such as a staged rollout, and kept the requester on side. Strong candidates also share a time the risk turned out smaller than they thought.
A simple scoring rubric
Running this interview with AI
Platform roles attract many applicants who list Kubernetes but have never debugged a live cluster. An adaptive AI interviewer can sort that out in the first round. With NTRVSTA you customize the interview for the role and add your own Kubernetes questions, such as the CrashLoopBackOff and Pending scenarios above. The interviewer adapts in real time, raising the difficulty for candidates who answer well and easing it for those who don't, and a hint system shows who can recover from a nudge. For architecture prompts, system-design interviews come with an interactive whiteboard.
You receive a score breakdown and video snippets of key moments, so your senior engineers only spend time with the candidates who earned it. Read how AI interviews are scored and our review of AI interview software before you choose. Related sets: DevOps, system design and backend developer interview questions. Writing the job post as well? Adapt our software engineer job description template.
Questions
Should a Kubernetes interview include hands-on work?
Yes, but usually after the first round. Use the first conversation to check concepts and debugging instincts, then give finalists a short hands-on task in a throwaway cluster, such as fixing a broken Deployment. Tell every candidate the same rules and time limit.
Do certifications like CKA or CKAD replace these questions?
No. A certification shows someone studied and passed a timed practical exam, which is useful. It doesn't show how they handle a production incident, design for a real team, or explain trade-offs, so still ask scenario and behavioral questions.
How do I adjust these questions for application developers vs platform engineers?
For developers who deploy to Kubernetes, focus on Deployments, probes, resources, ConfigMaps and debugging their own pods. For platform engineers, add scheduling, networking, RBAC, upgrades, control plane health and multi-tenant design.
See how an adaptive AI interviewer runs a platform engineering screen: book a 20-minute demo, or start a sample interview and experience it as a candidate.
