Kubernetes Interview Questions and Answers for 2026

Answer: Kubernetes is a container orchestration platform: it schedules containers across a fleet of machines, restarts what dies, scales on demand, and exposes stable networking, all driven by declared desired state. The problem it solves is running many containers reliably across many hosts, which manual scripting cannot do once you add failures, deploys, and scaling to the picture. That desired-state framing is the answer most Kubernetes interview questions are fishing for at the start.

Answer: A pod is the smallest schedulable unit: one or more containers sharing network namespace, IP address, storage volumes, and lifecycle. Containers that are one application, like an app plus its log shipper, share localhost and volumes natively inside a pod. Units that scale independently should not share one, which is the design question the follow-up always asks.

Answer: The API server is the front door for every read and write; etcd stores cluster state; the scheduler assigns unscheduled pods to nodes; the controller manager runs reconciliation loops; on nodes, the kubelet drives containers and reports status. Cloud setups add a cloud controller manager for load balancers and disks. Naming the owner of each function is what this classic among Kubernetes interview questions grades.

Answer: Etcd is a distributed key-value store holding every object in the cluster, the single source of truth. Lose quorum and the cluster keeps serving existing pods but accepts no writes. It wants odd membership for quorum, low-latency disks, and real backups, which is why etcd health and backup questions are permanent residents of Kubernetes interview questions.

Answer: It is the node agent: watches the API server for pods assigned to its node, drives the container runtime to match the pod spec, runs probes, mounts volumes, and reports node and pod status back. If the kubelet is unhealthy, the node gets marked NotReady and its pods get evicted, which is the operational consequence worth adding.

Answer: create makes a new object and fails if it exists; apply declares the full desired state and updates the object if it exists, using a merge that tracks what you last applied. Declarative apply is how GitOps and every pipeline works, so say that sentence: apply is repeatable, create is one-shot. This distinction opens many practical Kubernetes interview questions because pipelines live and die by it.

Answer: kubectl get pod NAME for status and restarts, kubectl describe pod NAME for events at the bottom, which reveal image pull failures, scheduling failures, and probe kills, then kubectl logs NAME plus -p for the previous container instance if it is crash-looping. Describe-then-logs is the reflex order Kubernetes interview questions on debugging want to hear.

Answer: A namespace partitions objects inside one cluster: names only need uniqueness per namespace, RBAC and quotas attach per namespace, and default ones like kube-system hold the cluster’s own machinery. Teams use them per environment slice or per team. They are not a security boundary by themselves, which is the nuance sharp candidates add.

Answer: A Deployment declares a desired pod template and replica count, then manages revisions through ReplicaSets: rollouts happen gradually, old ReplicaSets are kept for rollback, and history is inspectable with kubectl rollout history. Raw pods have no such supervision; a deleted pod is gone, while a Deployment’s pod is replaced automatically. Deployments are the default workload in Kubernetes interview questions, so know their revision mechanics cold.

Answer: A ReplicaSet keeps N identical pods alive by continuously reconciling count against its selector. You almost never write one directly; a Deployment creates and owns them per revision, which is why deleting a pod’s ReplicaSet while its Deployment lives is a self-healing exercise in futility. Ownership chains come up constantly in Kubernetes interview questions, and this is the canonical example.

Answer: kubectl scale deploy web --replicas=5, or edit the manifest and apply, or let an HPA do it. Underneath, the ReplicaSet reconciles the new count, the scheduler binds new pods, and the Service picks them up by label automatically. The detail that earns credit: scaling is safe precisely because pods are cattle, interchangeable members of a labeled set. Cattle vocabulary sounds flippant, but it is the exact mental model Kubernetes interview questions on scaling reward.

Answer: Changing the pod template makes the Deployment create a new ReplicaSet; it scales the new one up and the old one down in steps bounded by maxSurge and maxUnavailable, honoring readiness probes before proceeding, and it stops and reverts if the new version never becomes healthy within the progress deadline. Old ReplicaSets stay behind as rollback material, which is why rollout undo is instant.

Answer: ClusterIP gives an internal virtual IP, the default for service-to-service traffic. NodePort opens a static port on every node for crude external access. LoadBalancer provisions a real external load balancer through the cloud integration. ExternalName is a DNS CNAME alias to something outside the cluster. Ingress or Gateway resources sit in front of ClusterIP services for real HTTP routing, a point most Kubernetes interview questions expect you to make.

Answer: By a label selector: the Service continuously watches for pods whose labels match, tracks them in its endpoints, and load balances across them. Labels are the join key of the whole platform, which is why a one-character selector typo producing zero endpoints is the most classic bug in Kubernetes interview questions.

Answer: Labels are identifying key-value pairs used for selection and grouping: selectors, scheduling constraints, rollout segmentation. Annotations are non-identifying metadata for tools and humans: checksums, ingress controller config, links to runbooks. The dividing line to state: if something selects or groups by it, it is a label; everything else is an annotation.

Answer: A ConfigMap holds non-secret configuration as key-value pairs or whole files. Pods consume it as environment variables, as command arguments, or as files mounted from a volume. The operational nuance worth adding: env-var injection happens at pod creation, so config changes require a pod restart, while volume-mounted files update in place, subject to the sync delay. The restart implication is the part of this topic that Kubernetes interview questions always dig for.

Answer: A Secret is a ConfigMap-shaped object intended for sensitive data, and its values are merely base64 encoded, not encrypted, by default. Real secrecy comes from the surroundings: RBAC limiting who reads it, encryption at rest for etcd, or an external secret operator syncing from a vault. Saying that plainly is exactly what this item in Kubernetes interview questions wants, because the base64-equals-secure myth is the trap.

Answer: The liveness probe answers is this container deadlocked? and failing it restarts the container. The readiness probe answers can this pod serve traffic right now? and failing it removes the pod from Service endpoints without restarting anything. Mixing the two up is the most common probe bug, and one of the most reliable differentiators in Kubernetes interview questions, because a heavy liveness check creates restart storms under load.

Answer: A request is what the scheduler reserves on a node and what CPU weighting uses; a limit is a ceiling the runtime enforces. Memory over its limit means OOMKill; CPU over its limit means throttling, not death. The interview-grade summary: requests shape placement, limits shape punishment, and skipping requests breaks both scheduling and autoscaling. That summary sentence is the expected shape of the answer in Kubernetes interview questions on resources.

Answer: A StatefulSet provides stable pod names, ordered deployment and scaling, and per-pod persistent storage that survives rescheduling, the contract databases and quorum systems need. Web frontends stay on Deployments; ZooKeeper, Kafka, and friends get StatefulSets. Expect Kubernetes interview questions to ask why databases are hard here: identity and storage, exactly those two guarantees.

Answer: A DaemonSet runs one pod per node, or per matching subset with node selectors or affinities, and keeps it that way as nodes come and go. It is the shape of log collectors, node exporters, CNI plugins, and every other per-host agent. New nodes get the agent automatically, which is the operational point to state.

Answer: A Job runs pods to completion, restarting on failure per its backoff policy, and tracks success; a CronJob creates Jobs on a schedule in standard cron syntax. Useful knobs: completions and parallelism for batches, activeDeadlineSeconds to cap runtime, and concurrencyPolicy to stop overlapping runs, the detail that shows you have run real schedules.

Answer: Phases are Pending, Running, Succeeded, Failed, and Unknown. Pending is normal briefly but chronic Pending means scheduling or image trouble; CrashLoopBackOff is not a phase but a status reason worth learning on sight; Unknown usually means the node stopped talking. Learning to read kubectl get pods columns is honestly half of practical Kubernetes interview questions on operations.

Answer: Init containers run to completion in order before the app containers start, each blocking the next, with their own images and tools. They own setup: waiting for dependencies, migrating schemas, templating config from a volume. They must succeed for the pod to proceed, which makes them the clean answer to any ordering problem in Kubernetes interview questions about startup.

Answer: A sidecar runs alongside the app container in the same pod, extending it without touching it: log shippers, proxies, auth agents, secret refreshers. They share the pod’s network and volumes, so they integrate over localhost and files. Kubernetes now also supports native sidecar-style init containers with restartPolicy: Always, which solves the ordered shutdown problem the old pattern had.

Answer: An emptyDir volume is scratch space sharing the pod’s lifetime: created with the pod, destroyed with it, useful for scratch files, checkpoints between containers in the pod, or memory-backed tmpfs with medium: Memory for ephemeral sensitive data. It never survives rescheduling, which is the boundary against PersistentVolume claims you should state. Scratch versus durable is the axis this entry in Kubernetes interview questions is really testing.

Answer: It tunnels one local port through the API server to a pod or service port, for human debugging: hit a dashboard, curl an internal endpoint, poke a database from a GUI. It is a developer convenience, single-connection-minded and unsuitable for production traffic, and saying that boundary is the second half of the answer.

Answer: A kubeconfig holds clusters, users, and contexts, and a context binds the three; kubectl config use-context or the KUBECONFIG env var switches between them. Merge multiple files by colon-separating KUBECONFIG. The caution that belongs in this answer: always check kubectl config current-context before destructive work, because the wrong context is how people delete production.

Answer: kubectl apply --dry-run=client validates syntax locally, and --dry-run=server sends the object through the API server’s validation and admission without persisting, catching schema errors and policy rejections before they are real. Pair it with kubectl diff in CI to show humans exactly what would change, which is the pipeline-grade habit this question is checking.

Answer: Every object lives in an API group and version: core objects in v1, workloads in apps/v1, and newer features progress alpha to beta to stable, with deprecation policies promising migration time. In manifests you pin the version, and tools like kubectl explain show the live schema. Version churn awareness matters in upgrades, which is where Kubernetes interview questions usually take this topic.

Answer: A Service is layer 4 load balancing with a stable cluster IP; an Ingress is a layer 7 routing ruleset, host and path based, that needs a controller, nginx, Traefik, or a cloud one, to implement it, usually fronting several services over one load balancer and one TLS certificate. The Gateway API is the newer, role-separated successor worth mentioning by name in current Kubernetes interview questions.

Answer: A service gets a DNS name of the form service.namespace.svc.cluster.local, resolvable from any pod in the cluster; pods get reverse records and, with certain settings, per-pod names in headless services. CoreDNS implements it, and short names resolve only within the same namespace, which is the detail that explains a large share of connection bugs behind Kubernetes interview questions.

Answer: delete removes the object entirely, letting controllers clean up dependents; patch surgically modifies a live object, strategic-merge or JSON merge, without sending the whole manifest. Patching is also how non-declarative one-off fixes happen, and the honest operational note is to fold any emergency patch back into Git before the drift bites.

Answer: kubectl explain pod.spec.containers prints the live schema from the API server itself, including field docs and the --recursive view, so it is always accurate for your exact cluster version. It replaces documentation guessing under pressure, which is why fluent users answering Kubernetes interview questions often mention it as their first tool on an unfamiliar field.

Answer: Always, OnFailure, and Never, with Always the only legal value for Deployment-managed pods. Jobs use OnFailure or Never because their whole contract is running to completion and reporting a result. Restart counting interacts with backoff delays, which is where CrashLoopBackOff’s growing waits come from, a link worth making out loud.

Answer: Contexts bundle cluster, credentials, and default namespace. The safety pattern: set distinct context names per environment, use namespace flags or per-shell defaults, and develop the reflex of config current-context before every risky command. Interviewers asking Kubernetes interview questions about operations are partly probing whether that reflex exists.

Answer: Events are the cluster’s narrated diary: scheduling failures, image pulls, probe kills, evictions, each with reasons and counts. Make them useful with kubectl get events -A --sort-by=.lastTimestamp, or field-selectors per object. In scenario rounds, reading events in order is frequently the fastest route to root cause, which is why this command stars in Kubernetes interview questions about debugging.

Answer: The runtime pulls images, creates containers, and manages their lifecycle against the CRI interface: containerd and CRI-O are the standard choices, with Docker Engine now driving clusters through containerd underneath. Know the layering sentence: kubectl talks to the API server, the kubelet talks CRI to the runtime, and the runtime talks to the kernel, because that chain organizes half of Kubernetes interview questions about where behavior comes from.

Answer: Controllers open a watch against the API server and cache objects locally in an informer store, receiving incremental events instead of polling. Work queues process deltas, and status writes flow back through the API server. The consequences worth naming: watches scale far better than list-and-poll, the informer cache is why controllers seem psychic, and resourceVersion bookkeeping is what makes the whole stream reliable. Watch mechanics underpin most behavior questions in Kubernetes interview questions, from HPA speed to event lag.

Answer: In two phases: filtering removes nodes that cannot fit, insufficient CPU or memory, taints without tolerations, node selectors and affinity misses, unsatisfiable topology spread; scoring ranks the survivors on spread preferences, image locality, and other weights, and the highest score wins the binding. If every node is filtered out, the pod sits Pending, which connects this answer directly to the scenario tier of Kubernetes interview questions.

Answer: Node affinity steers pods toward or away from node labels, with required rules that gate scheduling and preferred rules that only weight it. Pod affinity and anti-affinity work between pods: co-locate by topology domain, or spread replicas apart for availability. The practical pairing interviewers like: node affinity for hardware or zone constraints, pod anti-affinity or topology spread for keeping replicas from sharing a failure domain.

Answer: A taint marks a node to repel pods that do not tolerate it: kubectl taint node n1 key=value:NoSchedule, with effects NoSchedule, PreferNoSchedule, and NoExecute, the last one evicting already-running pods. Tolerations on pods opt into those taints. The conceptual line to state: affinity attracts pods to where they should run, taints repel them from where they should not, and dedicated node pools are the classic use.

Answer: cordon marks a node unschedulable for new pods; drain cordons plus evicts existing ones, respecting PodDisruptionBudgets and ignoring DaemonSet pods with a flag; uncordon returns it to service. Drain is the node-repair and upgrade workflow, and the phrase Kubernetes interview questions listen for is that drain is polite eviction, not deletion, so controllers recreate the pods elsewhere.

Answer: Guaranteed, requests equal limits for every container; Burstable, requests set below limits; BestEffort, neither set. Under node memory pressure the kubelet evicts in reverse order: BestEffort first, Burstable exceeding requests next, and Guaranteed last, while OOM scores follow the same logic at the kernel level. This question is where Kubernetes interview questions check whether you understand why requests are not optional in production.

Answer: OOMKilled is the kernel cgroup memory limit firing: that container exceeded its limit and the kernel killed it, visible as reason OOMKilled, often exit code 137. Eviction is the kubelet or scheduler removing pods for node-level causes: memory or disk pressure, drain, over-budget disruptions. The fix differs completely, a limit problem is rightsizing, an eviction problem is node health or PDB design, so diagnosing which one you have is the whole game.

Answer: The kernel enforces CPU limits in time slices per period, so a bursty container that wants more gets hard-stopped at its quota, adding latency without any visible saturation, the notorious throttling trap for latency-sensitive services. Common practice: always set requests, set memory limits to catch leaks, and be deliberate about CPU limits, since throttling is silent. Metrics beat doctrine here, and saying so reads well.

Answer: The startup probe gates the other two until the container has booted, ideal for slow JVMs, with a generous failureThreshold so slow starts do not die young. Probes execute httpGet, tcpSocket, exec, or grpc, each with periodSeconds, timeoutSeconds, and failureThreshold knobs. The design rule worth stating: readiness should be cheap and immediate, liveness should only fail on unrecoverable internal state, and startup probes exist to keep the two honest.

Answer: A PDB caps voluntary disruptions: at least N, or at most a percentage, of the selector’s pods must stay available during drains and node upgrades. It does nothing against involuntary failures, crashes, OOM kills, node death, and it cannot block eviction forever, only delay it. The subtlety interviewers probe: a maxUnavailable of zero with a broken pod can wedge node drains, which is why PDBs need health-aware design.

Answer: The HPA scales replica counts against metrics like CPU or custom and external signals; the VPA rightsizes requests and limits per pod, usually in recommendation mode; the cluster autoscaler adds or removes nodes when pods are unschedulable or capacity sits idle. They compose: HPA for load, autoscaler for room, VPA for tuning, with the classic warning that HPA on CPU plus VPA on CPU fight each other unless carefully configured.

Answer: Setting clusterIP: None skips the virtual IP: DNS returns the pod IPs directly, one record per ready pod for StatefulSets, so clients reach specific instances instead of load balancing. It is the building block of peer discovery, gRPC client balancing, and databases that advertise their own members. Naming the StatefulSet DNS pattern, pod-name.service.namespace, is the flourish this question rewards.

Answer: A PersistentVolumeClaim is a user’s request for storage of a size and access mode; a PersistentVolume is an actual piece of storage in the cluster; a StorageClass is the template that lets the provisioner create PVs dynamically to satisfy claims. Pods mount claims, and reclaim policies decide whether released volumes are Deleted or Retained. The line Kubernetes interview questions wait for: users claim, administrators or provisioners supply, and the class decides who and how. Storage chain fluency pays off repeatedly in the scenario tier of Kubernetes interview questions.

Answer: RWO is read-write by a single node, ROX read-only by many, RWX read-write by many nodes, and the unit is nodes, not pods, which is the trap. Many pods on one node happily share an RWO volume; pods spread across nodes need RWX, typically NFS or a shared filesystem provisioner. Access modes are capabilities claimed at bind time, not enforced fences, which is the depth note for senior answers.

Answer: A NetworkPolicy is an allowlist on selected pods: once any policy selects a pod, unmatched ingress or egress is denied, so policies come in pairs, default-deny plus explicit allows. They are layer 3 and 4 only, no FQDN rules, they need a CNI that enforces them, and they are namespaced, selecting pods by label across namespaces only when explicitly entered. The common failure is assuming a default-deny exists; in vanilla clusters, everything talks to everything until you say otherwise.

Answer: In iptables mode it programs random-selection rules per Service and endpoint; in IPVS mode it builds kernel load-balancing tables with real algorithms and better behavior at scale; newer setups move east-west traffic into eBPF via CNI plugins, making kube-proxy optional. The interview-grade summary: Services are virtual, there is no listening process per Service, only rules translating the ClusterIP to real pod IPs.

Answer: The Container Network Interface plugin gives each pod its network namespace a real address and wires the datapath: bridge or veth setup, overlay encapsulation like VXLAN, or native routing, plus features like NetworkPolicy enforcement and encryption in plugins like Calico, Cilium, or Flannel. Pod-to-pod traffic never NATs on the same cluster, which is a sentence worth volunteering, and CNI choice drives your policy, performance, and observability ceiling.

Answer: Rules live in Roles, namespaced, or ClusterRoles, cluster-wide, and bind to users, groups, or ServiceAccounts through RoleBindings and ClusterRoleBindings, always grant-only, never deny. Verbs and resources are explicit, get, list, watch, create, delete, with subresources like pods/log. The design habit Kubernetes interview questions reward: bind groups not individuals, start read-only, and grant per namespace through least-privilege Roles.

Answer: A ServiceAccount is the identity pods use against the API server; the projected token volume mounts a time-limited JWT into the pod automatically, and RBAC decides what that identity may do. Default service accounts should be denied permissions, and each workload that needs API access gets its own account. Mention disabling automount where no API access is needed, and you have covered the security posture this question probes.

Answer: Pod and container-level Linux hardening: runAsUser and runAsGroup, runAsNonRoot enforcement, fsGroup for volume ownership, privileged off, dropped and added Linux capabilities, readOnlyRootFilesystem, seccomp profiles, and allowPrivilegeEscalation false. The strong answer pairs fields with intent: non-root images, read-only roots with writable volume mounts, and capability drops as the 2026 baseline that Kubernetes interview questions expect you to articulate.

Answer: Validating webhooks get a final yes or no on objects; mutating webhooks inject defaults and sidecars before validation. They run after built-in admission and are how policy engines, Kyverno and OPA Gatekeeper, and service meshes enforce organization rules. The operational caveat to mention: webhook outages can wedge the API server for affected operations, which is why failure policies and exemption namespaces matter.

Answer: A CustomResourceDefinition extends the API with your own object kinds, stored and versioned like native ones. An operator is a controller built around a CRD that encodes operational knowledge, install, scale, backup, failover, as reconciliation. The sentence that lands: CRDs add nouns, operators add the verbs that manage them, and together they are how Kubernetes grows beyond its built-in object set.

Answer: Helm packages charts as templated manifests with values files, releases, and lifecycle verbs, install, upgrade, rollback, effectively a package manager. Kustomize patches and composes plain YAML with overlays, no templating, and kubectl applies the result natively. The pragmatic framing interviewers like: Helm for distributing and versioning applications, Kustomize for environment deltas over the same base, and many teams use both.

Answer: They bound the rolling update: maxSurge is how many pods above replicas may exist during the rollout, cost versus speed; maxUnavailable is how many below replicas may be down, availability guarantee. Percentages or counts, one surge-heavy for speed, one availability-heavy for strict capacity. The detail worth adding: readiness gates every step, so probe design determines rollout speed more than these numbers do. Connecting probes to rollout pacing is the cross-topic insight Kubernetes interview questions love to surface.

Answer: The pod gets a deletion timestamp, a SIGTERM goes to its containers, and after terminationGracePeriodSeconds the kubelet SIGKILLs stragglers. Graceful means the app stops accepting new work, drains in-flight requests, and exits cleanly inside that window, with preStop hooks covering apps that need a nudge, like sleeping while endpoints withdraw. Endpoint propagation races, the reason preStop sleeps exist, are the senior detail here.

Answer: A ResourceQuota caps a namespace’s totals, CPU, memory, object counts, storage, so teams cannot consume the cluster by accident; a LimitRange injects defaults and bounds on individual containers and pods in that namespace. Together they make shared clusters governable, and the classic failure to mention: quotas without LimitRanges reject pods that arrive with no requests, an error message that confuses everyone the first time.

Answer: A PriorityClass gives pods a scheduling weight, and when a high-priority pod cannot fit, the scheduler evicts lower-priority pods to make room, preemption, subject to their PDBs. System components get reserved high priorities, and batch work runs deliberately low. The operational wisdom to add: priorities are also an eviction shield under node pressure, so they double as an incident-time protection tier.

Answer: Topology spread constraints distribute a Deployment’s pods across failure domains, zones, hosts, regions, with maxSkew defining how uneven the distribution may get and whenUnsatisfiable deciding whether to score softly or hard-fail. They replaced hand-rolled pod anti-affinity math for the common case, and pairing them with zone-aware storage and load balancing is the completeness note Kubernetes interview questions quietly look for.

Answer: kubectl rollout status watches the current rollout; history lists ReplicaSet revisions; undo --to-revision=N re-deploys one, implemented as yet another ReplicaSet scale pair; pause freezes the rollout for canary inspection, and resume continues. The mechanics matter: rollbacks are cheap because old ReplicaSets survive, so trimming revisionHistoryLimit to zero removes your safety net, a mistake interviewers like hearing you warn about.

Answer: The spectrum: pause-and-inspect with rollout pause on a few replicas; weighted traffic splitting with a service mesh or gateway API routes; separate canary Deployment plus Service sharing the parent selector so traffic splits by replica ratio; or Argo Rollouts and Flagger automating analysis-driven promotion. The graded idea is that Kubernetes gives you primitives, label juggling plus routing, and canary tooling is policy on top of those primitives.

Answer: Pods the kubelet runs directly from manifest files on disk, no API server involved, which is how control plane components bootstrap themselves in kubeadm clusters under /etc/kubernetes/manifests. The kubelet mirrors their status into the API read-only, so you can see but not edit them through kubectl. Knowing they exist explains a lot of kubelet behavior, which is the real point of the question.

Answer: Node status carries conditions like Ready, MemoryPressure, DiskPressure, and PIDPressure. DiskPressure evicts pods and blocks new ones, PIDPressure signals process table exhaustion, and a lost Ready condition with a grace period marks the node NotReady, triggering eviction of its pods. Node conditions are the first thing to read when pods start mass-Pending, which is why they lead the scenario tier of Kubernetes interview questions.

Answer: kubectl top pods and nodes show live usage from the metrics-server, which scrapes the kubelets and serves the Metrics API. When it errors with metrics not available, metrics-server is missing, misconfigured behind a kubelet TLS issue, or just warming up. The distinction to make: metrics-server feeds kubectl and the HPA, while real monitoring stacks scrape Prometheus endpoints directly.

Answer: Etcd snapshots on a schedule, etcdctl snapshot save, with a tested restore procedure, cover control plane state; Velero adds per-namespace backup and restore of objects plus PV data to object storage; and everything that lives in Git, all your manifests and Helm releases, is already portable. The senior note: restoring etcd is a cluster-replacing event with version constraints, so the real strategy is Git plus application-level data protection, with etcd snapshots as the disaster layer.

Answer: Zero is clean exit, 1 is app error, and the 128-plus range encodes signals: 137 is SIGKILL, which in Kubernetes overwhelmingly means OOMKilled, 143 is SIGTERM, the normal shutdown path, 139 is segfault. Reading exit codes before logs is a genuine time-saver, because 137 redirects the whole investigation toward limits and memory, which is why Kubernetes interview questions keep this one in rotation. Exit-code reading is a small habit that speeds up every scenario in this bank.

Answer: Taint the pool’s nodes so general workloads repel, add tolerations to the dedicated workload, and pin it with node affinity or selectors on the pool’s labels. For exclusivity, combine the taint with a quota or priority so nothing else lands there. The sentence that completes it: taints keep others out, affinity keeps yours in, and the pair is the standard answer to noisy-neighbor questions in Kubernetes interview questions.

Answer: After the node’s lease times out, the node controller marks it NotReady, pods get marked Unknown, and eventually they are tide-cleaned and the controllers recreate them elsewhere if they are managed by a Deployment or similar. The grace period is deliberate, roughly 40 seconds to a few minutes depending on settings, to avoid split-brain churn during network blips. Knowing that pods are not instantly resurrected is what separates realistic answers here.

Answer: Finalizers are strings on an object’s metadata that block deletion until the named controller finishes cleanup and removes them; the object sits in Terminating meanwhile. They bite when the responsible controller is gone, namespace deletion wedged by an orphaned finalizer is the classic, and the fix is completing or clearing the cleanup, with direct finalizer edits as the careful last resort. Naming namespace-wedge as the common case is what interviewers listen for.

Answer: StatefulSets for identity, StorageClasses backed by performant and zone-aware disks, PDBs so drains never take quorum down, topology constraints, backup jobs that are tested by restore, and honest sizing of IOPS against the storage class. Managed databases outside the cluster remain a legitimate answer, and saying when you would choose that instead of Kubernetes-native is exactly the judgment Kubernetes interview questions on this topic reward.

Answer: PodSecurityPolicy was removed, and its replacement is the built-in Pod Security Admission plus ecosystem policy engines: namespaces get labels for privileged, baseline, or restricted profiles with enforce, audit, and warn modes, while Kyverno or Gatekeeper cover richer org policy. The takeaway sentence: profile labels handle the standard guardrails, and policy engines handle everything site-specific.

Answer: Ephemeral containers: kubectl debug -it pod/name --image=busybox attaches a toolbox container to the running pod’s namespaces without restarting it, with process and network visibility per its profile. Cluster-side, read logs and events, describe the pod, and exec is off the table by design. This is a genuinely modern item in Kubernetes interview questions, and knowing kubectl debug by name signals current hands-on practice.

Answer: kubectl describe pod for state and exit code, then kubectl logs --previous for the dying instance’s last words: a stack trace names the bug, exit 137 points at OOMKilled, a config error points at the rollout that just shipped. Check what changed, the new image, a configmap or secret mounted into it, an env var, then fix and redeploy rather than restarting in place, because the ReplicaSet will faithfully recreate the same crash. Restart-only thinking is what this question exists to expose.

Answer: Describe the pod and read the pull error: ErrImagePull versus ImagePullBackOff reasons name the exact failure. Usual causes in order: the tag does not exist in the registry, a typo or a CI job that never pushed; credentials missing or expired, imagePullSecrets not attached to the ServiceAccount; a private registry the node cannot reach, firewall or DNS; and rate limiting on Docker Hub, the sneakiest one. Verify with a manual pull from a node, then fix at the source.

Answer: 137 is SIGKILL, and in a limits-managed container that means OOMKilled: the container crossed its memory limit. Confirm the reason in describe, then chart memory usage against the limit over time, a sawtooth that keeps climbing means a leak or undersizing. Decide deliberately: raise the limit with an honest request to match, or fix the leak, and remember Java and friends need heap flags aligned with the cgroup limit or they will happily ignore it. Java memory arithmetic is the follow-up in Kubernetes interview questions about 137 more often than not.

Answer: Describe the pod and read the events, they name the blocker group: unschedulable with insufficient cpu or memory means requests exceed node headroom; node taints mean tolerations are missing; node affinity or selector conflicts mean no node matches; and a PVC stuck Pending, check kubectl get pvc, means storage provisioning failed. Each family has a different owner, capacity, cluster policy, workload spec, or storage class, and naming that grouping is the senior move in scenario Kubernetes interview questions.

Answer: First contain: check whether its pods were rescheduled and whether service capacity held, watch for eviction storms on the rest of the pool. Then diagnose the node: SSH or console in, is the kubelet running, is the node out of disk or memory, did the container runtime die, is there a network partition from the API server. Read kubectl describe node for conditions and the kubelet’s last reported heartbeat. Fix the node and uncordon, or terminate it and let the autoscaler replace it, and only then, with capacity healthy, do the post-mortem.

Answer: An empty endpoints slice means the selector matched zero ready pods, so work the chain: does the Service’s selector actually match the pod labels, a typo or an environment suffix drift; are the pods ready, failing readiness probes remove pods from endpoints while they still run; and for targetPort mismatches, the container may listen on a different port than the Service forwards to. kubectl get endpoints svc or kubectl describe svc shows the matched set instantly, which is why this question is a staple of Kubernetes interview questions on networking.

Answer: Short names resolve only inside the same namespace, so the cross-namespace call needs the FQDN, service.other-namespace.svc.cluster.local. If the FQDN also fails, test DNS itself with a busybox nslookup against CoreDNS, check NetworkPolicies for egress-to-DNS blocks, the classic self-inflicted outage, and confirm the upstream resolv.conf search list is intact. Nine times out of ten it is the namespace suffix, and saying that first shows pattern memory.

Answer: Split the path: browser to load balancer, load balancer to ingress controller, ingress to Service, Service to pods. Check the ingress resource’s service name and port against reality, host and path rules against the request, TLS secret existence and validity, and whether the ingress controller’s own pods are healthy and receiving traffic. curl from inside the cluster to the Service directly, isolating Kubernetes routing from the edge, then walk outward. Halving the path with one test is the skill this question grades.

Answer: No StorageClass named in the claim exists, or no default class is set, so nothing provisions it; the class exists but its provisioner is not running or cannot reach the cloud API; or the requested access mode or size has no match. Describe the PVC for events, check kubectl get sc and the provisioner’s pods, and verify quota and IAM for the storage driver. The teaching point to voice: dynamic provisioning is a chain, claim to class to provisioner to disk, and the break is usually at the ends.

Answer: Most block-storage volumes attach to one node at a time, so the dead node still holds the attach, and the new pod waits forever. Force-detach depends on the platform: volumeattachment deletion for CSI, or the cloud console’s force-detach, after confirming the old node is truly gone rather than partitioned. Then the pod binds and starts, and the recovery review asks whether the node failure path should automate this. Multi-attach capable filesystems sidestep it, with their own consistency caveats worth naming.

Answer: Check the metrics-server pods exist and are healthy, then its logs for kubelet TLS errors, the default-facing certificate mismatch on many installs, fixed by the kubelet-insecure-tls or proper CA flags in test environments. Confirm the APIService for metrics.k8s.io is Available, since a broken aggregation layer silently starves both top and the HPA. Knowing that HPAs depend on this exact pipeline is the insight that elevates the answer.

Answer: Walk the metric supply chain: HPA reads from the metrics pipeline, so a dead metrics-server starves it; requests must be set on containers, because utilization percentages are relative to requests, and without them the HPA cannot compute a target; the target threshold and tolerance may simply not be crossed on average; and scale-up cooldowns delay reactions. Describe the HPA itself, its conditions often state the blocker verbatim, which is the first command I would run and the habit this question rewards. Describe the controller first is a diagnostic order that transfers across all scenario work in this tier.

Answer: kubectl rollout status and describe the Deployment for the progress deadline message, then examine the new ReplicaSet’s pods: a failing readiness probe keeps a rollout eternally incomplete, an image pull error repeats, or a quota blocks the surge pod. The Deployment itself will mark progressDeadlineExceeded, and the choice is fix forward or rollout undo. Failing readiness after a config change is the single most common shape of this incident.

Answer: Find what owns the disk: container images and logs dominate node storage, so check the runtime’s garbage collection, oversized logs without rotation, and ephemeral storage hogs via kubectl get pods -o wide plus node-level du on the container directories. EmptyDir and write-to-root-filesystem apps consume the node disk that eviction watches, so the durable fix is log sidecars, image pruning policy, and moving writes to volumes or object storage. Cleanup without finding the writer guarantees a repeat, which is the sentence this question wants.

Answer: Someone double-encoded or the app read the raw object instead of the mounted keys: Secret data is stored base64-encoded, and env or file mounts decode it, so seeing base64 inside the container means the value was encoded twice at creation, or the app is reading secret.yaml instead of the decoded mount. Verify with kubectl get secret X -o jsonpath='{.data.key}' | base64 -d, then fix the creation pipeline, and note that stringData in a manifest saves authors from manual encoding.

Answer: Policies are additive allowlists, so read every policy selecting the pod, both ingress and egress, and check each direction against the actual flow: is DNS egress allowed, port 53 is forgotten constantly; are the peer namespace and pod selectors what you think, not the names you meant; and does the CNI even enforce policy, an uninstalled network plugin makes policies decorative. Test from a scratch pod with curl and narrow the rule that rejects. Policy reading order, pod selection first, then rules, is the transferable skill.

Answer: Exec needs a live container: if the pod is crash-looping, exec into nothing and go to logs plus describe instead; if it restarted recently, the old container is gone and the new one has a different instance name, so retry against the pod. In distroless images there is no shell, and the answer is an ephemeral debug container. The question is really checking that you do not treat exec as the universal first move, because half the time the evidence you need is in events and previous logs.

Answer: Drain evicts politely, so it waits on PodDisruptionBudgets: a pod whose budget forbids disruption right now, a maxUnavailable zero with a single broken replica, or a StatefulSet member that cannot move because its PVC is zoned elsewhere. Check with describe on the stuck pod and the PDB’s allowed disruptions count, then decide: fix the blocker, temporarily relax the PDB with eyes on redundancy, or force with a documented risk. The PDB interplay is precisely what this scenario teaches.

Answer: Follow the state path: etcd disk latency is the number one suspect, so check its disk IOPS and latency first, then etcd db size and compaction state; a client hammering LIST on huge collections, a controller without informer caches, is suspect number two, visible in API server metrics and audit logs; and certificate or webhook stalls produce targeted slowness rather than cluster-wide. This is the scenario where Kubernetes interview questions separate operators from architects, because the answer is infrastructure forensics, not kubectl.

Answer: Cluster certificates: kubelet serving and client certs, API server certs, or front-proxy certs, all with about a one-year life in kubeadm installs. Symptoms are kubelets unable to report, nodes flipping NotReady, and TLS errors in API server logs; kubeadm certs check-expiration confirms, and renewal plus kubelet restarts recover it. Managed control planes hide this, which is exactly why self-managed clusters need expiry monitoring, the operational lesson to state.

Answer: An aggressive liveness probe: wrong path or port, a timeout shorter than the app’s worst response time, or a failureThreshold too low for garbage collection pauses, so the kubelet restarts a working container on a schedule. The restart count in pod status plus probe records in describe confirm it, and the fix is tuning periods and thresholds or, better, moving that health judgment to readiness while liveness only guards true deadlocks. Liveness-caused restart storms are among the most common self-inflicted wounds in the scenario tier of Kubernetes interview questions.

Answer: Init containers run in order, so find the first one stuck with kubectl get pod -o jsonpath or the init container status in describe, then read its logs specifically. The usual suspects: a dependency-wait loop polling an endpoint that is down or DNS-broken, a migration script holding a lock, or a missing volume or permission. Init failures block the app by design, so the fix belongs to the init step, and forgetting to check init logs, not app logs, is the classic mistake this scenario hunts.

Answer: Endpoint propagation races: the endpoint removal, the proxy rule update, and the client’s cached connections are three clocks, and a long-lived HTTP connection keeps flowing to the old pod even after rules change. The engineering fix is graceful termination on both sides, preStop delay so endpoints withdraw before SIGTERM lands, connection drains with sane idle timeouts, and retry-on-closed at the client. Explaining the three clocks is what makes this answer stand out.

Answer: Its identity artifacts: the PVC with the pod’s data was deleted with the namespace, or recreated in a zone the new node cannot attach, or the headless service that StatefulSet pod names depend on is missing, so the identity chain fails before the container runs. Restore the PVC and service, or accept data loss knowingly, and the prevention point is that namespaces are not soft boundaries, deleting one removes everything a StatefulSet assumed persistent. That lifecycle lesson is the actual content of the question.

Answer: Correlate first, blame second: line up pod restart times, node events, and the backup schedule. Likely mechanisms, I/O saturation from the backup starving the node, a memory spike when the backup process shares the node, an eviction triggered by ephemeral storage from backup staging, or the backup triggering liveness timeouts by blocking disk. Prove it with node metrics over the window, then isolate, move the backup, cap its I/O with a dedicated node pool, and re-observe. Scheduled-pattern incidents reward timeline discipline, which is the skill being graded.

Answer: Inventory before edits: kubectl api-resources then get everything namespaced, workloads first, then services, config, and RBAC; check for Helm releases with helm list -A and Argo or Flux applications, since GitOps ownership changes everything; label audit for owner and team annotations; and snapshot RBAC bindings to learn who can touch what. Then, before any change, introduce a Git-backed source of truth, even incrementally. The judgment being tested is archaeology before action, the same instinct every scenario in Kubernetes interview questions rewards.