Cheat sheet & self-check

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

1. Q1. Why should the monitoring backends not live only inside the production cluster they monitor?

   1. ACost
   2. BIf that cluster fails, you lose the tool you need to diagnose it; keep central storage/alerting elsewhere (mgmt cluster or other site) plus meta-monitoring
   3. CKubernetes forbids it
   4. DFor licensing
   Show answer

   B. Observability must survive the failures it's meant to explain.

   From lesson 10 · Observability & SLOs

2. Q2. All internal health checks pass but users fail. Which SLO was likely missing from the design?

   1. ANode CPU
   2. BA user-journey SLI measured from outside (synthetic checks and edge/ingress success rates), not just service-internal metrics
   3. CDisk usage
   4. DPod count
   Show answer

   B. Internal checks can't see DNS, CDN/WAF, TLS or routing failures before traffic reaches the service.

   From lesson 10 · Observability & SLOs

3. Q3. What must every alert in the catalogue have?

   1. AA colour
   2. BAn owner, a severity with a clear notification route, and a runbook explaining what to check and do
   3. CA dashboard only
   4. DAt least 10 conditions
   Show answer

   B. Alerts without owners and runbooks get ignored or cause confused incident response.

   From lesson 10 · Observability & SLOs

4. Q4. In an FMEA, what does the RPN (risk priority number) represent?

   1. ACost
   2. BSeverity × Occurrence × Detection, a way to rank failure modes so the riskiest (severe, likely, hard to detect) are addressed first
   3. CNumber of replicas
   4. DRecovery time
   Show answer

   B. RPN is a prioritisation aid, not an absolute measure; also look at any single high severity score.

   From lesson 11 · Resilience & failure modes

5. Q5. What's a steady-state hypothesis in a chaos experiment?

   1. AThe cluster never fails
   2. BA measurable statement of normal behaviour (e.g. tracking API success ≥ 99.95% and p99 < 300 ms) that should still hold while the fault is injected
   3. CA YAML file
   4. DThe number of pods
   Show answer

   B. The experiment tests whether the system keeps its steady state under the fault.

   From lesson 11 · Resilience & failure modes

6. Q6. Why does a high 'Detection' score (hard to detect) raise priority?

   1. AIt doesn't
   2. BFailures you can't see last longer and do more damage; improving monitoring can lower risk as much as preventing the failure
   3. CDetection is about hardware only
   4. DIt lowers cost
   Show answer

   B. Better alerts and synthetic checks reduce D, and therefore RPN.

   From lesson 11 · Resilience & failure modes

7. Q7. Why must the old primary database be fenced before promoting the secondary?

   1. AFor speed
   2. BIf both accept writes (split-brain), data diverges and is very hard to reconcile; fencing guarantees the old primary can't take writes
   3. CKubernetes requires it
   4. DTo save disk
   Show answer

   B. Fencing can be power-off, network isolation, or revoking access; it must be certain before promotion.

   From lesson 12 · Primary/secondary & failover

8. Q8. What keeps the secondary site's clusters in the same configuration as the primary?

   1. AManual copying
   2. BGitOps from the same repository (with site-specific values), so both sites converge to the same desired state continuously
   3. CBackups only
   4. DNothing is needed
   Show answer

   B. Drift between sites is a classic reason failovers fail.

   From lesson 12 · Primary/secondary & failover

9. Q9. Why is an untested DR plan risky?

   1. AIt isn't
   2. BHidden dependencies (DNS TTLs, hardcoded endpoints, missing secrets, capacity, expired credentials) only appear when you actually fail over; drills find them safely
   3. CIt uses more disk
   4. DAuditors dislike it
   Show answer

   B. The first real failover shouldn't be the first failover.

   From lesson 12 · Primary/secondary & failover

10. Q10. What's the purpose of an NFR traceability table in a design document?

    1. ADecoration
    2. BIt shows, for every requirement, where the design addresses it, which decision records justify it, and what evidence proves it, so gaps are obvious
    3. CTo list team members
    4. DTo replace ADRs
    Show answer

    B. Reviewers look for requirements with no design answer or no evidence.

    From lesson 13 · Capstone: design review

11. Q11. A reviewer asks, 'What happens if DC-B's management cluster is down during a DC-A failure?' A good answer…

    1. ASays it can't happen
    2. BExplains the actual behaviour (what still works, what doesn't), the likelihood, the mitigation or accepted risk, and where it's recorded (FMEA/risk register)
    3. CChanges the topic
    4. DPromises to add more servers
    Show answer

    B. Credible designs acknowledge limits honestly and show they were considered.

    From lesson 13 · Capstone: design review

12. Q12. Why include 'open questions' in the design document?

    1. AIt looks unfinished
    2. BBeing explicit about unresolved decisions, with owners and dates, prevents hidden assumptions and lets the board help resolve them
    3. CReviewers require at least ten
    4. DTo delay approval
    Show answer

    B. Hidden uncertainty surfaces later as incidents; visible uncertainty gets managed.

    From lesson 13 · Capstone: design review