Cheat sheet & self-check

Pick an answer to see if you got it, and why.

1. Q1. Why do partial rollouts cause incidents even when the new version is fine?

   1. AThey don't
   2. BOther changes assume all instances are upgraded (e.g. a schema change, a new message format, removing an old endpoint), so the remaining old instances break
   3. COld versions are always buggy
   4. DKubernetes rejects mixed versions
   Show answer

   B. The failure is in the assumption 'everyone has upgraded', not in either version alone.

   From lesson 04 · Partial rollouts

2. Q2. What's the expand/contract pattern?

   1. AScaling pods up and down
   2. BMaking a breaking change in compatible steps: add the new form alongside the old (expand), move all clients to it, and only then remove the old form (contract)
   3. CA compression method
   4. DA Helm feature
   Show answer

   B. At every step, old and new versions can both work, so mixed-version periods are safe.

   From lesson 04 · Partial rollouts

3. Q3. What's a good gate before running a 'contract' step (e.g. dropping an old column)?

   1. AA calendar reminder
   2. BVerified inventory showing no instance anywhere still runs a version that uses the old form (all clusters, sites and batch jobs)
   3. CAsking in chat
   4. DWaiting one hour
   Show answer

   B. Make completion a measured fact, not an assumption.

   From lesson 04 · Partial rollouts

4. Q4. A cleanup job deletes 'unused' namespaces across all clusters. Its label selector has a bug. Which guard rail would have limited the damage most?

   1. AA faster job
   2. BA percentage/count limit (e.g. stop after 5 deletions or 1% of targets per run) plus a dry-run diff reviewed before the first real run
   3. CMore logging only
   4. DRunning it at night
   Show answer

   B. Limits cap the damage of an unknown bug; dry runs catch known-visible mistakes.

   From lesson 05 · Automation blast radius

5. Q5. Why does Kubernetes slow down pod evictions when many nodes in a zone become unhealthy?

   1. ATo save CPU
   2. BMass node failure often means a network or control-plane problem, not dead nodes; evicting everything would make it worse, so the node controller reduces or stops evictions
   3. CIt's a bug
   4. DFor billing
   Show answer

   B. It's a built-in blast-radius control: when the signal is suspicious, act slowly.

   From lesson 05 · Automation blast radius

6. Q6. What does a PodDisruptionBudget protect against?

   1. ANode hardware failure
   2. BVoluntary disruptions (drains, upgrades, autoscaler scale-down) removing too many pods of an application at once
   3. CImage pull errors
   4. DDNS outages
   Show answer

   B. PDBs make automation respect application availability; involuntary failures aren't covered.

   From lesson 05 · Automation blast radius

7. Q7. After a power cut, a 3-node RabbitMQ StatefulSet with OrderedReady pod management never recovers. Why might that be?

   1. ARabbitMQ can't run on Kubernetes
   2. BPod-0 waits for its cluster peers before becoming ready, but OrderedReady won't start pod-1 until pod-0 is ready, so they deadlock; Parallel pod management (as the RabbitMQ operator uses) avoids it
   3. CToo little memory
   4. DDNS is too fast
   Show answer

   B. Clustered systems that wait for peers on boot need all members started together.

   From lesson 06 · Cold-start dependency loops

8. Q8. What's the core fix for circular bootstrap dependencies?

   1. AMore replicas
   2. BA tiered dependency map where each tier can start using only lower tiers, plus out-of-band options (local mirrors, break-glass access, external Git/registry copies) for the lowest tiers
   3. CFaster disks
   4. DRestarting everything twice
   Show answer

   B. If tier 1 needs tier 2 to start, you have a loop. Break it by design, then prove it with a cold-start drill.

   From lesson 06 · Cold-start dependency loops

9. Q9. Why run a cold-start drill?

   1. AFor fun
   2. BNormal operation never exercises 'everything starts at once from zero'; only a drill shows hidden loops, ordering problems and missing credentials
   3. CAuditors require weekly drills
   4. DIt speeds up nodes
   Show answer

   B. Many platforms run for years without a full restart, and discover their loops during the worst possible outage.

   From lesson 06 · Cold-start dependency loops

10. Q10. Why is 'CPU above 90%' a poor paging alert?

    1. ACPU can't be measured
    2. BHigh CPU often doesn't hurt users (and sometimes means efficient use), while real user-facing failures can happen with normal CPU; paging on it causes fatigue and misses real problems
    3. CIt's too slow
    4. DKubernetes hides CPU
    Show answer

    B. Page on user impact (symptoms). Keep CPU on dashboards and capacity tickets.

    From lesson 07 · Symptom-based monitoring

11. Q11. Which alert is symptom-based?

    1. ANode disk 85%
    2. BCheckout success rate burning the 30-day error budget 14× too fast
    3. CPod restarted
    4. DKafka partition leader changed
    Show answer

    B. It describes what users experience; the others are potential causes.

    From lesson 07 · Symptom-based monitoring

12. Q12. What's a good first step in reducing alert fatigue?

    1. ADelete all alerts
    2. BReview every alert that paged in the last month: was it actionable and urgent? Convert non-urgent ones to tickets, delete ones nobody acts on, and add missing symptom alerts
    3. CAdd more alerts
    4. DMute the pager at night
    Show answer

    B. An evidence-based review usually removes a large share of pages without losing coverage.

    From lesson 07 · Symptom-based monitoring