13 Kubernetes Admin Interview Questions That Test Operational Thinking

A DevOps engineer I know – four years of production Kubernetes experience – failed a panel at a Series B fintech last spring. He got stuck on RBAC scoping for multi-tenant workloads and couldn’t explain the reasoning behind his past choices. The interviewers weren’t testing whether he knew kubectl. They wanted to understand how he thought about operational risk.

That’s the actual interview. The 2025 CNCF Annual Cloud Native Survey found that 82% of container users now run Kubernetes in production, up from 66% in 2023. More people are competing for K8s admin roles, and the interviews have sharpened to match. What follows are 13 questions that actually separate strong candidates from people who’ve only run managed clusters under one team’s workloads.

Control Plane and Pod Lifecycle

1. Walk me through what happens when you run kubectl apply -f deployment.yaml.

Most candidates name the components. Strong ones trace the flow: API server authenticates and validates, writes desired state to etcd, controller manager detects the delta, scheduler assigns pods, kubelet calls the container runtime. It falls apart when the interviewer asks what happens if etcd is unavailable. The answer – API server rejects writes, existing workloads keep running, no new scheduling – tells you whether someone’s operated a cluster under real pressure.

2. What’s the difference between a liveness probe and a readiness probe, and how would a misconfiguration cause an outage?

Liveness probes tell the kubelet to restart a container. Readiness probes tell the service to stop sending it traffic. The classic mistake: setting a liveness probe with a 5-second initial delay on a service that takes 30 seconds to initialize. The kubelet kills it. It restarts. Repeat until you have an alert firing at 2am. The readiness failure mode runs the other direction – traffic keeps routing to a pod that’s actually unhealthy because the probe threshold was set too loosely.

3. How does the Kubernetes scheduler decide which node to place a pod on?

Two phases: filtering (eliminates nodes that can’t meet resource requests, taints, affinity rules) and scoring (ranks the remaining). Candidates who’ve tuned scheduling in production will mention that nodeAffinity and podAntiAffinity interact in non-obvious ways when spreading pods across AZs for HA. If they’ve never had to do that, they probably haven’t needed to think hard about this.

Networking

4. A pod can’t reach another pod in a different namespace. Where do you start?

Check if a NetworkPolicy is blocking the traffic (most common cause). Then verify DNS resolution with a kubectl exec into a debug pod running nslookup. Confirm the service and endpoints objects look correct. Then check CNI logs if you’re still stuck. The key knowledge here: Kubernetes DNS names follow a predictable pattern (service.namespace.svc.cluster.local), and NetworkPolicies are additive and default-deny if any policy selects the pod.

5. How do you implement network segmentation between teams on a shared cluster?

The baseline is NetworkPolicies per namespace with default-deny ingress. The part candidates miss: NetworkPolicies require a CNI that enforces them. Flannel doesn’t. Calico and Cilium do – Cilium uses eBPF in newer versions, which changes the performance profile significantly. A team that ran Flannel and assumed their NetworkPolicies were active had silently open network paths for months. That’s a real thing that’s happened to real teams.

6. What’s the difference between ClusterIP, NodePort, and LoadBalancer? When would you use an Ingress?

ClusterIP is internal-only. NodePort exposes on a static port on every node – fine for local dev, not production. LoadBalancer provisions a cloud load balancer for L4 traffic. Ingress handles L7 HTTP/S routing behind one external endpoint. The follow-up that reveals experience: “What if you need WebSocket support through your Ingress controller?” nginx needs an annotation; Traefik handles it natively. Candidates who’ve run HTTP workloads in production know this without looking it up.

Storage, RBAC, and Security

7. When would you choose a StatefulSet over a Deployment?

StatefulSets give stable network identity, stable storage per pod via volumeClaimTemplates, and ordered startup. The gotcha follow-up: “What happens to the PVC if you delete a StatefulSet?” The PVC is not deleted by default – it’s retained. Candidates who assume it’s garbage collected either lose data or accumulate storage costs they don’t notice for a while.

8. How do you back up a production cluster?

Two things to back up: cluster state (etcd snapshots) and persistent volume data. Etcd snapshots cover Kubernetes object definitions – they don’t contain application data. PVs need separate backup, typically via CSI volume snapshots or Velero, which handles both manifests and PV data. A candidate who only mentions etcd hasn’t thought about the data layer. One who only mentions Velero hasn’t thought about what happens when the control plane itself is gone.

9. How do you design RBAC for a multi-team cluster?

One namespace per team, with a ClusterRole scoped to that namespace and bound via RoleBinding (not ClusterRoleBinding, which grants cluster-wide access). CI/CD service accounts get separate minimally-scoped Roles. Enable audit logging and alert on any create against rolebindings by non-admin subjects. I think most teams under-invest in RBAC auditing. You can have clean policy definitions and still get burned by a misconfigured binding that went undetected for months.

10. What replaced PodSecurityPolicies and how do you use it?

PSPs were deprecated in 1.21 and removed in 1.25. The replacement is Pod Security Admission with three levels: Privileged (no restrictions), Baseline (blocks known privilege escalation), and Restricted (hardened, requires non-root). Enforced at namespace level with labels. The migration isn’t always clean – PSPs allowed per-ServiceAccount permissions the new model doesn’t support. Some teams added OPA/Gatekeeper to fill that gap.

11. How do you manage secrets without storing plaintext in etcd?

Two approaches: encryption at rest via the EncryptionConfiguration API (encrypts secrets in etcd using AES-GCM), or external secret management via the External Secrets Operator syncing from AWS Secrets Manager, Vault, or GCP Secret Manager. External secrets is generally better for teams with existing secret management infrastructure because you get audit trails and rotation outside the cluster. Storing secrets as base64 in Git and syncing with Flux is a pattern I’ve seen in the wild. It’s not adequate security, but it exists.

Troubleshooting and Autoscaling

12. A cluster node is in NotReady state. Walk through your diagnosis.

Start with kubectl describe node <name> to check conditions: MemoryPressure, DiskPressure, PIDPressure. Then SSH and check kubelet logs (journalctl -u kubelet -f). Most NotReady states come from the kubelet failing to reach the API server or the container runtime being down. The OOM case looks different from the network case in the logs, and candidates who’ve done this in production know which lines to look for.

13. How do you autoscale a service with unpredictable traffic spikes?

HPA scales on CPU by default, which works for CPU-bound services. For queue-driven or latency-sensitive workloads, you need custom metrics – KEDA (Kubernetes Event-Driven Autoscaling) can scale on SQS queue depth, Kafka lag, or a Prometheus query. One thing that trips teams up: HPA and VPA should not both target CPU on the same deployment. They conflict. Pick one for horizontal scaling, or use KEDA for horizontal and VPA for memory recommendations only.

How interviewers are actually calibrating

The 2024 Stack Overflow Developer Survey found that 22% of professional developers use Kubernetes – a wide population with widely varying depth. Interviewers calibrate quickly on whether you’ve operated a cluster in production or just read the docs.

People who pass these interviews mention specific failure modes they’ve actually hit. They say “we had a case where…” and describe a real incident. If you haven’t had those incidents yet, the preparation strategy that works is working through the “what breaks if you configure this wrong” angle on every topic above. It’s a reasonable proxy for operational experience, and it’s the layer most candidates skip.

For the adjacent skills that show up in the same panels, the system design interview guide covers distributed systems and failure mode reasoning that K8s admin interviews draw on directly. If you’re targeting cloud-focused roles at AWS shops, the AWS cloud interview questions post covers managed Kubernetes on EKS, which comes up more than candidates expect. And for the broader platform engineering picture, cloud architect interview questions covers the infrastructure thinking that overlaps with senior K8s admin panels.