Kubernetes Interview Questions for 5 Years Experience
10 real questions, pulled straight from HamChops's Containerization, Wasm & Kubernetes chapter — scenario-based, not trivia.
A Java microservice takes approximately 90 seconds to initialize its Spring context and establish database connections before it can serve requests. After startup, the service occasionally enters a deadlock state due to a known thread-pool bug that requires a restart to fix. Your team has configured only a liveness probe with initialDelaySeconds: 10 and periodSeconds: 5. In production, you observe the Pod restarting in a loop and never becoming healthy. What is the root cause, and what is the correct fix?
The liveness probe starts checking at 10 seconds, but the app takes 90 seconds to initialize. The probe fails repeatedly during initialization, causing Kubernetes to restart the container before it ever finishes booting — a crash loop. The fix is to add a Startup Probe with a failureThreshold and periodSeconds that together allow at least 90 seconds (e.g., failureThreshold: 18, periodSeconds: 5). The liveness probe should remain to catch deadlocks after startup.
You are deploying a critical payment processing service with 50 replicas. Your SLA requires that the service never drops below 90% of its normal request-handling capacity during a deployment. Your team also wants the rollout to complete as quickly as possible without violating the SLA. How would you configure maxSurge and maxUnavailable? Justify your choices.
Set maxUnavailable: 10% (5 Pods) and maxSurge: 25% (12–13 Pods). The maxUnavailable: 10% ensures at least 45 of 50 Pods (90%) are always available, satisfying the SLA. A higher maxSurge (25%) allows Kubernetes to spin up many new Pods in parallel before terminating old ones, maximizing rollout speed. The two parameters are independent — you can be conservative on availability while being aggressive on surge.
A team deploys a new version of their application by creating a second Deployment named my-app-v2 with the Pod label app: my-app, version: v2. Their existing Service has the selector app: my-app. After the new Deployment is running, they notice that traffic is being split between the old v1 Pods and the new v2 Pods unexpectedly — they intended v2 to be a dark deployment receiving no traffic. What is the cause, and how do you fix it without deleting either Deployment?
The Service selector app: my-app matches Pods from both Deployments because both have the app: my-app label. To exclude v2 Pods from the Service, add a more specific label to the v1 Pods (e.g., version: v1) and update the Service selector to app: my-app, version: v1. The v2 Pods will then not match the selector and receive no traffic until you deliberately update the Service selector to include them.
Your team runs a three-node Elasticsearch cluster on Kubernetes. The cluster requires that nodes discover each other using stable DNS names, and each node must retain its index data if it is rescheduled to a different physical server. A junior engineer suggests using a Deployment with 3 replicas and a standard ClusterIP Service. What specific failure modes would this cause, and what workload type should be used instead?
A Deployment would assign random Pod names and random PVC bindings, breaking peer discovery (Elasticsearch nodes can't find each other via stable DNS) and causing data loss on rescheduling (a new Pod gets a new empty volume). A StatefulSet with a Headless Service and volumeClaimTemplates is the correct choice — it provides stable ordinal names for DNS-based peer discovery and ensures each Pod always reattaches to its own persistent volume.
Your cluster is completely full. A new Pod B is submitted with priorityClassName: production-critical (value 1000000) and QoS class BestEffort (no resource requests or limits set). The only running Pod that could be evicted to make room is Pod A, which has priorityClassName: background-batch (value 1000) and QoS class Guaranteed (requests equal limits). Your team argues that Pod A should be safe because it's Guaranteed. Are they correct? What actually happens?
Your team is incorrect. Pod A will be preempted. Priority (1000000 > 1000) determines preemption, not QoS class. Pod A is evicted to make room for Pod B despite Pod A being Guaranteed and Pod B being BestEffort.
A team applies the following two NetworkPolicy resources to their app namespace. After applying them, their worker Pods (labeled role=worker) can no longer resolve DNS names — nslookup google.com from inside a worker Pod times out. However, the worker Pods can still reach the api Service on port 8080.
Policy 1 — default-deny-egress:
yaml
spec:
podSelector: {}
policyTypes: ["Egress"]
Policy 2 — allow-worker-to-api:
yaml
spec:
podSelector:
matchLabels:
role: worker
policyTypes: ["Egress"]
egress:
- to:
- podSelector:
matchLabels:
app: api
ports:
- protocol: TCP
port: 8080
What is the root cause of the DNS failure, and what change fixes it?
The egress policy for worker Pods allows traffic to the api Service on port 8080 but does not include a rule allowing UDP port 53 traffic to CoreDNS. The default-deny policy blocks all other egress, including DNS queries. Adding an egress rule that allows UDP/TCP port 53 to the kube-system namespace (where CoreDNS runs) fixes the issue.
Your organization is deploying a multi-tenant Kubernetes cluster on bare-metal servers in an on-premises data center. The cluster will host workloads from three different internal business units, each in their own namespace. Security requirements mandate strict network isolation between namespaces, and the operations team wants deep visibility into which Pods are communicating with which — including the ability to see Layer 7 (HTTP) traffic metadata without deploying a full service mesh.
The infrastructure team has confirmed that the physical network switches support BGP. The cluster is expected to grow to 500 nodes within 18 months.
Which CNI plugin would you recommend, and what is your reasoning? What are the key trade-offs of your choice?
Cilium is the strongest choice for this scenario. It supports Network Policies for namespace isolation, uses eBPF for high performance at 500-node scale (avoiding iptables rule explosion), and provides native Layer 7 observability (HTTP, gRPC, DNS) through Hubble — without requiring a separate service mesh. BGP support is available via Cilium's BGP Control Plane for native routing on the existing infrastructure.
Your team runs a production PostgreSQL database on Kubernetes. The database PVC was dynamically provisioned using a StorageClass with reclaimPolicy: Delete. A junior engineer, following a runbook to "clean up old PVCs," deletes the PVC named postgres-data. The database Pod immediately crashes. You check kubectl get pv and see no PVs listed. kubectl get pvc shows no PVCs. The cloud console confirms the underlying EBS volume no longer exists. The last known good backup is from 6 hours ago. What immediate steps do you take, and what process change prevents this in the future?
Immediate steps: restore from the 6-hour-old backup to a new PVC, accept the data loss for the last 6 hours, and communicate the incident. Prevention: change the StorageClass reclaimPolicy to Retain for production databases, implement RBAC to restrict PVC deletion in production namespaces, and add PVC deletion to change management processes requiring approval.
Your team is performing a Kubernetes upgrade on a production cluster. A junior engineer suggests skipping the pre-upgrade etcd backup because "we can just redeploy everything from our Helm charts and GitOps repo if something goes wrong." Your senior architect disagrees strongly. Who is correct, and what critical cluster state would be lost that cannot be recovered from Helm charts or a GitOps repository?
The architect is correct. While application manifests can be redeployed from Helm/GitOps, etcd contains state that cannot be reconstructed from source control: all Secrets (including TLS certificates and credentials), RBAC bindings, ServiceAccount tokens, PersistentVolumeClaims and their binding to specific PersistentVolumes, and any runtime state created by operators or controllers. Losing this state means the cluster must be rebuilt from scratch, not just redeployed.
Your team runs helm upgrade my-api ./api-chart -f prod-values.yaml in your CI/CD pipeline. The command exits with an error: "Error: UPGRADE FAILED: cannot patch 'my-api-deployment' with kind Deployment: Deployment.apps is invalid: spec.selector: Invalid value: ... field is immutable." The deployment was working fine before. What is the most likely cause, and how would you resolve it?
A label in the Deployment's spec.selector was changed in the chart templates. Kubernetes does not allow immutable fields like spec.selector to be modified after a resource is created. The fix is to delete the existing Deployment (or the entire release) and reinstall, or use helm upgrade --force which deletes and recreates resources that cannot be patched.
Want the rest of Containerization, Wasm & Kubernetes?
This is 10 of hundreds of concept reviews in this chapter alone — plus 17 more chapters, with fast daily review built in.
See pricing