Level 4 — Production · wrap-up
Cheat sheet & self-check
23 questions across 6 lessons. Each answer links back to the lesson it came from.
Pick an answer to see if you got it, and why.
Q1. In a 'stacked' HA topology, where does etcd run?
Show answer
B. Stacked = each control-plane node also runs an etcd member. It needs fewer machines; losing a node removes both an API server and an etcd member.
From lesson 22 · HA control plane & load balancingQ2. Why do kubelets and kubeconfigs point at a load balancer or VIP instead of one control-plane node?
Show answer
B. The stable endpoint hides individual node failures. If everything pointed at cp1, losing cp1 would break every client even with cp2 and cp3 healthy.
From lesson 22 · HA control plane & load balancingQ3. Three API servers are running. How many schedulers are actively scheduling at any moment?
Show answer
B. The scheduler and controller manager use leader election. One instance holds the lease and acts; the others take over if it stops renewing.
From lesson 22 · HA control plane & load balancingQ4. You join a new control-plane node the day after 'kubeadm init --upload-certs'. The join fails to fetch certificates. Why?
Show answer
B. For safety, the encrypted certificate Secret is deleted after two hours. Upload again to get a fresh certificate key.
From lesson 22 · HA control plane & load balancingQ5. A container exceeds its CPU limit. What happens?
Show answer
B. CPU is compressible. The kernel's CFS quota throttles the container. Memory is not compressible: exceeding a memory limit gets the container OOMKilled.
From lesson 23 · Resource management & QoSQ6. Which QoS class does a pod get when every container sets CPU and memory requests equal to limits?
Show answer
C. Guaranteed requires requests == limits for both CPU and memory in every container. Such pods are the last to be evicted under node pressure.
From lesson 23 · Resource management & QoSQ7. What does the scheduler use to decide whether a pod fits on a node?
Show answer
B. Scheduling is based on requests, not live usage. Over-large requests waste capacity; missing requests let nodes get overloaded.
From lesson 23 · Resource management & QoSQ8. What's the difference between a LimitRange and a ResourceQuota?
Show answer
B. LimitRange shapes each container (defaults, bounds). ResourceQuota limits what the whole namespace may consume in total.
From lesson 23 · Resource management & QoSQ9. An HPA targets 50% CPU utilisation but never scales, showing '<unknown>/50%'. What's most likely missing?
Show answer
B. Utilisation is usage divided by the request. Without metrics-server there's no usage; without requests there's nothing to divide by.
From lesson 24 · AutoscalingQ10. Pods are Pending because no node has room. Which component adds nodes?
Show answer
B. The HPA only creates more pods. Node autoscalers react to unschedulable pods by adding capacity.
From lesson 24 · AutoscalingQ11. Why avoid an HPA on CPU and a VPA in auto mode on the same Deployment?
Show answer
B. Both react to the same signal. Use the VPA in recommendation mode, or scale the HPA on a different (custom or external) metric.
From lesson 24 · AutoscalingQ12. Which tool can scale a queue worker down to zero replicas when the queue is empty?
Show answer
B. KEDA watches event sources and can scale a workload between 0 and N. A plain HPA's minimum is normally 1.
From lesson 24 · AutoscalingQ13. What is a 'canary cluster' in an upgrade programme?
Show answer
B. Upgrading in waves (canary → dev → staging → production groups) turns surprises into small incidents in the first wave, not a fleet-wide outage.
From lesson 25 · Cluster lifecycle at scaleQ14. Why do many platforms replace nodes instead of upgrading them in place?
Show answer
B. Replacing nodes with a new, tested image avoids configuration drift between nodes and makes both roll-forward and roll-back predictable.
From lesson 25 · Cluster lifecycle at scaleQ15. An upgrade wave's post-checks fail on 1 of 10 clusters. What should the automation do?
Show answer
B. A failed gate should stop the rollout. Investigate the outlier; don't spread a possible problem to the next, usually more important, wave.
From lesson 25 · Cluster lifecycle at scaleQ16. A big cluster's API gets slow and etcd shows high fsync latency. What's the most effective fix?
Show answer
B. etcd writes must be fsynced to disk before they're acknowledged. Slow disks make every write, and therefore the whole API, slow.
From lesson 26 · Performance tuningQ17. What does API Priority and Fairness (APF) do?
Show answer
B. APF puts requests into priority levels and queues, protecting system components and other tenants from a misbehaving controller or script.
From lesson 26 · Performance tuningQ18. Which client pattern is kindest to the API server?
Show answer
B. Informers list once and then stream changes via watch. Frequent full LISTs are among the most expensive API calls.
From lesson 26 · Performance tuningQ19. What is the default maximum number of pods per node for the kubelet?
Show answer
B. The kubelet's maxPods defaults to 110. It can be changed, but IP address space, CNI limits and per-pod overhead matter.
From lesson 26 · Performance tuningQ20. Your RPO is 1 hour. What does that require?
Show answer
B. RPO is about data loss (how old the latest recoverable copy may be). RTO is about how long recovery takes.
From lesson 27 · Disaster recoveryQ21. Which combination rebuilds a lost cluster most reliably?
Show answer
B. Git recreates what should run; backups restore what was stored. etcd snapshots restore a specific cluster's exact state.
From lesson 27 · Disaster recoveryQ22. What does a Velero restore NOT automatically recover?
Show answer
B. Velero backs up Kubernetes objects and, if configured, the cluster's volumes. Databases outside the cluster need their own backup and recovery.
From lesson 27 · Disaster recoveryQ23. Why run timed restore drills?
Show answer
B. Untested backups fail in surprising ways (missing credentials, wrong regions, incompatible versions). A timed drill turns an RTO target into a measured fact.
From lesson 27 · Disaster recovery