Top Kubernetes Interview Questions & Answers (2026)

CrashLoopBackOff means the container keeps starting and exiting, and the kubelet is backing off restarts, up to five minutes between attempts. First I run kubectl describe pod and read the events and the last state: the exit code and reason tell me a lot. Exit 137 with reason OOMKilled means the memory limit is too low or the app leaks. Exit 1 usually means the app itself failed, so I run kubectl logs with the previous flag to see the crashed container's output, not the fresh one. I also check for a liveness probe killing a slow starter, a missing ConfigMap key or Secret, or a wrong command or args. If it dies too fast to inspect, I use kubectl debug to start a copy with a different command.

RBAC is additive allow-only. A Role or ClusterRole lists verbs on resources, and a RoleBinding or ClusterRoleBinding attaches it to users, groups or service accounts. A RoleBinding can reference a ClusterRole, which scopes that reusable role to one namespace. For CI I would create a service account in the target namespace, a Role allowing get, list, watch, create, update and patch on Deployments, Services and ConfigMaps there, and a RoleBinding. I would not hand out the built-in edit role without thinking, because it includes Secrets. Then I verify with kubectl auth can-i, using the as flag with the service account name, both in that namespace and in another one where it should be refused. I prefer short-lived tokens or workload identity over long-lived token Secrets.

By default every pod accepts traffic from anywhere. A NetworkPolicy selects pods in its namespace, and once any policy selects a pod for ingress, only the traffic some policy explicitly allows gets in. The same applies separately to egress. Policies only add allows, there is no deny rule, and reply traffic for an allowed connection is permitted. A default deny is a policy with an empty podSelector and policyTypes Ingress, Egress, or both. Two practical points. Enforcement depends on the CNI, so Calico or Cilium will enforce it while a plain flannel setup silently ignores it. And if you deny egress, you must allow UDP and TCP 53 to CoreDNS in kube-system, or every name lookup breaks and it looks like an app bug.

On kubeadm, etcd runs as a static pod and its certificates live under /etc/kubernetes/pki/etcd. I take a snapshot with etcdctl snapshot save, passing the endpoint https://127.0.0.1:2379 and the cacert, cert and key flags for those files, then check it with etcdutl snapshot status. The snapshot contains every Secret, so it goes off the node to encrypted storage, on a schedule. To restore, I stop the API server and etcd by moving their manifests out of the manifests folder, run etcdutl snapshot restore into a new data directory, point the etcd manifest's data volume at that directory, and move the manifests back. Then I confirm nodes and workloads come back. And I test restores on a scratch cluster, because an untested backup is a hope.

A readiness probe decides whether the pod receives traffic. If it fails, the pod is removed from the Service endpoints but is not restarted. A liveness probe decides whether the container is stuck; if it fails enough times, the kubelet restarts the container. A startup probe holds off the other two until a slow app has finished booting, so a JVM that takes ninety seconds is not killed at thirty. The classic mistake is a liveness probe that checks the database. The database blips, every pod fails liveness at once, everything restarts together, and a small problem becomes an outage. I keep liveness cheap and local to the process, and use readiness for dependency checks.