100% Free
🎯 3200+ Questions. One Goal: Your Success Sign In Sign Up

Mid Kubernetes Interview Questions

Curated Mid-level Kubernetes interview questions for developers targeting mid positions. 30 questions available.

Last updated:

Kubernetes Interview Questions & Answers

Skip to Questions

Welcome to our comprehensive collection of Kubernetes interview questions and answers. This page contains expertly curated interview questions covering all aspects of Kubernetes, from fundamental concepts to advanced topics. Whether you're preparing for an entry-level position or a senior role, you'll find questions tailored to your experience level.

Our Kubernetes interview questions are designed to help you:

  • Understand core concepts and best practices in Kubernetes
  • Prepare for technical interviews at all experience levels
  • Master both theoretical knowledge and practical application
  • Build confidence for your next Kubernetes interview

Each question includes detailed answers and explanations to help you understand not just what the answer is, but why it's correct. We cover topics ranging from basic Kubernetes concepts to advanced scenarios that you might encounter in senior-level interviews.

Use the filters below to find questions by difficulty level (Entry, Junior, Mid, Senior, Expert) or focus specifically on code challenges. Each question is carefully crafted to reflect real-world interview scenarios you'll encounter at top tech companies, startups, and MNCs.

Questions

30 questions
Q1:

How does the Kubernetes Scheduler decide the best node for a Pod?

Mid

Answer

Scheduler evaluates nodes via filters and scoring. Predicates check resource availability, taints, affinity; priorities score nodes and top-scored node is selected.
Quick Summary: The scheduler filters nodes (eliminates those that fail hard requirements — resources, taints, affinity), then scores the remaining nodes (prefers nodes with most available resources, matching preferred affinity, spreading Pods evenly). It picks the highest-scoring node and binds the Pod to it by writing to the API server.
Permalink
Q2:

Why do Pods sometimes get terminated with OOMKilled even when free host memory exists?

Mid

Answer

Pods run under cgroup memory limits; exceeding the limit triggers kernel OOM kill regardless of host memory.
Quick Summary: Kubernetes enforces memory limits via cgroups per Pod (container memory.limit_in_bytes). The OOM killer operates at the cgroup level — it can kill a container even if the host has free memory, because the container's memory usage exceeded its cgroup limit. This is intentional — limits are hard boundaries for the container, not the host.
Permalink
Q3:

What is the role of kube-controller-manager?

Mid

Answer

It runs controllers like Deployment, ReplicaSet, Node lifecycle, Job, and HPA to maintain desired state.
Quick Summary: kube-controller-manager runs all the core controllers — Node controller (detects node failures), ReplicaSet controller (maintains Pod counts), Deployment controller (manages rolling updates), Endpoint controller (updates Service endpoints), and many more. Each controller watches relevant resources and takes action to maintain desired state.
Permalink
Q4:

How does Kubernetes handle split-brain scenarios in multi-master clusters?

Mid

Answer

API servers rely on etcd quorum; without quorum, writes stop to avoid inconsistent cluster state.
Quick Summary: Kubernetes uses etcd's Raft consensus — writes are only committed when a majority (quorum) of etcd members agree. With 3 control plane nodes, 2 must agree. If the network splits into two halves, the side without quorum can't accept writes — it becomes read-only. This prevents split-brain by design. Three or five control plane nodes ensure quorum survives one or two failures.
Permalink
Q5:

Why is direct access to etcd discouraged for debugging?

Mid

Answer

etcd stores raw cluster state; manual edits may corrupt the cluster. API server is the safe interface.
Quick Summary: etcd is the source of truth for the cluster — all Kubernetes state is stored there. Direct etcd access bypasses API server validation, admission controllers, and RBAC. You can corrupt cluster state with malformed writes or accidentally expose secrets. Use kubectl and the API server for all interactions; etcdctl is for backup/restore only.
Permalink
Q6:

What is the difference between soft and hard eviction in Kubernetes?

Mid

Answer

Soft eviction allows graceful shutdown; hard eviction force-kills Pods when thresholds exceed.
Quick Summary: Soft eviction: node is under resource pressure (low memory, low disk) — kubelet starts gracefully evicting lower-priority Pods to free resources. The node stays schedulable. Hard eviction: resources are critically low — kubelet aggressively evicts Pods without grace periods to prevent the node from becoming completely unusable.
Permalink
Q7:

How do topology spread constraints improve availability?

Mid

Answer

They distribute Pods across zones/nodes/racks to avoid localized failures.
Quick Summary: Topology spread constraints distribute Pods evenly across zones, nodes, or regions. Instead of all replicas landing on one zone (risky if that zone fails), you declare maxSkew: 1 across topology zones — Kubernetes ensures replicas spread as evenly as possible. Combines with Pod anti-affinity but is more flexible and declarative.
Permalink
Q8:

Why does Kubernetes recommend using readiness gates for external dependency checks?

Mid

Answer

Readiness gates delay traffic until apps confirm external dependencies are healthy.
Quick Summary: External dependency readiness gates let you declare that a Pod isn't ready until an external condition is met — beyond just the Pod's own health check. For example, a Pod might be healthy internally but not ready until a sidecar (like a service mesh proxy) finishes initializing. Readiness gates add a programmatic external condition to the standard readiness probe.
Permalink
Q9:

What is the difference between Service sessionAffinity ClientIP vs None?

Mid

Answer

ClientIP keeps the same Pod for a client; None performs round-robin load balancing.
Quick Summary: ClientIP: all requests from the same client IP go to the same Pod (sticky sessions) — useful for stateful protocols. None: each request can go to any healthy Pod — better load distribution. ClientIP is implemented via iptables DNAT rules that track client IP affinity with a configurable timeout (default 10800s).
Permalink
Q10:

How does kube-proxy operate in IPVS mode vs iptables mode?

Mid

Answer

IPVS uses kernel-level load balancing, faster for large clusters; iptables uses rule chains.
Quick Summary: iptables mode: for each Service, kube-proxy adds chains of iptables rules that DNAT traffic. With many Services, traversing many chains per packet adds latency and CPU overhead. IPVS mode: uses the kernel's IPVS module (L4 load balancer) — lookup is O(1) via a hash table instead of O(n) through iptables chains. Much faster at 10,000+ Services.
Permalink
Q11:

Why do HPA and Cluster Autoscaler sometimes conflict?

Mid

Answer

HPA increases Pods requiring more nodes; autoscaler reacts slower, causing scaling thrashing.
Quick Summary: HPA scales Pods based on current load; Cluster Autoscaler adds nodes when Pods are Pending (no room to schedule). Conflict: HPA scales up Pods → Cluster Autoscaler adds a node → node comes up → HPA scales down → Cluster Autoscaler tries to remove the underutilized node → HPA sees load spike again. Tune cooldown windows and min/max bounds to dampen oscillation.
Permalink
Q12:

What is the impact of using hostNetwork true in Pods?

Mid

Answer

Pods share node network namespace, risking port conflicts and weaker isolation.
Quick Summary: hostNetwork: true puts the Pod directly on the host's network namespace — no isolation. The Pod sees and can reach everything the host sees. Multiple Pods on the same node can't use the same port. If compromised, the attacker has direct network access to the host environment. Only justified for very specific system-level network workloads.
Permalink
Q13:

Why does Pod startup time increase when ConfigMaps or Secrets grow large?

Mid

Answer

Large data mounts slow kubelet volume setup and Pod initialization.
Quick Summary: Kubernetes projects ConfigMaps and Secrets into Pods via the API server. Kubelet watches these resources and syncs them into the Pod. Large ConfigMaps mean more data to transfer, more etcd I/O per watch event, and more time for kubelet to process and write files into the container. The sync loop adds latency proportional to data size.
Permalink
Q14:

Why can a Deployment have multiple ReplicaSets simultaneously?

Mid

Answer

Rolling updates retain old ReplicaSets for rollback until scaled to zero.
Quick Summary: During a rolling update, the old ReplicaSet scales down while the new one scales up — both coexist temporarily. Additionally, Kubernetes keeps the last N ReplicaSets (controlled by revisionHistoryLimit, default 10) to support rollbacks. kubectl rollout undo switches back to the previous ReplicaSet instantly.
Permalink
Q15:

What is the significance of Pod Priority Classes?

Mid

Answer

Higher-priority Pods can preempt lower ones, ensuring critical workloads get scheduled.
Quick Summary: Priority Classes define the importance of Pods. Higher-priority Pods can preempt (evict) lower-priority ones to get scheduled when the cluster is full. System components run at the highest priority. Batch jobs and non-critical workloads run at lower priority. This ensures critical services always get resources, even under cluster pressure.
Permalink
Q16:

What is the difference between eviction due to node pressure and preemption?

Mid

Answer

Eviction removes Pods for node stability; preemption removes Pods for priority scheduling.
Quick Summary: Node pressure eviction: kubelet proactively evicts Pods because the node is running low on memory or disk — it removes the lowest-priority Pods to keep the node healthy. Preemption: the scheduler evicts lower-priority Pods on a node to make room for a higher-priority Pod that couldn't fit. Eviction is reactive; preemption is scheduled.
Permalink
Q17:

What causes image pull backoff errors beyond missing images?

Mid

Answer

Caused by bad credentials, DNS issues, digest mismatch, rate limits, or broken CNI.
Quick Summary: ImagePullBackOff occurs when: the image doesn't exist or the tag is wrong, the registry requires authentication but no imagePullSecret is configured, the registry is rate-limiting (Docker Hub free tier), the node can't reach the registry (network/firewall issue), or the registry itself is down. kubectl describe pod shows the exact error message.
Permalink
Q18:

How does Kubernetes handle network policies internally?

Mid

Answer

CNI plugins enforce policies using iptables or eBPF based on Pod labels.
Quick Summary: NetworkPolicies are enforced by the CNI plugin (not kube-proxy or the kernel directly). The CNI plugin (Calico, Cilium, Weave) watches NetworkPolicy objects via the API server and programs iptables, eBPF, or OVS rules on each node accordingly. By default, no NetworkPolicies means all traffic is allowed — policies are additive restrictions.
Permalink
Q19:

Why is disabling swap required for kubelet?

Mid

Answer

Swap breaks kubelet memory accounting, causing unpredictable scheduling and OOM behavior.
Quick Summary: Swap changes memory pressure behavior in ways that break Kubernetes' resource accounting. With swap, the kernel can move memory pages to disk silently — a Pod appears to have "used" memory but it's actually on disk, making resource limits unreliable. Kubernetes' OOM killer and eviction logic assume in-memory resources are truly in memory.
Permalink
Q20:

How does Kubernetes guarantee consistent Pod identity in StatefulSets?

Mid

Answer

Pods get stable names, PVCs, and ordinals that persist across restarts.
Quick Summary: StatefulSet Pods get stable, predictable names: app-0, app-1, app-2. Each gets its own PersistentVolumeClaim (volumeClaimTemplate). Even after restarts or rescheduling, app-0 always gets the same PVC with the same data. The Headless Service gives each Pod a stable DNS name. This identity stability is what databases need for leader election and replication.
Permalink
Q21:

Why do terminating Pods still receive traffic sometimes?

Mid

Answer

Service endpoints update slowly; readiness checks and graceful shutdown reduce traffic leakage.
Quick Summary: When a Pod is deleted, it's removed from the endpoint slice immediately — but kube-proxy has a slight propagation delay before updating iptables rules. During that window, Services still route some traffic to the terminating Pod. Setting terminationGracePeriodSeconds and adding a pre-stop sleep hook ensures the Pod drains in-flight requests before the process actually stops.
Permalink
Q22:

What causes Pods to get stuck in CrashLoopBackOff?

Mid

Answer

Repeated startup failures due to misconfigurations, missing dependencies, or readiness issues.
Quick Summary: CrashLoopBackOff means the container starts, crashes, kubelet restarts it, it crashes again — repeatedly. Root causes: application error (bug, missing config, wrong startup command), missing environment variables or Secrets, out-of-memory kill, permission issues, or dependency (like a database) not being available. Check kubectl logs and kubectl describe pod for the actual error.
Permalink
Q23:

Why is API throttling important in large clusters?

Mid

Answer

Throttling prevents overload from noisy clients, ensuring API server stability.
Quick Summary: In large clusters, many controllers, kubelet heartbeats, watches, and client requests all hit the API server simultaneously. Without throttling (rate limiting), a surge of requests could overwhelm it. API Priority and Fairness (APF) queues requests by priority and limits each client's throughput — preventing one noisy controller from starving critical system operations.
Permalink
Q24:

What is the difference between Ingress and Gateway API?

Mid

Answer

Gateway API offers richer routing and team isolation; Ingress is simpler and older.
Quick Summary: Ingress is an older API with limited routing capabilities — host-based and path-based routing only, TLS termination, vendor-specific annotations for extra features. Gateway API is the newer, more expressive replacement — supports traffic splitting, header matching, backend weights, and multiple protocols natively. Gateway API is now GA and recommended for new deployments.
Permalink
Q25:

Why do readiness probe misconfigurations cause cascading failures?

Mid

Answer

Pods keep entering/exiting load balancer rotation, destabilizing traffic.
Quick Summary: A failing readiness probe removes the Pod from Service endpoints — it stops receiving new traffic. If many Pods fail readiness simultaneously (e.g., due to a dependency like a DB being slow), the Service routes all traffic to the few remaining ready Pods — overloading them, causing them to fail readiness too, cascading until the service is down.
Permalink
Q26:

How does Kubernetes handle kernel upgrades or node reboots gracefully?

Mid

Answer

Cordon, drain, and PDB ensure Pods migrate safely before reboot.
Quick Summary: For node reboots during upgrades, use kubectl drain to cordon the node (stop new scheduling), evict existing Pods gracefully (respecting PDBs), perform maintenance, then uncordon to bring it back. PDB prevents draining from taking down more replicas than you can afford to lose. Tools like kured automate this process for kernel upgrades requiring reboots.
Permalink
Q27:

What is the difference between nodeSelector, nodeAffinity, and topologySpreadConstraints?

Mid

Answer

nodeSelector = basic match; nodeAffinity = expressions; spread constraints distribute Pods.
Quick Summary: nodeSelector: simple label matching — must be on a node with this exact label. nodeAffinity: expressive — required vs preferred, multiple conditions, AND/OR logic. topologySpreadConstraints: distribute evenly — "spread my Pods across zones, max 1 skew" — no hard node targeting but ensures balanced distribution across a topology dimension.
Permalink
Q28:

Why are Init Containers important?

Mid

Answer

They run setup logic before main containers start.
Quick Summary: Init containers run to completion before the main container starts. They're used for: waiting for a database to be ready before the app starts, running schema migrations, downloading config files, setting up permissions. If an init container fails, Kubernetes restarts the Pod. This decouples initialization from the main app logic cleanly.
Permalink
Q29:

Why does scaling StatefulSets too quickly cause issues?

Mid

Answer

StatefulSets require ordered Pod creation; fast scaling causes readiness delays.
Quick Summary: StatefulSets create and scale Pods sequentially (app-0, then app-1, then app-2) and each Pod must be Running and Ready before the next starts. Scaling quickly means you're waiting for each Pod to initialize, connect to peers, and join the cluster (for distributed DBs, this is critical). Scaling too fast can cause split-brain or replication lag.
Permalink
Q30:

Why are cluster upgrades risky without version skew awareness?

Mid

Answer

Components allow limited version skew; mismatches destabilize clusters.
Quick Summary: Kubernetes enforces strict version skew limits between components — typically no more than 2 minor versions between API server and kubelet. Upgrading the API server too far ahead of the kubelet can cause incompatibilities where the kubelet can't process new API features. Upgrade control plane first, then nodes, one version at a time.
Permalink

Curated Sets for Kubernetes

No curated sets yet. Group questions into collections from the admin panel to feature them here.

People Also Ask - Related Kubernetes Questions

How does the Kubernetes Scheduler decide the best node for a Pod?
Why do Pods sometimes get terminated with OOMKilled even when free host memory exists?
What is the role of kube-controller-manager?
How does Kubernetes handle split-brain scenarios in multi-master clusters?
Why is direct access to etcd discouraged for debugging?
What is the difference between soft and hard eviction in Kubernetes?
Ready to level up? Start Practice