Why this topic matters in interviews
Kubernetes troubleshooting interviews test practical thinking. Interviewers expect you to move from symptom to root cause using kubectl, events, logs, resource checks and architecture knowledge.
15 interview questions to prepare
Check events, node capacity, taints/tolerations, node selectors, affinity, PVC binding, quotas and scheduler messages.
Check logs, previous logs, command/args, config, secrets, dependencies, probes and resource limits.
Check image name, tag, registry access, pull secrets, network, authentication and image existence.
Check service selector, endpoints, pod labels, pod readiness, ports, kube-proxy/network plugin and NetworkPolicy.
Endpoints show which pod IPs are selected by a service. Empty endpoints often means selector mismatch or pods not ready.
Check ingress resource, ingress class, controller pods, service backend, DNS, TLS secret, events and controller logs.
Check CoreDNS pods, service names, namespace, resolv.conf, NetworkPolicy and test with nslookup from a debug pod.
DaemonSet runs one pod per selected node, commonly for logging, monitoring, networking and node agents.
Readiness controls traffic; liveness restarts unhealthy containers; startup probe protects slow-starting apps.
Check node conditions, kubelet logs, disk, memory, image garbage collection, evictions and pod resource requests.
Use rollout history and rollout undo, but also fix Git/CI source-of-truth if using GitOps.
Memory usage exceeds container limit. Check limits, application memory behavior and metrics.
Check namespace/pod labels, ingress/egress rules, DNS, service selectors and test connectivity from debug pods.
Check app metrics, pod resources, node pressure, dependencies, DNS latency, ingress, database and network latency.
A structured flow: describe symptom, inspect resources, check events/logs, isolate layer, fix, validate and prevent recurrence.