Chapter 6 — Containment planning and approvals

Lesson map

Lesson 06 published. Map, example, EX026.

flowchart TD
  N0["Learning outcomes and connection"]
  N1["6.1 A containment objective is narrower than a cause"]
  N2["6.2 New evidence C13–C16 changes the option ranking"]
  N3["6.3 Compare three candidate controls"]
  N4["6.4 Permission, execution and validation are distinc"]
  N5["6.5 A separate failure rehearsal: V6"]
  N6["6.6 Define the containment property rather than the"]
  N7["6.7 A decision comparison that treats availability a"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX026"]

Logical drawing

flowchart LR
  N0["Learning outcomes and connection"]
  N1["6.1 A containment objective is narrower than a cause"]
  N2["6.2 New evidence C13–C16 changes the option ranking"]
  N3["6.3 Compare three candidate controls"]
  N4["6.4 Permission, execution and validation are distinc"]
  N5["6.5 A separate failure rehearsal: V6"]
  N6["6.6 Define the containment property rather than the"]
  N7["6.7 A decision comparison that treats availability a"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX026"]

[Learning outcomes and connection]
    |
    v
[6.1 A containment objective is narrower than a cause]
    |
    v
[6.2 New evidence C13–C16 changes the option ranking]
    |
    v
[6.3 Compare three candidate controls]
    |
    v
[6.4 Permission, execution and validation are distinc]
    |
    v
[6.5 A separate failure rehearsal: V6]
    |
    v
[6.6 Define the containment property rather than the]
    |
    v
[6.7 A decision comparison that treats availability a]
    |
    v
[Worked example] --> [Exercise EX026]

Learning outcomes and connection

The learner can compare containment options against service harm, evidence strength and rollback; draft an action-specific approval; and distinguish a reported control change from measured effect. Chapter 5 left an S42 edit, a disputed approval and an account-to-request join unresolved. A professional responder must use the new facts below to narrow the decision without treating containment as a diagnosis. The supervised artifact is an action record that could be reviewed by the service owner before any real change.

6.1 A containment objective is narrower than a cause claim

Containment seeks to limit further harm while investigation continues. It does not require final attribution, but it does require a named harm path and a proportionate control. At 09:26, disabling the shared svc-enroll account would affect a scheduled enrollment job and perhaps other services. Revoking s-77 might be narrow, yet no record directly joins that session to q-144. A temporary hold on writes to one slot might preserve the rest of enrollment, but only if the application owner knows which write routes the hold covers. These are options, not permissions. NIST SP 800-61 Rev. 3 frames response choices within organizational risk management; CTN's control menu and approval form are fictional teaching tools.

Separate four questions before selecting a control: What harm do we want to prevent? What evidence makes that harm plausible now? What legitimate service will the control interrupt? What observation would tell us that the control worked or should be rolled back? A vague “block the attacker” answers none of them. In this case, the immediate harm is another unauthorized or mistaken edit to S42, not an established human adversary. A control aimed at that harm can be justified even while the user of the shared account remains unknown.

6.2 New evidence C13–C16 changes the option ranking

The following are invented CTN records. They are released after the 09:26 Chapter 5 handoff; they cannot retroactively justify an earlier decision.

Lesson table; scroll horizontally to read all columns →

C13 is stronger than C10 on stored state, because its custodian queried the owner-designated authoritative record. Yet it is still a point-in-time read; it does not count all affected learners or explain why C02's approximate 09:00 observation precedes C05's 09:01 edit. C14 weakens the specific “approved batch-17 made q-144” interpretation. It does not prove intentional misuse. C15 resolves the visible approval question for the official ledger through 09:33, but a missing approval record is not a person or a motive. Write those refinements in a new hypothesis version rather than overwriting Chapter 5's 09:26 view.

6.3 Compare three candidate controls

The analyst and service owner compare options at 09:35, before C17 or later cards exist:

Lesson table; scroll horizontally to read all columns →

The S42 hold is a defensible proposal because C13 confirms a bad current state and the service owner has described tolerable interruption. It remains conditional on exact approval and coverage review. A different local architecture could change the choice: if S42 writes bypass the application guard, the proposed hold may not achieve its objective. The option record must name that uncertainty and a stop rule. “Most narrow” does not automatically mean “effective.”

6.4 Permission, execution and validation are distinct records

At 09:37, card C17 records an explicit fictional case approval: the incident lead coordinates and the service owner authorizes the application operator to enable a S42-only write hold, with an automatic expiry at 09:47, a named rollback owner, monitoring of accepted and denied S42 writes, preservation of relevant audit records, and escalation if an alternate route accepts S42 writes. The approved action does not include disabling svc-enroll or changing other slots. This is a classroom case fact, not authority in a real environment.

At 09:39, C18 is the operator's execution receipt: configuration change g-22 is reported enabled for S42. It records operator role, target, approved change reference, start and rollback owner. The receipt does not prove that the guard covers every path. At 09:42, C19 is a read-only audit review: an attempted S42 write labelled q-147 was denied through one observed application route; an S40 write q-148 was accepted. No learner initiated these writes. This supports a narrower statement: the guard appears active for the observed S42 route while S40 remains available. It does not prove that direct database access or an alternate API route is blocked, nor that the source of q-147 was malicious.

Lesson table; scroll horizontally to read all columns →

The status field should never jump from approved to effective without an execution receipt and relevant observation. A written rollback should say what would trigger it: expiry at 09:47, a legitimate enrollment failure outside the approved tolerance, or evidence that the hold is ineffective and must be re-planned. The operator would document the actual rollback and a post-rollback service check. The book does not provide commands to modify a tenant or application; the learner's work is a decision record, using only these synthetic cards.

6.5 A separate failure rehearsal: V6

Variant V6 is an isolated training tenant, not a CTN production observation. A simulated S42 guard denies a browser-form write but accepts a direct API write; an S40 control succeeds. A learner should report partial route coverage and fail the claimed all-route containment criterion. The correct next step is an application-owner design review of write paths and a bounded retest after an approved change. It would be incorrect to cite V6 as proof that CTN's C17 guard was bypassed; C19 supplies only the main case's one observed route. This variant teaches how a control can look successful in a dashboard yet fail at the boundary the decision actually depended on.

6.6 Define the containment property rather than the device setting

A device or application configuration is an implementation; a containment property is a falsifiable statement about behavior. “Enable guard g-22” is a prospective change request. “No unapproved S42 write is accepted through any in-scope route while the hold is active, and approved S40/S41 operations remain available” is a property that can be tested. The distinction matters when several paths reach the same state store. A front-end form may enforce a rule while a direct API, job worker or internal maintenance path uses a different authorization boundary. CTN does not provide evidence that any such alternate route was used during its real case; those routes are questions for the owner, not findings.

Write the control requirement as a five-part tuple: asset and operation; initiating conditions; intended denial or permission; observation source; exception and expiry rule. For CTN the asset is the S42 enrollment-state write, not the whole tenant or all actions by svc-enroll. The initiating condition is the owner-authorized temporary hold during investigation. The expected denial is an attempted in-scope S42 mutation that does not commit, while S40 remains available. An audit record must include a recognizable route and request identifier. The exception is not “security team may do anything”; it is a separately approved maintenance action with its own record, or an escalation if the hold harms legitimate enrollment. The expiry is an explicit boundary, not merely a reminder.

This property exposes an important ambiguity. A dashboard's “guard enabled” describes configuration state, whereas “request denied” describes one observed transaction. Neither alone establishes that the system enforces the guard uniformly. A verifier must ask whether the routing table, application handler, job path, background repair interface and state-store writes share the same enforcement boundary. If the owner cannot enumerate the routes, the verifier records “coverage unknown” and names who can resolve it. Do not fill the gap with confidence language.

The widely applicable principle is to make response actions proportionate to known risk and explicitly governed; NIST SP 800-61 Revision 3 integrates incident response with organizational cyber-risk management. The tuple and CTN guard are original course methods, not NIST-mandated fields.

6.7 A decision comparison that treats availability as evidence

The initial decision is not “which intervention is strongest?” but “which supported intervention reduces a sufficiently likely harm path without causing an unaccepted business loss?” Compare the proposed session restriction, bounded S42 write hold and account-wide disablement using the same denominator: an additional unauthorized or mistaken S42 edit during the evaluation window.

Restricting s-77 is potentially cheap because it appears session-specific, yet C03's session and C05's q-144 have no verified join. If the session belongs to a healthy component, an otherwise sound session action could have zero incident benefit and nonzero availability cost. A successful IdP revocation would verify the session state, not that the S42 write path had been stopped. For account-wide disablement, the expected interruption of the legitimate approved batch-17 path is a first-class outcome, not an inconvenient side note. That action has more dependencies, a larger rollback plan and a higher approval threshold. It may become warranted if evidence later shows a broad active credential risk, but C13–C16 alone do not establish that condition.

A ten-minute S42 hold is narrower in blast radius, but narrowness and coverage are separate dimensions. It might still be wrong if most mutations come from an unguarded job route or the hold blocks a time-critical legitimate enrollment operation. Therefore the candidate must specify two independent acceptance axes: security effect (no accepted in-scope S42 writes on tested routes) and business preservation (S40/S41 function; owner-recorded S42 delay stays within tolerance). One axis cannot compensate numerically for a failure on the other when either is mandatory.

A useful decision sheet lists for each option: the suspected harm path; source cards and confidence; the least privilege target; affected services and named dependency owner; expected duration; rollback actuator and decision owner; minimally invasive test; test blind spots; collection/retention consequences; and the exact stop condition. Where a field is unknown, retain “unknown” and assign the question. Recording the unknown is more informative than a falsely complete risk score.

6.8 Authority is an event with a scope, not a job title

Organizational roles establish who can request, approve, operate and independently check a change; they do not merge those actions. In CTN the analyst prepares the case-bound recommendation. The service owner accepts a business availability tradeoff, the incident lead coordinates a time-limited response, the application operator performs the approved configuration change, and another authorized observer inspects the resulting records. This separation is a design choice of the case. A real organization must map it to its actual delegated-authority matrix and emergency procedure.

An approval event should be reconstructable as a small contract: case ID, target, action, allowed routes, forbidden collateral actions, approver and capacity, effective window, operator, rollback owner, evidence-preservation duties and escalation. The phrase “approve containment” is insufficient because it could be misread to authorize a session purge, a shared-account disablement or a database rewrite. For C17 the authorized object is only the S42 write hold through 09:47. There is no authority to disable svc-enroll, alter S40/S41 or make a final actor attribution. C16 only says the initial interruption might be tolerable; its evidentiary role is an impact assessment, not a signature.

An operator's receipt should bind the approval to the actual configuration version, reported start time, outcome and error condition. C18 reports g-22 enabled at 09:39. That receipt deserves preservation but is not independently sufficient to claim enforcement. C19 at 09:42 observes q-147 denied on one S42 application route while q-148 for S40 succeeds. This supports observed route behavior at that timestamp, not global coverage. A supervisor asking “Was containment successful?” should receive the calibrated answer: the approved hold was reported enabled and one route showed the intended selective denial; other routes are unverified.

Avoid collapsing these records into a single green checkbox. Each transition has a different evidence producer and a different possible failure: approver identity or scope could be missing; a change could be approved but not deployed; it could be deployed to the wrong environment; it could take effect on one path and fail elsewhere; or it could remain after expiry. A practical record carries status and source separately so the next shift can investigate each link.

6.9 Chronology as a permission-and-observation ledger

Use immutable checkpoints for a reproducible incident narrative:

Lesson table; scroll horizontally to read all columns →

A later chapter adds C20 and a new C21 extension approval at 09:46:30, followed by a 09:46:45 operator receipt. That development must not be added to the 09:42 knowledge column. A past decision is evaluated against evidence and authority available then, not against a tidy retrospective account. If a review finds a decision imperfect, preserve the original and append a correction with its timestamp.

The expiry needs active ownership. A time-based rollback may create a new exposure window, but quietly overriding the expiry is itself unauthorized scope expansion. Before expiry, the service owner should be asked whether the observed benefit and legitimate cost justify a new approval; if no decision arrives, follow the actual fail-safe/default procedure recorded in the authorization, not the analyst's assumption. C17 states an automatic expiry. Chapter 7's C21 later documents renewal; no reader may silently substitute that fact at the Chapter 6 decision point.

6.10 Two worked arguments: a defensible recommendation and a seductive mistake

Defensible 09:35 note: “The owner-approved C13 view shows S42 unavailable and associates the stored state with q-144, while C14's complete approved-run manifest lacks that request. The person or process behind q-144 remains unresolved. To reduce the chance of another S42 change while the source question is investigated, request a ten-minute S42-only hold, conditional on explicit service-owner and incident-lead approval. Ask the application owner which write routes it covers. Appoint an operator and rollback owner, preserve audit records, test one S42 denial and a legitimate S40 acceptance through approved observations, and label any untested route unverified. Do not disable svc-enroll based only on these cards.”

Incorrect note: “C14 proves an attacker used svc-enroll. C16 approved emergency containment, so disable the account until the forensic investigation finishes and record the issue resolved when the portal shows S42 unavailable.” It turns a missing request in one manifest into human attribution, misclassifies tolerability as authorization, expands the intervention to a shared dependency, and uses a user-facing symptom as proof of prevention. Worse, a portal that still displays unavailable might simply be showing the very business harm the team wants to repair. The correct revision states the narrow harm, proposes an action, names its decision owner and insists on a bounded verification claim.

When discussing alternatives, explain why rejected as well as why chosen. A session-only action is rejected for insufficient session/request linkage, not because sessions never matter. Account disablement is deferred because the expected business cost is broader than supported harm, not because it could never be legitimate. The S42 hold is provisional because its enforcement surface and operating cost must be tested.

6.11 Offline laboratory: state-machine and route-coverage separation

Objective. Demonstrate that authorization, reported execution and observed effect cannot be inferred from one another. Inputs. Four synthetic tuples reflecting C16–C19 and a separately labeled V6 route fixture. Environment. Python 3 standard library only, disconnected from networks; no login, file write or command against a tenant. Success condition. Reproduce the exact lines below; explain why all-route coverage remains unknown in CTN even though V6 fails a route test.

checkpoints = [
    ("09:35", False, False, ()),
    ("09:37", True, False, ()),
    ("09:39", True, True, ()),
    ("09:42", True, True, ("application",)),
]
for clock, approved, reported, observed in checkpoints:
    state = (
        "proposal" if not approved else
        "authorized" if not reported else
        "reported-enabled" if not observed else
        "observed-one-route"
    )
    all_routes = "verified" if len(observed) == 3 else "unknown"
    print(f"C6 {clock} {state}; all-routes={all_routes}")

# V6 is an isolated training variant, never a CTN incident card.
v6 = {"browser": False, "api": True, "S40": True}
verdict = "PASS" if (
    not (v6["browser"] or v6["api"]) and v6["S40"]
) else "FAIL"
print("C6 V6 all-route=", verdict)

Executed result (Python 3, in-memory fixture):

C6 09:35 proposal; all-routes=unknown
C6 09:37 authorized; all-routes=unknown
C6 09:39 reported-enabled; all-routes=unknown
C6 09:42 observed-one-route; all-routes=unknown
C6 V6 all-route= FAIL

The boolean False for a V6 write means denied, and True means accepted; the API's accepted S42 write fails V6's all-route denial criterion. The CTN state-machine deliberately has no all-route evidence. Its arbitrary three-route threshold is a teaching placeholder, not a known CTN route count or a real coverage estimator. A reviewer should reject the program if it is used to turn a fixture assumption into operational assurance. To extend safely, introduce a local fictional inventory with three named routes and require one independently sourced result per route; do not generate writes to a real service.

6.12 Supervised control selection as a constrained decision

A containment objective describes the prohibited change the team wants to prevent; an implementation is the particular guard, session action or account setting selected to pursue that objective. Those are not interchangeable. At 09:35, C13 supplies a service-owner-approved read of S42 as unavailable at version 19, and C14 excludes q-144 from one complete approved batch-17 manifest. Neither identifies the actor. C16 says an initial ten-minute S42 hold would be tolerable; it does not authorize a deployment. A defensible proposal therefore names one S42 write boundary, the initial impact tolerance, route-coverage unknowns, the approving roles and an independently observable stopping rule. It must not use C17's later approval to justify the proposal retrospectively.

A supervised responder should compare three counterfactual outcomes before requesting a disruptive control: no further S42 changes but normal S40/S41 work remains possible; an alternate S42 route bypasses the hold; and legitimate S40/S41 writes fail because the control was applied too broadly. The first is a bounded success only for observed routes and window. The second is a protection failure. The third is an unacceptable business failure even if the suspicious operation was blocked. A control can therefore fail along two independent axes. Treating a dashboard's "enabled" signal as sufficient evidence of all-route behavior conceals both.

There is also a fourth failure mode: the approved target and the actual target differ. If an operator is authorized to guard the S42 application route but the platform only permits account-wide disabling, the operator must hold the change and return it to the service owner and applicable change authority. The fact that the broader command is technically available is not permission to use it. This supports the organizational coordination emphasis in NIST SP 800-61 Rev. 3; the CTN tuples and acceptance conditions are original teaching devices.

6.13 Effective time, expiry and renewal are three separate receipts

C17 at 09:37 authorizes a hold expiring at 09:47. C18 at 09:39 reports g-22 enabled. Those timestamps do not describe the same event. If the hold genuinely became effective at 09:39 and expired as authorized at 09:47, the potential effective duration would be eight minutes, not ten. Even eight minutes is a calculated bound, not proof that every route was blocked throughout. C19's observations at 09:42 cover only one named application route and the S40 control. The correct operational record has fields for approval window, actual activation, verified protective observations, review trigger, actual expiration/reversal and separately tested legitimate service.

The later C21 renewal is released in Chapter 7. Its 09:46:30 decision and 09:46:45 operator receipt must not appear in the Chapter 6 approval record as knowledge available at 09:42. This distinction protects both instruction and operational audit: a future rescue of a decision cannot create a historical authorization that did not exist.

An expiry trigger can be implemented by a timer, an operator or a workflow; none is safe by naming the time alone. The observer should ask whether the control actually reverted, whether the original harmful route reopened, whether pending authorized S42 work needs reconciliation and whether the alternate routes were ever covered. If evidence is missing, say effect unverified and obtain a new owner-governed decision. Never convert an expiry rule into permission to prolong a block indefinitely or to resume unsafe writes automatically.

6.14 Two contrasted decision examples

Defensible worked example, C13–C19: At 09:35, the analyst documents C13's S42 state, C14's bounded exclusion of q-144 from batch-17 and C16's limited tolerance. The analyst proposes an S42-only temporary hold with a route inventory question, source-preservation request, S40/S41 service test and a fixed review. At 09:37 the distinct C17 decision authorizes that scope and expiry; at 09:39 C18 reports deployment; at 09:42 C19 supports one observed S42 denial and one observed legitimate S40 acceptance. The handoff says "reported enabled, selectively observed, other routes unverified." Its remaining tasks are an owner-led route/impact review and the impending expiry decision. It neither concludes that q-144 was malicious nor claims the cause was removed.

Seductive but incorrect example: "The owner tolerated the hold at 09:35; therefore we disabled svc-enroll immediately, confirmed all paths blocked by the 09:42 dashboard and can extend the shutdown until attribution is finished." This statement backdates approval, broadens S42 scope to a shared account, invents an operation, turns one route into all routes and makes the extension indefinite. It would also obscure the fact that S40 success is part of the service-side acceptance condition. The corrected version must treat each action as a separate request, approval, operator report and route-specific observation.

When the test cannot safely be run: A practitioner must not create unauthorized writes on a live enrollment platform merely to see whether the guard works. An application owner can design a known synthetic rehearsal in an isolated environment using explicitly permitted accounts and inert slot records. The case's C19 observations are already supplied; the learner can analyze them without issuing traffic.

6.15 Offline laboratory C6X — permission versus tested route coverage

Scope: This is a separate, entirely synthetic Python 3 standard-library exercise. No CTN source is queried or changed. The fixture labels reuse times of known C16–C19 decision checkpoints but the optional API-route rows are counterfactual, not canonical case facts. The purpose is to reject a falsely global protection verdict even when an operator reports success.

from datetime import datetime

def time6(s):
    return datetime.strptime(s, "%H:%M")

def assess6(approved, applied, routes, legitimate):
    if approved is None:
        return "PROPOSED_ONLY"
    if applied is None:
        return "APPROVED_NOT_APPLIED"
    if time6(applied) < time6(approved):
        return "INVALID_TIME_ORDER"
    if not {"form", "api"}.issubset(routes):
        return "COVERAGE_UNKNOWN"
    if any(routes[k] != "deny" for k in ("form", "api")):
        return "PROTECTION_FAIL"
    if legitimate != "accept":
        return "BUSINESS_FAIL"
    return "BOUNDED_TEST_PASS"

cases6 = [
    ("C16", None, None, {}, None),
    ("C17", "09:37", None, {}, None),
    ("C18", "09:37", "09:39", {}, None),
    ("C19", "09:37", "09:39", {"form": "deny"}, "accept"),
    ("BYPASS", "09:37", "09:39", {"form": "deny", "api": "accept"}, "accept"),
    ("SERVICE_DOWN", "09:37", "09:39", {"form": "deny", "api": "deny"}, "reject"),
    ("LAB_PASS", "09:37", "09:39", {"form": "deny", "api": "deny"}, "accept"),
]
for name, *values in cases6:
    print(name + ": " + assess6(*values))

Exact observed output in an isolated Python 3 run:

C16: PROPOSED_ONLY
C17: APPROVED_NOT_APPLIED
C18: COVERAGE_UNKNOWN
C19: COVERAGE_UNKNOWN
BYPASS: PROTECTION_FAIL
SERVICE_DOWN: BUSINESS_FAIL
LAB_PASS: BOUNDED_TEST_PASS

For the adversarial BYPASS control, a form route denies an S42 write but a distinct API route accepts one; the broad containment objective fails. SERVICE_DOWN denies both tested writes but rejects the legitimate S40 operation, so the business gate fails independently. LAB_PASS is only a consistency verdict on invented observations, not real application approval or all-path production coverage; two routes were selected by the exercise author, not discovered through CTN source evidence. The canonical C19 cannot inherit any of these API outcomes.

Deliverable and scoring: Submit seven exact states, a four-column approval/execution/protection/service ledger, the C17/C18 time comparison, a supervisor-controlled alternative if a route is unverified, and a specific expiry/rollback check. Award one point for each of three lifecycle distinctions, two for identifying the separate BYPASS and SERVICE_DOWN failures, one for the expiry bound, and one for refusing a CTN-wide claim from LAB_PASS (7 points). A fabricated operator event or an action outside the approved S42 scope is a critical error regardless of score.

6.16 Operational synthesis and handoff to eradication

A professionally useful handoff at 09:42 includes the current S42 effect scope; the C17 approval identifier/time/expiry; C18 operator report; C19's one-route observations and remaining route unknowns; which source evidence is preserved or only requested; service cost and rollback owner; and a time- or event-triggered next review. It does not name an attacker. Chapter 7 introduces a different type of evidence—the job/task mechanism—which can strengthen a cause-specific correction without rewriting this earlier containment record.

A second responder should be able to check each item without access to the original conversation.

Common errors and limits

• Converting C16's tolerance into C17's approval. They are separate cards, two minutes apart, with different meanings.
• Treating C18's configuration receipt as proof of effective containment. C19 tests one observed path; the rest are unverified.
• Saying C14 proves a hostile operator. It rules out q-144 from one approved run, not all mechanisms or identities.
• Letting the 09:47 expiry become a forgotten permanent restriction. Put expiry, rollback owner and a reminder in the decision record.
• Reusing V6's isolated failure as a main-case finding. Label simulation variants prominently.

Practice: supervised control review

Give one learner C13–C16 and ask for a two-option comparison. A second learner acts as service owner and must either reject, amend or explicitly approve a scoped action. Only then release C17–C19 and have a third learner score what was actually validated. The recorder versions the action record at 09:35, 09:37, 09:39 and 09:42. The exercise requires no access to a real system.

Exercises — subject 6

EX026 — Updated impact statement. Inputs: C05, C10, C13–C15. Produce a four-row ledger of stored state, displayed symptom, approval scope and actor attribution, with source IDs and one unresolved question each. A 2-point answer distinguishes C13's authoritative S42 state from C10's screenshot and does not name an actor.

EX027 — Containment comparison. Inputs: C13–C16 and the three options above. Produce benefit, business cost, permission gate, verification and rollback for each; select a proposal at 09:35. A 2-point answer names one reason the narrow option could still fail and does not treat C16 as approval.

EX028 — Approval-to-effect record. Inputs: C17–C19. Make four timestamped status lines: proposal, approval, execution and observed result. Include the 09:47 expiry and state which write path remains unverified. A 2-point answer does not call the whole account disabled or all routes blocked.

EX029 — Conditional rollback. Inputs: C17–C19. Write a rollback decision card with owner, three triggers, required service and audit checks, and a record of what must remain preserved. A 2-point answer leaves any actual rollback unperformed until a triggering observation and authorized operation occur.

EX030 — V6 coverage review. Input: the isolated V6 browser/API/S40 outcomes. Write a two-sentence containment verdict, a bounded design question for the application owner and a retest criterion. A 2-point answer says the all-route criterion fails in V6 without importing that result into CTN's C19. Compare the isolated V6 verdict with the CTN state-machine output in §6.11; distinguish one-route observation from all-route assurance.

Subject synthesis

Containment is a controlled attempt to limit further harm. C17 authorizes only the S42 hold; C18 reports execution; C19 provides limited validation. Chapter 7 examines the likely change path and a second configuration concern, while retaining the still-unverified human attribution and the expiry of the temporary hold.