Skip to the document
Madhuopen lab
The Kubernetes Ninja PathTrack 1 — Kubernetes from the ground up

Chapter 16

Kubernetes Interview Questions — The Concept Reference

14 min read read2,201 wordsInterview Prep3 recall cards

Before you read, guess

What distinguishes the current post from Post 17 in terms of interview preparation focus?

Take ten seconds and guess — even a wrong guess makes the answer stick. Tap to see where the chapter lands, or just read on.

Interviewers weight troubleshooting and scenario answers heavily in 2026 — this post covers concepts; Post 17 covers the scenario-based and production-incident questions that actually separate candidates.

This isn't a fifteenth lesson — it's the drawer you pull open the night before an interview. Every answer below is deliberately short: the goal is to jog the full mental model you already built in Posts 1–15, not re-teach it. Where a topic needs more than three sentences to actually understand, the answer points back to the post that already did that work. Read this one straight through once, then skim it again the morning of.

Core Concepts & Architecture

See Post 1 & Post 2

What is Kubernetes, in one sentence?

An open-source system that keeps a fleet of containers running in the state you declared, automatically noticing and correcting drift — the reconciliation loop from Post 1.

What problem does Kubernetes solve that plain Docker doesn't?

Docker runs one container on one machine. Kubernetes runs containers across many machines, restarts them when they die, moves them off failed nodes, and load-balances traffic to whichever replicas are healthy — none of which a single docker run gives you.

Explain the control plane vs. worker nodes.

The control plane (API server, etcd, scheduler, controller manager) decides what should be running; worker nodes (kubelet, kube-proxy, container runtime) actually run it. Full breakdown in Post 2.

What is etcd and why does it matter so much?

etcd is the cluster's only source of truth — a distributed key-value store holding every object's desired and current state. Lose etcd with no backup, and you've lost the cluster's memory, not just its dashboard.

What does the reconciliation loop actually do, mechanically?

Controllers continuously compare desired state (what you applied) against observed state (what's actually running) and issue the minimum actions to close the gap — create a Pod, kill a Pod, never a full teardown-and-rebuild. This is the idea every later object in this series inherits.

Pods, Deployments & ReplicaSets

See Post 3, Post 4 & Post 13

What is a Pod, and why does Kubernetes wrap containers in one instead of scheduling containers directly?

A Pod is one or more containers that always land on the same node and share network and storage — the smallest deployable unit. It exists because some containers (a sidecar shipping logs) need to be inseparable from the app they help. Full mental model in Post 3.

Deployment vs. ReplicaSet vs. Pod — what does each actually own?

A Pod is one instance. A ReplicaSet keeps N identical Pods alive. A Deployment manages ReplicaSets over time, which is how you get rolling updates and rollbacks instead of just a fixed headcount.

How does a rolling update avoid downtime?

The Deployment creates new-version Pods gradually while removing old-version ones, controlled by maxSurge/maxUnavailable, and only routes traffic to a new Pod once its readiness probe passes — see Post 4 and the probes section below.

How do you roll back a bad Deployment?

kubectl rollout undo deployment/<name> reverts to the previous ReplicaSet revision. kubectl rollout history lists revisions if you need to go back further than one step.

What are init containers, and when do you reach for one?

Containers that run to completion, in order, before any main container starts in the same Pod — used to wait on a dependency or run setup that must finish first, without permanently coupling that logic into the app image.

Sidecar, ambassador, adapter — what's the difference?

All three are a helper container riding alongside your main one. A plain sidecar does general-purpose helper work; an ambassador proxies the main container's outbound calls; an adapter standardizes the main container's output. Post 14 has the full walkthrough.

Services & Networking

See Post 5 & Post 10

Why does Kubernetes need Services at all if Pods already have IPs?

Pod IPs are thrown away every time a Pod is recreated. A Service is a stable name and virtual IP in front of a changing set of Pods, so nothing else in the cluster has to track individual Pod IPs. Post 5.

ClusterIP vs. NodePort vs. LoadBalancer vs. ExternalName — when does each apply?

ClusterIP (default): internal-only. NodePort: exposes a port on every node, mostly for dev/testing. LoadBalancer: provisions a cloud load balancer for real external traffic. ExternalName: a DNS alias to something outside the cluster entirely, no proxying involved.

How does a Service actually find its Pods?

Label selectors. A Service's selector matches Pod labels, and the result set becomes the Service's Endpoints — this is the exact mechanism from Post 8, reused everywhere.

Ingress vs. a Service of type LoadBalancer — why have both?

A LoadBalancer Service is one external IP per Service — expensive and wasteful with dozens of services. Ingress is one shared entry point that routes by hostname/path to many internal Services, needing only one Ingress Controller and load balancer for the whole cluster. Post 10.

A Pod can reach another Pod's IP directly but not through its Service — where's the bug?

Almost always the Service's selector not matching the target Pods' labels, so the Service has zero Endpoints. Confirm with kubectl get endpoints <svc> before looking anywhere else.

What is CoreDNS's job in the cluster?

It's the default DNS server that resolves Service names like my-svc.my-namespace.svc.cluster.local to the Service's ClusterIP — the reason Pods can call each other by name instead of hardcoded IPs.

ConfigMaps, Secrets & Storage

See Post 6 & Post 7

ConfigMap vs. Secret — what's the actual difference?

Mechanically, almost none — both inject data as env vars or mounted files. The difference is intent and handling: Secrets are base64-encoded (not encrypted by default) and meant for credentials; Post 6 covers the honest truth about how little protection that base64 encoding actually provides on its own.

How do you actually encrypt Secrets at rest?

Base64 isn't encryption. You need an EncryptionConfiguration on the API server (e.g. the aescbc provider) so etcd stores Secret data encrypted, not just encoded.

emptyDir vs. hostPath vs. PersistentVolume — pick the right one.

emptyDir: scratch space, dies with the Pod. hostPath: mounts the node's own disk — fragile, ties a Pod to a specific node. PersistentVolume + PersistentVolumeClaim: the real production pattern, decoupling a Pod from the physical storage behind it. Post 7.

What's the relationship between a PV, a PVC, and a StorageClass?

A PVC is a request for storage; a PV is the actual piece of storage; a StorageClass tells Kubernetes how to dynamically provision a new PV to satisfy a PVC, instead of an admin pre-creating them by hand.

Namespaces, Labels & Organizing a Cluster

See Post 8

What are Namespaces for, really?

Virtual walls inside one physical cluster — dividing it by team, environment, or domain, and scoping ResourceQuotas and RBAC per area, without needing separate clusters.

Labels vs. annotations — what's the line?

Labels are for identifying and selecting objects (a Service's selector matches labels). Annotations are for attaching non-identifying metadata a tool might read (build IDs, descriptions) — nothing selects by an annotation.

Scheduling, Probes & Resource Management

See Post 9

Requests vs. limits — what does each control?

A request is what a Pod is guaranteed and what the scheduler uses to decide if a node has room. A limit is the hard ceiling it's capped at. Exceed a memory limit and the container is OOMKilled; exceed a CPU limit and it's throttled, not killed.

Liveness vs. readiness vs. startup probes — say the difference in one line each.

Liveness: "is it stuck? restart it if so." Readiness: "is it ready for traffic right now? pull it from Service Endpoints if not, without restarting it." Startup: "give slow-booting apps extra time before liveness starts checking at all."

A Pod is stuck Pending — what are the likely causes, in order of likelihood?

No node has enough free CPU/memory to satisfy its requests; a taint on every viable node with no matching toleration; a PVC that can't bind; or a node-affinity rule that no node satisfies. kubectl describe pod's Events section names the exact one.

Taints and tolerations vs. node affinity — what's the difference in direction?

A taint repels Pods from a node unless they carry a matching toleration — the node's decision. Node affinity is the Pod attracting itself toward (or away from) nodes with certain labels — the Pod's decision. They're often combined, not interchangeable.

RBAC & Security

See Post 11

Role vs. ClusterRole, RoleBinding vs. ClusterRoleBinding?

A Role/RoleBinding pair grants permissions inside one namespace. A ClusterRole/ClusterRoleBinding pair grants permissions cluster-wide (or a reusable permission set bound per-namespace via a RoleBinding referencing a ClusterRole).

How do you check what a user or ServiceAccount can actually do, without guessing from YAML?

kubectl auth can-i <verb> <resource> --as=<user> — Post 11's core habit, and the fastest way to verify RBAC instead of reasoning about bindings by hand.

What's the "4C" model of cloud-native security?

Cloud (the underlying infrastructure), Cluster (RBAC, network policies, audit logging), Container (image scanning, minimal base images), Code (secrets management, dependency scanning) — layered defense, not one control doing everything.

What is a mutating admission webhook?

A controller the API server calls out to before persisting an object, letting it modify the object in flight — e.g. auto-injecting a sidecar into every Pod in a namespace. Validating webhooks do the same thing but only accept/reject, never modify.

Helm, StatefulSets, Jobs & CronJobs

See Post 12 & Post 13

What problem does Helm actually solve over raw YAML?

Templating and release management for multi-file, multi-environment manifests — one chart, different values.yaml per environment, with revision history and one-command rollback. Post 12 covers when raw YAML is still the better call.

Why can't a Deployment run a stateful database cluster properly?

A Deployment assumes every replica is interchangeable and gives Pods random-suffix names with no stable identity. A database node needs a name and a disk that survive restarts and follow it across reschedules — exactly what a StatefulSet's stable naming, headless-Service DNS, and per-Pod volumeClaimTemplates provide. Post 13.

Job vs. CronJob vs. Deployment — sort by "how long should the Pod live"?

Deployment: forever, restart on exit. Job: until it finishes successfully once, then stop. CronJob: a Job template that fires repeatedly on a cron schedule.

Tooling, Microservices & Architecture

See Post 14 & Post 15

What is a service mesh, and when do you actually need one?

An infrastructure layer (Istio, Linkerd) that automatically injects a sidecar proxy next to every service to handle retries, mTLS encryption, and observability uniformly — worth it once you have dozens of microservices and hand-wiring that per-service stops scaling. Post 14.

Lens/FreeLens vs. k9s vs. raw kubectl — how would you frame this to an interviewer?

Raw kubectl for exams, scripts, and CI (the only scriptable one); k9s when you're terminal-only over SSH; Lens/FreeLens for multi-cluster comparison and live metrics trends. None replace the others — see Post 15's full comparison table.

How does Kubernetes autoscaling actually work — and how many kinds are there?

Three, targeting different things: the Horizontal Pod Autoscaler changes replica count based on metrics; the Vertical Pod Autoscaler adjusts a Pod's own requests/limits; the Cluster Autoscaler adds or removes nodes. They solve different bottlenecks and are often combined.

How would you monitor a production cluster day to day?

Metrics through Prometheus + Grafana, logs through a Loki or ELK-style aggregator (raw kubectl logs doesn't scale past a handful of Pods), and alerting through Alertmanager wired to on-call. This whole stack is a natural next post beyond this series.

How do you back up and restore etcd?

etcdctl snapshot save for the backup, etcdutl snapshot restore to recover — and practice the restore before you ever need it for real, not during the incident.

Walk through upgrading a Kubernetes cluster safely.

Back up etcd first, upgrade the control plane components one minor version at a time, then upgrade worker nodes (often by draining and cordoning them one at a time), then upgrade add-ons — never skip a minor version, and never upgrade nodes before the control plane.

Interview trap, not exam trap: Interviewers can tell the difference between "I memorized the definition" and "I've actually run this command under pressure." When an answer above references a post, that's not filler — it's signaling you understand the underlying mechanic, not just the vocabulary. If a question makes you blank, that's the post to reopen before the next interview, not this reference.

Key Takeaways

  • This reference mirrors the series structure on purpose — every category maps to specific posts, so a shaky answer tells you exactly what to re-read.
  • Interviewers weight troubleshooting and scenario answers heavily in 2026 — this post covers concepts; Post 17 covers the scenario-based and production-incident questions that actually separate candidates.
  • The habit that carries every category: know the one-sentence definition, know the command that proves it (auth can-i, describe pod, rollout undo), and know which earlier object it depends on.

Next up: Post 17 — real production scenario and troubleshooting interview questions, the kind that come with "walk me through how you'd debug this" attached.

Before you go

In one sentence, what was this chapter about?

From memory, without scrolling up. Writing it is what makes it yours; the grade is only to show you what you had.

How sure?