Kubernetes interviews in 2026 should test how a practitioner diagnoses and operates actual workloads, not how well they recall terminology from a 2024 article. The candidate needs to connect desired objects to control-plane reconciliation, scheduling, node execution, storage and network behavior. The eighteen original questions below focus on evidence-driven technical reasoning. They are not reproduced live certification questions, and a good answer always considers the cluster’s version, network and storage plugins, and the application’s uptime requirements.<\/p>\n
For each case, state an assumption and identify the first evidence that would distinguish likely causes. A local learning cluster and a production managed service can expose the same Kubernetes APIs but have different control-plane access and operational responsibilities. Avoid promising that a single command repairs every incident. A sound troubleshooting narrative describes the observed failure, tests, safest proposed correction and confirmation that the service works again.<\/p>\n
Question 1: A Deployment has three replicas but only one Pod is Running?<\/strong> Inspect the Deployment conditions and ReplicaSet, then describe the Pending Pods and recent events. Scheduling can fail due to insufficient requests, taints, topology constraints or missing volumes. An image-pull problem occurs later and has different evidence. Use the Pod’s conditions and node status to decide which subsystem is responsible. Increasing the replica target is not a remedy when the scheduler cannot place the intended instances.<\/p>\n Question 2: An application starts but users experience errors after a rollout?<\/strong> Check the newly created ReplicaSet, readiness probes, image tags, configuration and deployment history. A successful image start does not mean the application is ready for traffic. Investigate whether the service has healthy endpoints and whether the new API contract works. Explain when a controlled rollback is appropriate and why rollback must also account for external data changes. Verify an actual user transaction rather than relying only on an available-Pod count.<\/p>\n Question 3: CrashLoopBackOff appears after a configuration change?<\/strong> Inspect exit codes, current and previous container logs, command arguments, missing dependencies and probe failures. CrashLoopBackOff describes repeated restarts; it is not a single root cause. A process might exit because of invalid configuration, an OOM kill or a liveness probe that is too aggressive. Form hypotheses using evidence and correct one cause at a time, then watch for stable operation. Do not immediately disable probes or raise all memory limits without diagnosis.<\/p>\n Question 4: A Service exists but its requests time out?<\/strong> Compare the Service’s selector with labels on intended Pods and inspect EndpointSlices for ready endpoints. Then check targetPort against the application’s listening port, namespace resolution, network path and NetworkPolicies. A valid-looking Service can have no matching ready backend. DNS resolution and packet connectivity are separate checks. Do not blame kube-proxy first when labels or Pod readiness already explain the symptom.<\/p>\n Question 5: A NetworkPolicy object has no apparent effect?<\/strong> Check whether the installed CNI enforces Kubernetes NetworkPolicy; the API object can exist without effective data-plane enforcement. Evaluate pod and namespace selectors, policyTypes and allowed ingress\/egress rules. Allowed traffic is built from additive policy permissions for selected Pods. A default-deny egress rule can also block DNS unexpectedly. Test a permitted and a rejected connection to prove effective behavior instead of treating saved YAML as proof of isolation.<\/p>\n Question 6: A node needs maintenance with minimal downtime?<\/strong> Explain cordon, drain and workload rescheduling, then examine available replicas and a PodDisruptionBudget. A PDB can constrain voluntary evictions but cannot prevent involuntary failure such as lost power. A one-replica critical service might have no safe spare capacity. If drain waits, identify the blocked eviction condition instead of forcing it immediately. Test readiness and business requests after replacements are placed before continuing maintenance to other nodes.<\/p>\n Question 7: A batch workload stays Pending despite idle-looking CPU?<\/strong> Resource requests determine scheduling feasibility, while container limits govern runtime constraints. Inspect requested CPU and memory, node allocatable resources, taints, affinities and namespace ResourceQuota or LimitRange. A dashboard might show low actual utilization yet the node has insufficient unallocated requested capacity. Lowering requests indiscriminately risks overcommit and outages later. Explain which metric the scheduler uses and how you would verify a corrected placement safely.<\/p>\n Question 8: The team needs a log agent on every eligible node?<\/strong> A DaemonSet manages eligible node-local replicas, unlike a Deployment that manages an aggregate target count. Explain node selectors, tolerations and update behavior when agents should run on specialized nodes. Test coverage when the cluster adds a node and inspect eligibility if some nodes lack the agent. DaemonSets fit monitoring, networking and security utilities; they are not automatically the right controller for a stateless API with variable replica demand.<\/p>\n Question 9: An interviewer asks what kube-scheduler actually does?<\/strong> The scheduler selects nodes for Pods that have not yet been bound, considering feasibility, constraints and relative suitability. It does not itself launch containers on the node; kubelet and the configured container runtime perform node-side work. The scheduler can consider requests, affinity, topology spread and taints. Explain why a correctly scheduled Pod can still fail to start and why controller reconciliation is separate from a placement decision.<\/p>\n Question 10: Readiness is green but the background worker is unhealthy?<\/strong> Readiness, liveness and startup probes have different purposes. Readiness usually governs eligibility for Service traffic, not the health of every background operation. Liveness failure can cause restarts; startup probes protect slow startup from premature checks. Select an endpoint that represents a useful part of the service contract rather than a trivial open socket. A Pod can be Running and Ready while users encounter failures in an untested dependency.<\/p>\n Question 11: A ConfigMap update does not affect a running process?<\/strong> Ask whether configuration entered as environment variables or mounted files. Values injected into a container environment at start generally do not change automatically in that running process. Mounted ConfigMap updates have caveats, and the application may need an explicit reload. Plan a controlled rolling restart or supported reload mechanism and verify the new behavior. Use Secret handling for sensitive values rather than placing credentials into ordinary ConfigMaps.<\/p>\n Question 12: A Secret value appears in an application log?<\/strong> Kubernetes Secrets are API objects for sensitive configuration, not an automatic guarantee of confidentiality. Exposure can arise through overly broad RBAC, logs, backups, environment variables or weak etcd protection. Review data access, encryption at rest, external secret management and rotation. The immediate correction is not merely renaming the key. Preserve necessary incident evidence without copying the sensitive value into public discussion or an AI assistant prompt.<\/p>\n Question 13: ResourceQuota exists but one team still causes contention?<\/strong> ResourceQuota constrains selected usage and objects within a namespace; it is not a cluster-wide fairness guarantee. Evaluate actual placement, limits, requested resources, priority, autoscaling and shared node capacity. A team may obey its namespace quotas while a workload still competes for local CPU or I\/O. Suggest explicit capacity planning and workload separation based on evidence rather than asserting that quota always guarantees predictable application latency.<\/p>\n Question 14: A StatefulSet Pod moves but its claim cannot be mounted?<\/strong> Inspect the PersistentVolumeClaim, volume binding, storage class, access modes and topology constraints. A volume provisioned in one zone may not attach to a node in another without a supported data path. StatefulSet provides stable identities and associations, not automatic cross-zone storage replication. A recovery approach needs data integrity, backup and workload placement planning as well as a healthy Pod object.<\/p>\n Question 15: A Helm upgrade breaks an API?<\/strong> Review chart and values versions, rendered manifests, the application’s logs and any external migrations. Helm can apply a previous release’s resources through rollback, but it does not necessarily reverse database schema changes or external state. Describe deployment gates, smoke tests, change ownership and operational recovery. Helm chart concepts<\/a> help distinguish package configuration from the application behavior that must be verified.<\/p>\n Question 16: An HPA shows high utilization but replicas do not grow?<\/strong> Inspect metrics availability, target configuration, min and max replicas, stabilization behavior and whether the workload defines requests needed for utilization metrics. Confirm new Pods can actually schedule once the replica target changes. Horizontal Pod Autoscaler adjusts application replicas; it does not directly create node capacity. A node autoscaler is a separate mechanism with its own constraints and delay. Measure service performance as well as the number of Pods.<\/p>\n Question 17: A cluster dashboard is healthy while users face latency?<\/strong> Measure application error rates, latency and throughput, then examine dependency response times, rollout history, resource saturation and endpoint behavior. Running Pods and available nodes are necessary signals but not proof of correct results. Use logs, metrics and traces together, protecting private data. Kubernetes probe semantics<\/a> help identify whether the readiness criteria actually represent useful traffic handling.<\/p>\n Question 18: Why are Docker and Kubernetes not substitutes for each other?<\/strong> Docker tools can build and run containers, while Kubernetes orchestrates containerized workloads across nodes through compatible container runtimes. Kubernetes no longer depends on the old dockershim integration with Docker Engine. A Dockerfile, container image and Deployment manifest solve different problems. Compare image production, local debugging, scheduling, service discovery and operational ownership. An effective answer avoids claiming that using Kubernetes removes the need to understand container images or application processes.<\/p>\n Reproduce two or three of the scenarios in an authorized disposable cluster. Create a Service whose selector does not match its Pods, a Deployment requesting more resources than a node can place, or a benign readiness failure. Inspect resources with kubectl get, describe, logs and events, then save the manifest and a short incident timeline. Record which observation supported your final cause and how you confirmed recovery. The Kubernetes component architecture<\/a> becomes easier to remember when tied to this evidence.<\/p>\nQuestions 5\u20139: Network policy, scheduling and node maintenance<\/h2>\n
Questions 10\u201314: Health probes, configuration and state<\/h2>\n
Questions 15\u201318: Helm, scaling and performance<\/h2>\n
Turn scenario answers into hands-on interview evidence<\/h2>\n