Practice · Anti-Fragility & Organizational Impact

Correct: C. Robust is exactly this: a stressor that leaves capability unchanged, neither harmed nor improved — the flat middle of Taleb's spectrum, not a lesser cousin of antifragile. (A) over-claims: nothing about the service's future tolerance for the next failure changed because of this one event; a real gain requires the found-weakness-fixed-reverified loop, and this stem describes none of that. (B) contradicts the stem's own facts — the redundancy is precisely why the request didn't fail. (D) is a fabrication: Taleb's framework is a strict three-way split; "resilient" is the loose, everyday synonym people reach for in place of robust, not a distinct fourth category.

Correct: B. If every experiment a team runs passes cleanly, that's usually a sign they're only testing what's already known to be safe — not evidence the system is antifragile. (A) commits the exact confusion this module tests: a pass streak with no found-and-fixed weakness anywhere in it has no antifragile signature at all. (C) overclaims with "always" and "definitively" — a clean pass is consistent with robustness at that blast radius, not proof of it, since the same result would come from an experiment too narrow to find anything. (D) lands on the right suspicion (the program may be under-scoped) but the wrong diagnosis — the stem gives no evidence of harm or degradation, only of an inconclusive test.

Correct: B. Hormesis is the precise term, and the pattern most directly mirrors what a mature chaos-engineering program is trying to produce in software. (A) names a real biological concept — but the wrong one: homeostasis is an organism actively working to stay at a fixed, unchanged equilibrium, which is the robust pattern, not the antifragile one. (C) is a real word used elsewhere in this exact module — the mathematical shape (convex) of an antifragile response curve — but it's the geometry, not the name of the biological phenomenon asked for. (D) is a genuine immunology term, but it describes a virus's own mutation over time, not a host organism's adaptive response — planted because it sounds plausible next to "antibody" vocabulary.

Correct: B. Reliability patterns like circuit breakers and retries make a system robust against a known failure mode repeating — valuable and exactly what happened here — but they don't by themselves make anything antifragile, because they protect against the same failure recurring rather than generating new capability against a broader class of failure. (A) is this module's most common trap in a different costume: tolerating a known, specifically-engineered-against fault is the definition of robust, not evidence the system's capability grew from the stress. (C) is false against the stem's own facts — without the added patterns, the outage would have been customer-facing, so the position on the spectrum clearly did shift. (D) states a real general concern applied backwards — the described outcome was a clean, successful trip, the opposite of a new fragility appearing.

Correct: B. "Postmortem theater" is a document with a correct root cause and good intentions that nobody is actually accountable for finishing — the system's real tolerance for that failure class never changes. (A) misdiagnoses the gap: blameless postmortems are explicitly not about naming an individual; the actual defect is missing ownership and a deadline on the fix. (C) mistakes the first half of the loop for the whole thing — finding and documenting a weakness is necessary but not sufficient; the loop only closes once the fix is tracked, shipped, and re-verified, none of which happened. (D) blames the wrong tool — the chaos experiment did exactly its job by surfacing the weakness; the process that failed sits downstream of it.

Correct: B. A hypothesis you can prove wrong, a steady-state you're measuring against, and a deliberately bounded blast radius are the three structural requirements — miss any one and what you have is closer to randomly breaking things and hoping. (A) confuses one specific technique (some mature programs do run unannounced) with a universal requirement; plenty of legitimate, rigorous experiments — especially scheduled game days — are announced on purpose. (C) is a sensible operational precaution many teams follow, but it's a scheduling convenience, not part of the definition. (D) is simply false — a controlled staging experiment is a completely legitimate, lower-risk way to build the same hypothesis-driven discipline before graduating to production.

Correct: B. Because Chaos Monkey terminates instances constantly rather than as a rare, scheduled event, engineers can never write code that merely tolerates termination once and call it done — every latent lifetime assumption keeps getting found and eliminated, which is why the fleet's tolerance for churn climbs rather than plateaus. (A) inverts the mechanism — rarity doesn't make a single recovery more instructive, it just means Service A never gets pressure-tested enough to surface anything beyond the one failure mode redundancy already covers. (C) is too absolute and contradicts the whole point of the comparison — termination absolutely can build antifragility, provided the find-and-fix loop keeps running. (D) ignores the distinction entirely: "eventually recovers" describes Service A's unchanged-over-time pattern just as well as Service B's, which is exactly what the stem is asking you to tell apart.

Correct: B. When a scenario uses "resilient" casually, read it as robust unless it explicitly describes a system that measurably improved because of the stressor — and this stem goes out of its way to say no new capability and no fixed weakness. (A) makes exactly the mistake this module is written to prevent: treating loose everyday usage of "resilient" as though it maps onto Taleb's stronger, precise definition of antifragile. (C) over-reads "unchanged" as a flaw — robust is a legitimate, often perfectly adequate point on the spectrum, not a failure state. (D) is a stalling non-answer — the classification turns entirely on the described outcome, not on implementation detail that wouldn't change it.

Correct: C. A contract a customer won't sign without a formal, defensible reliability commitment is precisely the "competitive and contractual pressure" trigger. (A) would require traffic, headcount, or service count outpacing the org's ability to hire — nothing here describes growth outpacing anything; it's a sales requirement. (B) would require a monolith-to-microservices-style shift multiplying independently failing things — not what's described. (D) requires a specific, already-happened failure as the proximate cause; this stem describes a forward-looking sales requirement, not a post-incident reaction.

Correct: D. The defining fact is the explicit split: a central function owns shared infrastructure and org-wide policy while execution — on-call, runbooks — stays local to each team. That split, done explicitly, is hybrid's signature feature. (A) would require SREs permanently placed inside individual teams reporting to those teams' own managers, not a central org serving forty teams at once. (B) is the tempting near-miss — there genuinely is a central function — but pure centralized would mean the central org owns the whole relationship, including on-call; here, on-call and runbooks are explicitly local, which pushes the answer to hybrid. (C) is ruled out on permanence alone — nothing describes a defined engagement with a start, an end, and a handoff.

Correct: C. A defined engagement with a start, a scope, and an explicit handoff is the consulting model by definition — and its named risk is that success depends entirely on whether billing sustains the practice after the SREs leave, since the SLOs go stale and the runbook rots the moment nobody's watching. (A) correctly names embedded's own risk but misidentifies the model — embedded is permanent placement, not a six-week engagement with a planned exit. (B) correctly names centralized's risk but again misidentifies the model — nothing here describes a standing function serving many teams at once. (D) names hybrid's real risk, but the stem describes a clean handoff with no ambiguity about ownership afterward — that's consulting done correctly, not a muddled hybrid split.

Correct: C. This module names exactly three organizational preconditions for on-call — a real budget line, staffing sized to a sane rotation cadence, and a freeze policy with genuine leadership backing — and a mandatory incident-command certification for every rotation member isn't among them. (A), (B), and (D) are each drawn directly from the module's own list. This is a negative-phrasing item: mark each option true or false against the source material first, rather than trying to hold the inversion in your head.

Correct: B. Blameless culture is a leadership commitment that has to be modeled from the top down, and it breaks instantly, company-wide, the moment it isn't — every engineer now has direct proof that "blameless" doesn't actually apply once the stakes feel high enough to someone senior, whether or not they personally witnessed it. (A) is exactly the claim this module argues against — no document survives a leader's public behavior contradicting it. (C) underestimates how this kind of story travels inside an organization; the precedent exists regardless of who was in the room. (D) makes the same mistake in a narrower form — a well-written document guarantees nothing if the people with power over careers don't honor it when it counts.

Correct: A. Eighty incompatible definitions of "ready," eighty incompatible toolchains, and freeze decisions with no consistent review are exactly the failure modes this module warns appear at scale without deliberate investment in a repeatable onboarding path, paved-road tooling, and a steering group reviewing error-budget policy consistently. (B) is a real SRE mechanism, but it describes individual-team operational load, not this org-wide consistency problem. (C) is also a real "at scale" problem this module names, but it's about promotion criteria and title inflation, not inconsistent tooling or governance. (D) names one adoption model rather than a scale-specific governance gap — nothing in the stem is about a temporary engagement ending.

Correct: C. Consulting's defining traits — a bounded engagement, a capability transfer, a planned exit — map exactly onto Team Topologies' "enabling team," whose whole purpose is to make itself unneeded once the receiving team has absorbed the capability. (A) is the mapping for embedded, where an SRE functions as part of one permanently placed team. (B) is the mapping for centralized/platform, consumed by other teams as an ongoing service. (D) names a real fourth Team Topologies type — a team owning deep, specialized complexity other teams consume through a defined interface — but it isn't one of this module's four SRE adoption models, and it doesn't describe a temporary engagement.

Correct: B. The proximate cause is losing senior engineers specifically over pager burden — precisely the retention trigger, where formalizing SRE's guardrails (an on-call budget, a hard operational-load ceiling) is frequently how a company stops losing its best people to a competitor with a saner pager. (A) would require growth outpacing hiring capacity — nothing here describes growth pressure at all. (C) requires a specific, high-profile failure event; the stem describes accumulated burnout and departures, not one incident. (D) requires a monolith-to-microservices-style change multiplying failure surface — again, not what's described.

Correct: C. Neither contains the other because their scopes genuinely diverge in both directions: ITIL spans territory SRE never touches (supplier management, IT financial management), while SRE brings mechanisms ITIL never mandates (an error budget enforced by automated policy). They overlap substantially in incident, problem, and service-level management, but overlap isn't containment. (A) and (B) both commit the same containment error in opposite directions. (D) is easiest to rule out — a negotiated SLA reviewed quarterly is not functionally identical to a continuously-measured SLO enforced the moment a budget hits zero.

Correct: A. The document-heavy, change-advisory-board-driven criticism describes ITIL v3 (2007, refreshed 2011); ITIL 4's 2019 redesign was a direct, deliberate response to it, absorbing Agile and DevOps thinking. (B) is false and structurally implausible — ITIL 4 still has an Incident Management practice. (C) overstates the convergence — ITIL's Change Enablement still typically routes risky changes through a human Change Advisory Board vote; that's a genuine difference from SRE, not something ITIL 4 adopted. (D) is a fabrication — DORA is stewarded by Google Cloud after Google's 2018 acquisition; ITIL is stewarded by Axelos/PeopleCert, an entirely separate lineage.

Correct: B. A retrospective happens on a schedule regardless of whether anything went wrong, with no formal root-cause requirement; a postmortem happens because a specific event crossed a defined severity threshold and mandates a structured method plus tracked, owned action items — exactly what the stem's own details (no incident, regular cadence, open agenda) describe. (A) and (C) both invent facilitation or participation rules neither process actually requires. (D) overstates postmortems in general — external publication is a mark of unusual organizational maturity, not a universal requirement.

Correct: B. Deployment Frequency and Lead Time for Changes measure speed (throughput); Change Failure Rate and Time to Restore Service measure quality of outcome (stability). (A) simply swaps the two groupings entirely. (C) mixes one metric from each real category into each new group — every metric named is real, but neither grouping is correct. (D) contradicts DORA's headline finding directly: "speed and stability aren't a tradeoff" requires measuring both dimensions independently, which is exactly why there are two metrics of each kind.

Correct: B. DORA's 2021 addition is Reliability, measured in practice through the exact mechanism this course's Module 2 builds — an SLI, an SLO, and the error budget it creates — arrived at independently by a research tradition that started from delivery-performance statistics rather than from Google's own operations practice. (A) invents a metric that isn't part of DORA's published framework. (C) names a real, older reliability concept, but it isn't what DORA actually added. (D) is a fabrication built to sound plausible next to "error budget" — the metric is named Reliability, and it's measured through SRE's mechanism, not invented independently of it.

Correct: B. A service can have a low, healthy Change Failure Rate while still burning its entire error budget on causes CFR was never designed to see, because CFR only counts deploy-attributed failures while an error budget counts every minute of unreliability regardless of cause. (A) is exactly the false assumption this module warns against by name. (C) overcorrects into a different error — the two metrics differ in scope and cause-attribution, not in some fundamental incompatibility that makes comparison meaningless; the whole point is that they can disagree. (D) is a fabrication — DORA's Reliability metric leans on error budgets to be measured at all.

Correct: B. Platform engineering relocates SRE's repetitive setup work rather than eliminating SRE's role entirely — what stays distinctly human, and doesn't template well, is choosing the actual SLO target the business can live with and sustaining the blameless-postmortem culture. (A) names exactly the part of the job the golden path does eliminate, which makes it the wrong answer to a "what's NOT eliminated" question. (C) and (D) both overstate the scenario into a claim it never makes — dashboards and paging remain, just automated rather than hand-built.

Correct: B. A human approval gate is precisely the line between the lower automation rungs and genuine rung-4 autonomy — most real production AIOps for judgment-heavy incident response sits here, while true rung-4 autonomy is reserved almost entirely for low-blast-radius, already-well-understood actions. (A) makes exactly the mistake this module warns readers to watch for: reading a vendor's "autonomous" claim at face value instead of checking what actually executes without a human. (C) undercounts the automation actually present — drafting a proposed rollback is a real automated step, not nothing. (D) is simply false — this module treats the rung distinction as the central, examinable point of the whole AIOps section.

1. Robust is unaffected by a stressor — it stays essentially flat, neither harmed nor improved. Antifragile actively gains capability because of the stressor. A single clean pass only proves the system tolerated that specific fault at that specific blast radius on that specific day; antifragility requires the found-weakness-fixed-reverified loop to run, repeatedly, so the system's demonstrated tolerance for a whole class of failure trends upward over time.
2. Embedded (permanent, inside one team), Centralized/Platform (permanent, serves many teams), Consulting (temporary, hands ownership back), and Hybrid (central function plus local embedded/consulting execution). The fact separating centralized from consulting is permanence: centralized is an ongoing service relationship; consulting has a defined start and end with an explicit handoff.
3. Because the practice depends on engineers believing that reporting a mistake honestly costs them nothing — and that belief is destroyed instantly, company-wide, the first time a leader publicly blames someone by name after an incident, regardless of how well-designed the postmortem template is. Trust has to be demonstrated repeatedly from the top, not just documented.
4. Neither framework contains the other because their scopes only partially overlap: ITIL spans IT-service-management territory SRE never touches (supplier management, IT financial management); SRE brings mechanisms ITIL never mandates (an error budget enforced by automated policy). They share real overlap in incident, problem, and service-level management, but overlap isn't containment.
5. Reliability — whether a team meets its own user-defined operational targets. It's measured in practice through SLOs and observability, which is this course's own SLI/SLO/error-budget mechanism under a different name.