Cheat sheet & self-check

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

1. Q1. Why include the misleading first signal in an RCA?

   1. ATo blame someone
   2. BIt shows how the investigation could go wrong again, and often reveals monitoring or dashboards that point responders at effects instead of causes
   3. CFor length
   4. DIt's legally required
   Show answer

   B. Improving how incidents are investigated is as valuable as fixing the specific bug.

   From lesson 01 · The shape of a strong RCA

2. Q2. Why is 'human error' a poor root cause?

   1. AHumans never err
   2. BIt stops the analysis too early; the useful question is why the system allowed a normal mistake to cause an outage (missing guard rails, confusing tools, no review, no canary)
   3. CIt's too long
   4. DIt's always the vendor's fault
   Show answer

   B. Blameless analysis finds system fixes that prevent the next person making the same mistake.

   From lesson 01 · The shape of a strong RCA

3. Q3. Which is the strongest prevention item?

   1. ARemind the team to check cron schedules
   2. BA CI policy that rejects CronJobs scheduled at minute 0 without jitter, plus NodeLocal DNSCache on all clusters (owner: platform team, due in 3 weeks)
   3. CMonitor more
   4. DBe careful with DNS
   Show answer

   B. It's specific, automated, owned, dated, and removes the class of failure rather than relying on memory.

   From lesson 01 · The shape of a strong RCA

4. Q4. Why shouldn't the incident commander debug the problem themselves?

   1. AThey're not allowed to know technology
   2. BCoordinating (roles, decisions, communication, time) is a full-time job; an IC deep in logs loses sight of the whole incident
   3. CDebugging is slow
   4. DIt's a legal rule
   Show answer

   B. Separate thinking about the system from thinking about the incident.

   From lesson 02 · Incident command & communication

5. Q5. What must every status update contain?

   1. AOnly good news
   2. BCurrent impact, what's known, what's being done, and when the next update will come
   3. CFull logs
   4. DThe root cause
   Show answer

   B. Predictable updates stop stakeholders interrupting responders for news.

   From lesson 02 · Incident command & communication

6. Q6. Why declare an incident early, even if unsure of severity?

   1. ATo create paperwork
   2. BIt gathers help and starts communication while the problem is small; downgrading or closing a false alarm costs little, whereas late declaration extends outages
   3. CIt's required hourly
   4. DTo page everyone always
   Show answer

   B. Most organisations under-declare. Make declaring cheap and normal.

   From lesson 02 · Incident command & communication

7. Q7. Why is a liveness probe that checks the database dangerous?

   1. AIt's slow
   2. BWhen the database has a hiccup, every pod fails liveness and is restarted at once, turning a dependency blip into a full outage (and a restart storm)
   3. CLiveness probes can't reach databases
   4. DIt uses too much memory
   Show answer

   B. Liveness should answer 'is this process stuck?'. Dependency checks belong in readiness (carefully) or nowhere.

   From lesson 03 · Architecture antipatterns

8. Q8. The container registry is down. Why might running workloads also fail?

   1. AThey can't
   2. BAny pod restart, reschedule or scale-up needs to pull images; with imagePullPolicy Always or on new nodes without cached images, pods can't start
   3. CRegistries run the pods
   4. DDNS depends on the registry
   Show answer

   B. Registries are a hidden dependency of every restart. Mirrors, caches and digests with IfNotPresent reduce the risk.

   From lesson 03 · Architecture antipatterns

9. Q9. What is 'shared fate'?

   1. ATeam spirit
   2. BSupposedly redundant components that fail together because they share something: power, network, a config source, a software version, or an operator's command
   3. CA Kubernetes feature
   4. DA backup type
   Show answer

   B. Redundancy only helps if failures are independent.

   From lesson 03 · Architecture antipatterns