Kubernetes Interview Questions and Answers

Kubernetes interviews are layered, and the level you are interviewing for changes what counts as a good answer. Juniors are expected to define the core objects and explain the declarative model: you describe desired state in YAML, the API server persists it to etcd, and controllers reconcile actual state toward it. Mid-level candidates must connect objects into working systems, reason about failure modes, and read the output of kubectl describe and kubectl logs fluently. Senior and staff candidates are judged on trade-offs, blast radius, multi-tenancy, security posture, and how they would design and operate clusters at scale.

A reliable tell of seniority is whether you reach for the right diagnostic command unprompted. A junior says a pod is broken; a senior says kubectl describe pod shows the events, kubectl get events --sort-by=.lastTimestamp gives the timeline, and kubectl logs --previous shows the last crash. Interviewers also watch for honest scoping: knowing what you would check first, second, and third under time pressure beats reciting every possible cause.

The pod is the smallest deployable unit and the atom of scheduling: one or more containers that share a network namespace (same IP and port space) and can share volumes. You rarely create bare pods in production because nothing reschedules them when a node dies. Instead a Deployment manages a ReplicaSet, which manages pods, giving you declarative scaling, rolling updates, and rollbacks (kubectl rollout status, kubectl rollout undo). StatefulSets are the equivalent for workloads needing stable network identity and per-pod persistent storage; DaemonSets run one pod per node for agents like log shippers or CNI components.

A Service gives a stable virtual IP and DNS name in front of an ephemeral set of pods selected by labels, load-balancing across the ready endpoints. ClusterIP is internal-only, NodePort exposes a static port on every node, and LoadBalancer provisions an external load balancer via the cloud provider. The Service decouples callers from pod churn: pods come and go, the Service name stays constant. Namespaces are virtual partitions for scoping names, applying ResourceQuotas and RBAC, and organizing tenants or environments, but they are not a hard security boundary by themselves; cross-namespace network traffic is allowed by default and must be restricted with NetworkPolicies.

Cluster DNS (CoreDNS) makes Services discoverable by name. A Service named api in namespace prod resolves at api.prod.svc.cluster.local, and same-namespace callers can just use api. An Ingress is not a Service type; it is an L7 routing layer that maps hostnames and paths to backend Services, and it does nothing without an Ingress controller (ingress-nginx, Traefik, or a cloud controller) actually running and watching Ingress objects. A classic interview trap is claiming you created an Ingress and it should work, when no controller is installed to act on it. (Newer clusters increasingly use the Gateway API for the same job, so mentioning it signals you are current.)

Storage uses the PersistentVolume and PersistentVolumeClaim split: a PVC is the workload's request for storage (size, access mode), and it binds to a PV that satisfies it, usually provisioned dynamically through a StorageClass. Access modes matter: ReadWriteOnce allows read-write by pods on a single node, so a multi-replica Deployment whose pods land on different nodes and share one RWO volume will get pods stuck Pending or ContainerCreating because the volume cannot attach to a second node. ConfigMaps hold non-sensitive configuration and Secrets hold sensitive values; both can be mounted as files or injected as environment variables. Remember that stock Secrets are only base64-encoded, not encrypted at rest unless you enable an encryption provider, and changes to a mounted ConfigMap propagate to the file but the process must be designed to reload (env-var injections do not update a running pod at all).

The scheduler places pods based on resource requests, node selectors, affinity and anti-affinity, taints and tolerations, and topology spread constraints. Requests reserve capacity and drive scheduling; limits cap usage at runtime. Get this wrong and you either pack nodes too tightly (no headroom, evictions) or waste capacity. A pod whose requests no node can satisfy stays Pending, and kubectl describe pod will show the FailedScheduling event explaining exactly which predicate failed (Insufficient cpu, Insufficient memory, untolerated taint).

Reliability hinges on probes. A liveness probe restarts a hung container; a readiness probe removes a pod from Service endpoints until it is ready (without restarting it); a startup probe protects slow-booting apps from being killed by liveness before they finish initializing. A common production outage is a liveness probe that is too aggressive, restarting healthy-but-busy pods into a CrashLoop. On security, every pod runs as a ServiceAccount, and RBAC (Roles and ClusterRoles bound by RoleBindings and ClusterRoleBindings) governs what that identity can do. The senior-level answer is least privilege: grant a namespaced Role with only the verbs and resources a workload needs, never bind the cluster-admin ClusterRole to application identities, and prefer per-namespace scoping so a compromised pod cannot read or write outside its own namespace.

Live troubleshooting is where senior interviews are won or lost, and the discipline is always the same: kubectl get pods to see status, kubectl describe pod for events, and kubectl logs (add --previous to read the crashed instance). CrashLoopBackOff means the container keeps exiting and Kubernetes is backing off (exponentially, capped at five minutes) between restarts; the cause is almost always in the logs of the previous attempt: a bad config or missing env var, a failed dependency at startup, a non-zero exit, or an over-aggressive liveness probe. The status itself is a symptom, not a diagnosis, so never stop at the name.

ImagePullBackOff and ErrImagePull are registry problems: a wrong image name or tag, a private registry with no imagePullSecret, rate limiting, or the node having no network path to the registry. kubectl describe pod shows the exact pull error. Pending means the scheduler cannot place the pod: insufficient CPU or memory across all nodes, an unsatisfiable nodeSelector or affinity rule, an untolerated taint, or a PVC that will not bind (for example a ReadWriteOnce volume already attached on another node). OOMKilled appears as the container's last state with reason OOMKilled and exit code 137 (128 + SIGKILL): the process exceeded its memory limit and the cgroup OOM killer terminated it. The fix is to right-size the memory limit, find the leak or unbounded buffer, and confirm requests and limits reflect real usage measured under load.

Memorizing definitions gets you through the first ten minutes; the interview turns when someone hands you a broken cluster or asks you to design one. Build muscle memory on the diagnostic loop until kubectl describe, kubectl get events --sort-by=.lastTimestamp, and kubectl logs --previous are reflexes. Practice deliberately breaking things in a throwaway cluster: ship a bad image tag, set a memory limit too low, apply a too-aggressive liveness probe, request more CPU than any node has, then walk yourself through finding and fixing each one out loud as you would in the interview.

prepme.io is built for exactly this loop. Paste the job description you are targeting and you get a free briefing that maps the role to three practice surfaces: real in-browser k3s/Kubernetes and Terraform labs where you debug live pods (the flagship), auto-graded ABCD exams across easy, medium, and hard to drill recall, and an architecture design round for the whiteboard portion. Each task is graded 0 to 100 with written feedback so you know exactly where you stand, and a free Company Coverage card researches the employer (recent news, funding, culture, and likely interview intel) so you can tailor your answers. Generating and viewing the briefing is free; you can try the demo before deciding to subscribe and practice the hands-on labs.