Cheat sheet & self-check

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

1. Q1. What does acknowledging a page communicate?

   1. AThe problem is fixed
   2. BSomeone owns the response now, so the alert stops escalating and others know not to duplicate work
   3. CThe alert was a false positive
   4. DThe incident is SEV1
   Show answer

   B. Acknowledge fast, even before you know anything; then assess.

   From lesson 01 · Answering the page

2. Q2. The error rate jumped right after a deploy 10 minutes ago. What's usually the best first action?

   1. ADebug the new code in production
   2. BRoll back (or disable the feature flag) to stop user impact, then investigate with less pressure
   3. CWait to see if it recovers
   4. DRestart all nodes
   Show answer

   B. Stabilise first. Root cause can wait; users can't.

   From lesson 01 · Answering the page

3. Q3. Why start a timeline immediately?

   1. AManagers like it
   2. BTimes, actions and findings noted as they happen make handovers, updates and the RCA accurate; memory is unreliable at 2 a.m.
   3. CIt's required by Kubernetes
   4. DTo assign blame
   Show answer

   B. A few lines per action in the incident channel is enough.

   From lesson 01 · Answering the page

4. Q4. Only pods on one node are failing. What does that suggest?

   1. AAn application bug
   2. BA node-level problem (disk, network, kubelet, runtime, kernel) rather than the application or the whole cluster
   3. CDNS is down everywhere
   4. DThe Ingress is wrong
   Show answer

   B. Scoping by node, zone or version points you at the right layer immediately.

   From lesson 02 · Where to start troubleshooting

5. Q5. Why walk the request path outside-in (edge → ingress → service → pods → nodes)?

   1. AIt's alphabetical
   2. BIt follows what the user experiences and finds the first broken hop, instead of guessing at internals that may be fine
   3. CPods are always the cause
   4. DIt avoids using kubectl
   Show answer

   B. The first hop that fails tells you where to dig.

   From lesson 02 · Where to start troubleshooting

6. Q6. You have three theories. Which do you test first?

   1. AThe most interesting one
   2. BThe one that's cheapest and quickest to confirm or rule out, especially if it's also likely
   3. CAll at once
   4. DNone; wait for more data
   Show answer

   B. Quick eliminations shrink the search space fast. Change one thing at a time.

   From lesson 02 · Where to start troubleshooting

7. Q7. You've been investigating alone for 25 minutes, impact is growing, no mitigation yet. What now?

   1. AKeep going quietly
   2. BEscalate: declare/raise severity, page the service owner or secondary, and share what you've ruled out
   3. CWait for the morning
   4. DRestart everything
   Show answer

   B. Escalating early is good practice, not a failure. Most organisations wish people escalated sooner.

   From lesson 03 · Engaging people & communicating

8. Q8. What makes a request for help effective?

   1. A"Help, it's broken"
   2. BService + impact + since when, what's already done/ruled out, a specific ask and where to join
   3. CA long essay
   4. DTagging everyone
   Show answer

   B. People can act in seconds instead of asking ten questions.

   From lesson 03 · Engaging people & communicating

9. Q9. Why open a cloud/vendor support case early during a suspected provider issue?

   1. AIt's never useful
   2. BSupport queues take time; opening early with severity, resource IDs, timestamps and errors gets experts engaged while you keep mitigating
   3. CIt fixes it automatically
   4. DTo avoid internal escalation
   Show answer

   B. You can always close the case if it turns out to be your side.

   From lesson 03 · Engaging people & communicating

10. Q10. Where should a runbook be linked from?

    1. ANowhere, people will find it
    2. BThe alert itself (e.g. a runbook_url annotation), so the on-call engineer lands on it from the page
    3. CA PDF on someone's laptop
    4. DOnly the wiki homepage
    Show answer

    B. The runbook is only useful if it's one click from the page.

    From lesson 04 · Runbooks & the knowledge base

11. Q11. What makes a known-issue entry findable during an incident?

    1. AA clever title
    2. BThe exact error messages and symptoms people will see and search for, plus clear actions
    3. CLong background history
    4. DBeing in a private chat
    Show answer

    B. People search for what's on their screen. Put the literal error text in the entry.

    From lesson 04 · Runbooks & the knowledge base

12. Q12. When should a runbook step be automated?

    1. ANever
    2. BWhen it's frequent, well understood, safe and verifiable, with the human still deciding for risky actions
    3. CAlways, immediately
    4. DOnly for SEV1
    Show answer

    B. Automate the boring, proven steps first; keep judgement where it matters.

    From lesson 04 · Runbooks & the knowledge base

13. Q13. What's wrong with the root cause 'engineer forgot to renew the certificate'?

    1. ANothing
    2. BIt blames a person and stops too early; the useful question is why renewal depended on memory and why expiry wasn't alerted
    3. CIt's too short
    4. DCertificates never expire
    Show answer

    B. Blameless RCAs find system fixes: automation, monitoring, checks.

    From lesson 05 · Writing the RCA

14. Q14. Which is a good action item?

    1. ABe more careful with certificates
    2. BAdd an alert when any cluster certificate expires within 30 days (owner: platform, due 15 Oct), and automate renewal via upgrades
    3. CImprove monitoring
    4. DDiscuss certificates
    Show answer

    B. Specific, owned, dated and verifiable.

    From lesson 05 · Writing the RCA

15. Q15. Why record 'what went well' too?

    1. ATo feel good
    2. BIt preserves practices that worked (fast rollback, good runbook) so they're kept and spread, not accidentally removed
    3. CRequired by law
    4. DTo shorten the document
    Show answer

    B. Learning includes recognising what to keep doing.

    From lesson 05 · Writing the RCA

16. Q16. etcd filled up because of event churn. Which fix is 'eliminate' rather than 'detect'?

    1. AAn alert at 80% of quota
    2. BFind and fix the source of the churn (e.g. a controller writing constantly) and set sensible limits so it can't recur
    3. CA runbook for defragmentation
    4. DPaging faster
    Show answer

    B. Detection is valuable too, but removing the cause beats catching it every time.

    From lesson 06 · Preventing the repeat

17. Q17. What's a leading indicator?

    1. AThe first alert of the night
    2. BA signal that warns before users are hurt, like disk at 80% and rising, or a certificate 30 days from expiry
    3. CThe incident commander
    4. DA log line
    Show answer

    B. Leading indicators turn incidents into planned work.

    From lesson 06 · Preventing the repeat

18. Q18. Why verify a fix with a test, drill or chaos experiment?

    1. ABureaucracy
    2. BFixes that are never exercised often don't work when needed; verification proves the failure is now prevented or handled
    3. CIt's faster than coding
    4. DTo close tickets
    Show answer

    B. An untested fix is a hope.

    From lesson 06 · Preventing the repeat