Kubernetes Interview Questions for DevOps, SRE, and Platform Engineers

What Interviewers Are Looking For

Strong Kubernetes answers connect an API concept to runtime behavior and failure modes. Saying "a Service provides networking" is weaker than explaining selectors, EndpointSlices, readiness, and how you would isolate a timeout. Structure scenario answers as observation, hypothesis, test, and safe remediation.

1. A Pod is Running but receives no traffic. What do you check?

Running is only the Pod phase. Check READY, Pod conditions, and readiness events. Then inspect the Service selector and EndpointSlices:

kubectl -n app get pod -l app=api --show-labels
kubectl -n app describe pod <pod>
kubectl -n app get svc api -o yaml
kubectl -n app get endpointslice -l kubernetes.io/service-name=api

If endpoints exist, test the Pod IP and Service name from another Pod. A wrong targetPort, process bound only to localhost, NetworkPolicy, or service-routing failure each produces different evidence.

2. What happens when you create a Deployment?

The API server validates and stores the object. The Deployment controller observes desired state and creates a ReplicaSet; the ReplicaSet creates Pods. The scheduler binds unscheduled Pods to nodes. Kubelets on those nodes ask the container runtime to prepare images and containers, mount volumes, and report status. Controllers continuously reconcile - this is not a one-time command chain.

3. Requests versus limits - why do both matter?

The scheduler uses requests to find a node with sufficient allocatable capacity. Limits are runtime ceilings: CPU is throttled; exceeding a memory limit can lead to OOM termination. Requests also influence QoS and CPU-based HPA calculations. A tiny request can make utilization percentages look high and pack too many Pods; an inflated request can leave Pods Pending while nodes appear underused.

4. Readiness, liveness, and startup probes?

Readiness controls whether an endpoint should receive Service traffic. Liveness asks whether the container needs restarting. Startup protects a slow-starting container by suppressing the other probes until initialization succeeds. A database outage should not usually fail liveness because restarting every client does not repair the database and may worsen recovery.

5. Why is a Service stable if Pod IPs change?

The Service has a stable virtual IP and DNS name. Its selector associates it with Pods, represented through EndpointSlices. The cluster's service-routing implementation directs traffic to eligible endpoints. Readiness normally removes unhealthy Pod addresses from serving traffic without changing the Service name.

6. A Pod is Pending. Walk through the diagnosis.

Start with kubectl describe pod and scheduler events. Common messages identify insufficient requested CPU/memory, unmatched node selectors or affinity, untolerated taints, and topology constraints. If a node is already assigned, inspect image-pull and volume-mount events plus PVC status. Do not "fix" a placement constraint until you know why it exists.

7. Deployment versus StatefulSet?

Deployment replicas are interchangeable and are normally addressed through a Service. StatefulSet replicas have stable ordinals, stable network identity through a headless Service, ordered behavior, and per-replica volume claim templates. StatefulSet supplies identity, not database correctness: leader election, replication, backup, quorum, and safe failover remain application or operator concerns.

8. How do you perform a safe rollout and rollback?

Use immutable image identifiers, meaningful readiness, appropriate maxUnavailable and maxSurge, enough cluster capacity, and a PodDisruptionBudget for voluntary disruptions where appropriate. Validate with server-side dry-run and diff, apply declaratively, then watch kubectl rollout status, availability metrics, errors, and latency. kubectl rollout undo restores an earlier Pod template, but cannot reverse schema migrations or external side effects.

9. Why might an HPA never scale on CPU?

Check that the metrics API works, the HPA can read metrics, target Pods have CPU requests, and load reaches those Pods. CPU utilization is current usage divided by requested CPU. Missing requests can make utilization unavailable; inaccurate requests distort the signal. Also inspect stabilization and scaling policies, min/max replicas, and whether a rollout or readiness failure keeps metrics absent.

kubectl -n app describe hpa checkout
kubectl -n app top pods -l app=checkout
kubectl -n app get deploy checkout -o yaml

10. How does RBAC scope work?

Roles are namespaced. ClusterRoles can represent cluster-scoped permissions or reusable namespace permissions. A RoleBinding grants a Role or ClusterRole inside one namespace; a ClusterRoleBinding grants a ClusterRole cluster-wide. Permissions are additive, with no RBAC deny. Test the exact service account using kubectl auth can-i, including negative cases such as Secret reads and Pod deletion.

11. ConfigMap versus Secret?

Both hold configuration and can be exposed through environment variables or volumes. Secret data is base64-encoded at the API boundary, not inherently encrypted. Protect Secrets with RBAC, encryption at rest, external secret workflows where appropriate, and careful logging. Mounted configuration can update eventually, while environment variables require a Pod restart; applications must also reload files to use changes.

12. What does a PodDisruptionBudget protect against?

A PDB limits simultaneous voluntary disruptions, such as node drains, by specifying minimum available or maximum unavailable Pods selected by labels. It does not prevent node crashes, application failures, or a controller rollout from all failure modes. A PDB with insufficient replicas can block maintenance, so pair it with realistic replica counts and capacity.

13. How would you debug CrashLoopBackOff?

Read the last termination reason and exit code, then kubectl logs --previous. Inspect events, command and args, configuration, mounts, probes, and resources. Exit 137 plus OOMKilled points toward memory; probe events point toward kubelet restarts; exit 0 may mean a one-shot process was placed under a controller expecting a long-running service. Change the owning controller, not the disposable Pod.

14. NetworkPolicy was added and traffic stopped. What next?

Confirm which Pods the policy selects and whether ingress, egress, or both became isolated. Verify source namespace and Pod labels, destination port, and DNS egress. Remember that selectors in one from item are ANDed, while separate items are ORed. Test from the actual source workload and verify the cluster's CNI enforces policy.

15. What would you monitor for a production workload?

Monitor user signals first: availability, latency, errors, and throughput. Add desired versus available replicas, restart and termination reasons, pending duration, scheduling failures, CPU throttling, memory working set, OOM kills, HPA state, probe failures, request saturation, and dependency health. Kubernetes object status is necessary context, not a substitute for application telemetry.

Turn these answers into muscle memory in the Kubernetes command sandbox, the 20 Kubernetes incident labs, and the structured Kubernetes theory course.