Companion question bank for the 6-part tutorial series in this folder: 01-architecture-and-control-plane.md, 02-scheduling-and-workloads.md, 03-networking-and-storage.md, 04-service-mesh-and-advanced-topics.md, 05-managed-kubernetes-eks-aks-gke.md, 06-onprem-and-cluster-provisioning.md.

Answers are short and plain — expand out loud using the diagrams and worked examples in the tutorials.

---

Part 1 Questions: Architecture & Control Plane

1. In one sentence, what problem does Kubernetes actually solve?#

It continuously makes the actual state of your infrastructure match a desired state you declare — placing containers, restarting them on failure, routing traffic, and scaling — automatically, without a human doing it by hand.

2. What's the difference between the control plane and worker nodes?#

The control plane (API Server, etcd, Scheduler, Controller Manager) is the "brain" that makes decisions. Worker nodes (kubelet, kube-proxy, container runtime) are where containers actually run — the control plane never runs application containers itself.

3. Why does only the API Server talk directly to etcd?#

It's the single, mandatory gatekeeper to all cluster state — every other component (scheduler, controllers, kubelets) reads/writes state only by calling the API Server, which is what makes consistent authentication, authorization, and validation possible across the whole cluster.

4. Why do etcd clusters always use an odd number of nodes?#

etcd needs a strict majority to commit any write. A 4-node cluster still only tolerates 1 failure (needs 3 of 4) — the same as a 3-node cluster (needs 2 of 3) — so the extra node adds cost with zero extra fault tolerance. Odd numbers are always the efficient choice.

5. Explain the reconciliation loop pattern, and why it's the most important idea in Kubernetes.#

Observe the current actual state, compare it to the desired state, act to close any gap, repeat forever. Nearly everything in Kubernetes is built on this one pattern — it's exactly why the system self-heals with no human involvement: a controller notices a gap (like a crashed pod) on its very next pass and fixes it automatically.

6. What's the difference between what the Scheduler does and what the kubelet does?#

The Scheduler only decides WHICH node a pod should run on and records that decision — it never starts a container itself. The kubelet, running on that specific node, is what actually tells the container runtime to start it and then monitors it.

7. Distinguish liveness probes from readiness probes, and explain the classic mistake.#

Liveness: "should this container be restarted?" Readiness: "should this container receive traffic right now?" The classic mistake is letting a temporarily busy/slow (but not broken) container fail its liveness probe — restarting it discards progress and makes an overload situation worse. Readiness should handle "temporarily not ready," not liveness.

8. What does kube-proxy actually do?#

Programs real networking rules (iptables or IPVS) on every node that turn a Service's stable virtual IP into "route to one of the currently healthy pod IPs backing it" — without it, a Service's virtual IP would just be an abstract idea with nothing making it work.

9. What is the CRI, and why does it matter that Kubernetes uses a standard interface for it?#

The Container Runtime Interface — a standard API between the kubelet and whatever container runtime is actually installed (containerd, CRI-O). It's why Kubernetes could deprecate direct Docker support without breaking anything — any CRI-compliant runtime can run the same OCI-format images.

---

Part 2 Questions: Scheduling & Workload Objects

10. Describe the two-phase scheduling process.#

Filtering: which nodes are even capable of running this pod at all (a hard yes/no per node). Scoring: of the nodes that survive filtering, rank them to find the best choice. A node failing even one filter is completely disqualified, not just deprioritized.

11. What's the difference between resource requests and limits, and which one drives scheduling?#

Requests drive scheduling placement — the Scheduler guarantees a pod only lands where its requested resources are actually available. Limits drive runtime enforcement via cgroups — exceeding a CPU limit gets you throttled, exceeding a memory limit gets you OOM-killed.

12. What are the three QoS classes, and which gets evicted first under node memory pressure?#

Guaranteed (requests == limits, evicted last), Burstable (requests set, limits higher or unset, middle), BestEffort (no requests/limits at all, evicted first). Critical workloads should use Guaranteed QoS.

13. What's the difference between a taint and node affinity?#

A taint is node-side "keep out unless you have a matching toleration" — closed by default. Node affinity is pod-side "I want/require nodes with these characteristics" — opt-in from the pod's perspective.

14. Why doesn't changing a node's labels after a pod is already scheduled there cause that pod to be evicted?#

Affinity rules ending in ...IgnoredDuringExecution are only checked at scheduling time, not continuously enforced afterward — it's a one-time decision, not an ongoing invariant.

15. Why does having replicas: 3 in a Deployment not guarantee availability across a node failure?#

Replica count says nothing about WHERE the pods end up — without pod anti-affinity, the Scheduler could place all 3 on the same node, silently creating a single point of failure that looks perfectly healthy (3/3 Running) until that node dies.

16. Why does a Deployment manage pods through an intermediate ReplicaSet instead of directly?#

It's exactly what makes rolling updates and instant rollbacks possible — a new version gets a brand-new ReplicaSet, while the old one is kept around scaled to zero. kubectl rollout undo just flips which ReplicaSet is scaled up, without needing to reconstruct the old config from scratch.

17. What do maxSurge and maxUnavailable control during a rolling update?#

maxSurge: how many extra pods above the desired count are allowed temporarily (faster rollout, more resource usage). maxUnavailable: how much capacity can be briefly missing (faster rollout, less safety margin). Both at 0 would make a rollout impossible.

18. Why do StatefulSets exist when Deployments already work fine for most apps?#

Deployment pods get random names and no stable identity — fine for interchangeable stateless apps. Some workloads (databases) need a stable, predictable identity and their SAME storage reattached every time they restart — that's exactly what StatefulSets provide.

19. When would you use a DaemonSet instead of a Deployment?#

When you need exactly one copy of a pod on every (or every matching) node — log-shipping agents, monitoring agents, CNI components — rather than an arbitrary replica count.

20. Why does using a Deployment for a one-time batch script cause it to loop forever?#

A Deployment's pods always use restartPolicy: Always, since Deployments are designed to run forever — Kubernetes has no way to know the script's successful exit was the intended end state rather than a crash. Use a Job instead, which correctly understands "successful exit means done."

---

Part 3 Questions: Networking (CNI) & Storage (CSI)

21. What are the core rules of the Kubernetes networking model?#

Every pod gets its own unique IP; every pod can reach every other pod's IP directly, with no NAT, cluster-wide; a pod sees its own IP the same way everyone else sees it. A deliberately "flat" network model.

22. What does CNI do, and why does it matter which specific CNI plugin a cluster runs?#

CNI is the standard plugin interface that actually implements pod networking (and, for some plugins, NetworkPolicy enforcement). Some CNI plugins don't enforce NetworkPolicy at all — a policy YAML can apply successfully with zero actual effect if the cluster's CNI plugin doesn't support it.

23. Why do containers within the same pod talk to each other over localhost?#

They share the pod's single IP and network namespace — exactly the mechanical foundation of the sidecar pattern (covered fully in Part 4).

24. What problem does a Kubernetes Service solve?#

Pods are disposable and constantly get new IPs as they're created/destroyed. A Service provides a stable virtual IP/DNS name that never changes, automatically load-balancing across whichever pods currently match its label selector and are healthy.

25. Name the four Service types and what each is for.#

ClusterIP (internal-only, the default), NodePort (exposes on every node's IP at a fixed port), LoadBalancer (provisions a real external cloud load balancer), ExternalName (a pure DNS alias to something outside the cluster).

26. What's the exact mechanism connecting a failed readiness probe to traffic actually stopping?#

The EndpointSlice controller notices the pod is no longer Ready and removes its IP from the EndpointSlice backing the Service. kube-proxy, watching EndpointSlices, updates its routing rules — traffic simply stops being routed there, even though the container is still technically alive.

27. Does an Ingress object do anything by itself?#

No — it's just a set of routing rules. Nothing happens without an Ingress Controller actually running in the cluster to read those rules and configure real routing (the same "API object declares it, something else implements it" pattern as CNI and CSI).

28. What's the difference between a PersistentVolume and a PersistentVolumeClaim?#

A PV represents actual, real storage that exists (an EBS volume, an NFS share). A PVC is an application's request for storage with certain characteristics — Kubernetes binds the claim to a matching volume, so the app never needs to know the underlying implementation.

29. What does a StorageClass enable, and why does reclaimPolicy matter?#

Dynamic provisioning — automatically creating a real storage volume on demand the moment a matching PVC is created, instead of manually pre-creating PVs. reclaimPolicy: Delete destroys the underlying storage the instant its PVC is deleted; Retain keeps it around, which is the safer choice for genuinely critical data.

30. Why do StatefulSets use volumeClaimTemplates instead of one shared volume reference?#

ReadWriteOnce storage (the common case, like most block storage) can only be attached read-write to one node at a time — sharing one PVC across replicas either fails outright or causes data corruption. volumeClaimTemplates gives each replica its own dedicated PVC, permanently tied to that replica's specific identity.

---

Part 4 Questions: Service Mesh, etcd & Operators

31. What problem does a service mesh solve that plain Kubernetes networking doesn't?#

Consistent mTLS, retries, and observability across every service, applied uniformly at the infrastructure layer — without every application team having to reimplement the same logic in their own code, in their own language.

32. How does the sidecar pattern actually work, mechanically?#

iptables rules inside the pod's network namespace transparently redirect all inbound/outbound traffic through a sidecar proxy container. The application makes a normal-looking network call with zero awareness this redirection is happening.

33. What's the difference between a mesh's control plane and data plane?#

The control plane (e.g. Istiod) centrally defines policy (routing rules, mTLS settings). The data plane is every individual sidecar proxy actually enforcing that policy on real traffic, in real time — the control plane never touches an actual request itself.

34. Why does mTLS between services matter, tied back to STRIDE?#

It defends against Spoofing (a rogue pod can't impersonate a legitimate service without a valid cert) and Information Disclosure (all inter-service traffic is encrypted, even inside the cluster) — applied automatically to every service, with zero app code changes.

35. Why does a service mesh give you RED metrics "for free"?#

Since 100% of traffic to and from a pod already flows through its sidecar, that sidecar is perfectly positioned to observe and report request rate, errors, and duration for every service automatically — no per-language, per-team instrumentation needed.

36. What are the real costs of adopting a service mesh?#

Added latency (every request hops through two extra proxies), added resource usage (every pod runs an extra sidecar container), and added operational complexity (a whole new control-plane system to run and understand).

37. Why does etcd need regular compaction and defragmentation?#

etcd keeps a full history of every change (unbounded growth if left alone). Compaction discards old, superseded revisions; defragmentation actually reclaims the freed space on disk. Skipping both can eventually hit etcd's storage quota, blocking ALL writes cluster-wide.

38. Why is an untested etcd backup not actually a safety net?#

A backup that's never been restored is a hypothesis, not a verified recovery path — exactly the chaos engineering principle of testing assumptions before reality does. Teams should periodically practice a full restore drill in non-production.

39. Does creating a CRD, by itself, make anything happen?#

No — a CRD only defines a data shape the API server will accept and store. Nothing acts on objects of that type unless a separate controller (an Operator) is actually deployed and watching for them.

40. What is an Operator, and why can it do things a generic StatefulSet can't?#

A custom controller following the same reconciliation loop pattern as any built-in controller, but built to manage a CRD. It encodes actual domain-specific operational knowledge (like how to safely fail over a specific database) as running code — something a generic StatefulSet has zero built-in concept of.

41. What problem does Helm solve?#

Packaging a multi-file, multi-environment Kubernetes application (Deployment, Service, ConfigMap, Ingress, etc.) into one versioned, repeatable, auditable install/upgrade/rollback — instead of manually applying many interdependent YAML files by hand, inconsistently, across environments.

---

Part 5 Questions: Managed Kubernetes — EKS, AKS, GKE

42. Why does managed Kubernetes exist, tied back to a concept from the SRE Fundamentals series?#

Running your own control plane (etcd HA, API server upgrades, certificate rotation) is genuine, ongoing operational toil. Managed Kubernetes shifts that specific toil to the cloud provider, letting your team focus on workloads instead.

43. Explain the shared responsibility model as applied to Kubernetes.#

The cloud provider manages the control plane (API server, etcd, scheduler) — always. You remain responsible for worker node patching (unless using a fully serverless compute option), RBAC configuration, workload security, and your application's actual reliability. "Managed" almost always means the control plane specifically, not everything.

44. Compare EKS's two compute options.#

EC2 managed node groups: you choose instance types, still responsible for node-level OS patching, but full flexibility (DaemonSets work fine). Fargate: fully serverless, zero node management, but real constraints (no DaemonSets, since there's no persistent shared node) and typically higher cost per unit of compute.

45. What is IRSA, and what problem does it solve?#

IAM Roles for Service Accounts — lets an EKS pod assume a real, scoped AWS IAM role via OIDC federation, getting short-lived, automatically-rotating credentials with zero long-lived AWS keys ever stored in the cluster. Directly eliminates the credential-leak risk covered in the DevSecOps series' secrets management tutorial.

46. Why can EKS's VPC CNI cause a real capacity planning issue that an overlay-network CNI wouldn't?#

It assigns pods real, routable IPs directly from your VPC's own address space rather than an overlay network — meaning pods are limited by your VPC's actual IP capacity, and running out of available VPC IPs for pods is a real, concrete operational issue at scale.

47. What's GKE Autopilot, and how is it different from standard node-pool-based Kubernetes?#

A fully serverless GKE mode where Google manages the underlying nodes entirely — you only think about pods, never nodes, and billing is per-pod resource usage instead of per-node. It's the closest thing to "fully serverless Kubernetes" among the three major providers' default offerings, trading some low-level customization flexibility for that abstraction.

48. What do GKE Release Channels solve?#

They formalize "how aggressively should we adopt new Kubernetes versions" as an explicit, pre-curated choice (Rapid/Regular/Stable) matching different real risk tolerances, instead of every team independently managing their own upgrade cadence.

49. Do EKS's IRSA, AKS's Azure AD Workload Identity, and GKE's Workload Identity solve different problems?#

No — they solve the exact same problem, the exact same way (OIDC federation between a Kubernetes ServiceAccount and the cloud provider's IAM system, eliminating long-lived credentials). Only the provider-specific configuration and naming differ.

50. Does a managed control plane remove your responsibility for handling node upgrades gracefully?#

No — the "cordon and drain" upgrade process still relies on your pods handling SIGTERM properly and having correct readiness probes. A managed provider automates the mechanical upgrade process, but a pod that doesn't shut down gracefully can still be abruptly disrupted during what's supposed to be a graceful node upgrade.

---

Part 6 Questions: On-Prem & Self-Managed Kubernetes

51. Name concrete, real reasons an organization would self-manage Kubernetes instead of using a managed offering.#

Data residency/regulatory requirements, cost at genuine scale for steady predictable workloads, existing data center investment, latency-sensitive edge/industrial workloads, and air-gapped/highly regulated environments with no internet connectivity permitted.

52. What does kubeadm actually do, and what does it deliberately NOT do?#

It bootstraps a new cluster's control plane and lets new nodes join an existing cluster, plus handles in-place control-plane version upgrades. It deliberately does NOT provision underlying VMs/hardware, install a CNI plugin, or handle ongoing day-2 operations (monitoring, backup automation, node patching) — all of that is left entirely to you.

53. Why would kubectl get nodes show a control-plane node as NotReady immediately after kubeadm init?#

Because kubeadm doesn't install a CNI plugin as part of bootstrapping — without pod networking functional, the node correctly reports NotReady until a CNI plugin (Flannel, Calico, Cilium, etc.) is applied.

54. What are k3s and k0s, and what's their core tradeoff versus kubeadm?#

Lightweight, single-binary, opinionated, batteries-included Kubernetes distributions (built-in CNI, ingress, storage) — popular for edge/IoT and fast dev environments. The tradeoff: dramatic setup simplicity in exchange for less flexibility than kubeadm's unopinionated, bring-your-own-everything approach.

55. Explain Cluster API's core idea in one sentence, tied back to Part 1.#

It applies Kubernetes's own declarative reconciliation-loop pattern (observe, compare, act) one level up — instead of managing Pods, its controllers manage the lifecycle of entire Kubernetes clusters across many infrastructure providers.

56. What problem does Rancher solve that's distinct from Cluster API's focus?#

Rancher provides unified RBAC, policy, and observability across a heterogeneous, multi-cluster, multi-provider fleet (on-prem, EKS, AKS, edge, all at once). Cluster API focuses on declarative cluster lifecycle automation — the two are complementary, and larger organizations often use both.

57. What's distinctive about Talos Linux, and what security philosophy does it extend?#

It's an immutable OS with no SSH and no shell at all — managed entirely through a declarative API. It extends the same minimal-attack-surface philosophy as distroless container images (DevSecOps series) to the host OS itself: an attacker with some access has dramatically less to actually do, and every legitimate change goes through an auditable, declarative path.

58. Why does creating a type: LoadBalancer Service on bare metal just sit in Pending state without MetalLB?#

On cloud providers, that Service type automatically triggers provisioning of a real cloud load balancer behind the scenes. On bare metal, there's no equivalent cloud API to call — MetalLB fills this exact gap using real networking protocols (ARP or BGP) to announce an IP from a configured pool.

59. Why is local-path-provisioner-style storage risky for genuinely critical bare-metal data?#

It uses local disk on each individual node with no redundancy — if that specific node dies, the data is gone. Rook (managing Ceph) provides genuinely distributed, replicated storage as a Kubernetes-native Operator instead, conceptually similar to how a cloud provider's managed disks work under the hood.

60. What does an air-gapped Kubernetes environment require that a normal setup doesn't?#

Standard setup assumes internet access for pulling container images and Helm charts — an air-gapped environment has none of that, so every dependency must be deliberately pre-staged in a private, internal registry, with every cluster component explicitly configured to pull only from it.

---

Quick-Fire / Rapid Recall#