#### Day 32 — Preserve and plan two independent eradication contracts **Learning task.** Build separate task and identity workstreams at **09:54**, with permission, preservation, checks and pending fields. First account for the intervening authority event: C21 at 09:46:30 is fresh service-owner/incident-lead approval to extend the **S42-only hold to 10:07**, followed by the application operator's 09:46:45 `g-23` receipt. It continues the limited scope, monitoring and rollback ownership and sets a 10:06 review. It is not task-removal authority or an automatic consequence of C20. The longer business interruption has its own impact decision; C16's initial tolerance does not supply it. Next release C22 at 09:50: a separately retained configuration-audit source reports a recovery-method addition to `svc-enroll` at 08:52, with a blank actor. This is not recovered C08 sign-in detail and carries no inference that all identity evidence shares C08's 10:00 retention limit. An added method may provide a continuing access path, but its active/functioning state is untested. At 09:54 C23 records owner comparisons against the approved task inventory and official change ledger: neither change is approved through that checkpoint. This supports **unapproved configuration change**, not malware, theft, a named actor or a shared author of both changes. **Mechanism of the contract.** Map each observed concern to a prospective intervention and a test that can contradict it. Baseline preservation must precede destructive modification where the authorized procedure permits it. Preserve the minimum task definition/schedule and bounded run evidence, inventory version, request semantics and source pointers; preserve the identity configuration history and method identifier without publishing secrets. A collection receipt should identify the acquired object, custodian, time, scope and integrity/provenance checks actually performed. A later change receipt must identify what was altered. “Saved and fixed” merges two different evidentiary obligations and hides ordering. | Contract field at 09:54 | Scheduler task | Identity recovery method | |---|---|---| | Supported concern | C20 mechanism plus C23 task-inventory comparison. | C22 configuration addition plus C23 approval comparison; functionality untested. | | Proposed action | Preserve configuration/run baseline; seek approval to disable only `sync-override`. | Preserve bounded audit/settings; identity owner assesses active state and seeks scoped method/session/credential decisions. | | Authority and operation | Task/application/service decision with incident coordination; authorized application operator, rollback plan. | Identity and service owners determine permitted targets, operator and dependency-aware reversal. | | Intended effect check | Disabled status and no invocation at a known next scheduled opportunity. | Specific method absent/inactive after approved action; separately scoped session/credential effect where authorized. | | Legitimate-service control | Approved `batch-17` S40/S41 path remains functional. | Approved integration still authenticates/operates after any change. | | Reopen and gap | Re-registration, unexpected run/write; unseen runners and author remain unknown. | Unexpected method/access or broken integration; other methods/sessions and actor remain unresolved. | **Worked contrast.** A correct 09:54 worksheet marks both eradication changes **proposed**. It can separately mark the S42 hold extension authorized/reported from C21. A single green “persistence removed” box would invent execution in both tracks. Disabling the whole account to make both rows appear quiet exceeds the narrow proposals, risks approved jobs and prevents distinguishing the task fix from an availability failure. A broader control might later be justified, but it needs a separate decision and evidence. **Offline practice.** Complete both rows without importing a later result. For each, write the source package, approving capacity, expected operator receipt, effect check, legitimate-service check and an unavailable-result branch. A missing preservation digest remains missing; planned collection does not create a receipt. If immediate harm conflicts with lengthy collection, refer a bounded preservation/action sequence and stop condition to the owners rather than delaying indefinitely or granting yourself access. No recovery secret, live command or test traffic belongs in this exercise. **Limits and decision.** Submit [EX032](#exercise-ex032), then inspect its [worked answer](#answer-ex032). Task evidence does not prove the identity concern fixed, and method absence would not prove every session invalid. Preserve those two independent completion gates for the later task-only decision. [Previous: Day 31](#week-07-day-01) · [Week 7 index](#week-07-index) · [Course index](../SUBJECTS.md) · [Next: Day 33](#week-07-day-03). ### Exercise for this lesson **EX032 — Two-path eradication contract.** Objective: plan distinct task and recovery-method changes with preservation before modification. Inputs: C20–C23 through 09:54 and Day 32. Produce separate rows for source/baseline, proposed target/action, approving capacity, operator/rollback, effect and legitimate-service checks, expected observation opportunity, monitoring and reopen trigger. Distinguish C21's already approved/reported hold extension from both pending eradication operations; do not claim method functionality, removal or secret collection. Rubric: 0 = invented remediation or shared actor; 1 = two paths with missing authority, preservation or verification fields; 2 = usable independent contracts with honest pending results and source-specific limits. [Worked answer](#answer-ex032). ## Worked answers **EX032 — Model two-path contract.** Task row: baseline = approved inventory and preserved C20 task/run copy; proposed change = disable `sync-override` only; authority = application/service owners with incident-lead coordination; positive test = scheduler status disabled and no run at next expected interval; negative test = approved `batch-17` S40/S41 path still works; monitor for re-registration or new S42 requests; reopen if either occurs. Recovery-method row: baseline = bounded C22 configuration audit and owner-approved settings; proposed change = remove unapproved method, address credentials/sessions under identity/service-owner approval; positive test = method absent and scoped old session inactive; negative test = approved integration works after change; monitor for new recovery methods; reopen on an unexpected addition. At 09:54 all changes are **proposed**, not executed. Preserve source records before altering them. **Additional professional worked reasoning:** Task workstream: preserve task and run, obtain a targeted owner decision, observe disabled state at execution and a later expected scheduled opportunity, and verify approved batch-17 S40/S41 still works. Identity workstream: preserve C22 configuration-audit evidence and request a separately authorized method/session/credential decision plus positive removal and negative legitimate-authentication tests. At 09:54 both are plans, not performed remediation. **Week 7 Day 32 — worked pending contracts.** C21 separately authorizes/reports only the S42 hold extension to 10:07. At 09:54 the scheduler row proposes preserving configuration/schedule, bounded run source and inventory/version, then a targeted task-disable decision, operator/rollback receipt, disabled status, known scheduled-opportunity observation and legitimate batch-17 check. The identity row proposes preserving C22's separate configuration audit/settings without a secret, determining active state, then owner-approved method/session/credential changes with scoped effect and legitimate integration tests. Neither eradication operation is yet executed. C22's blank actor is unknown, not hostile anonymity, and its retained configuration source is not C08 sign-in reconstruction. C23's unapproved classification applies to both changes but does not establish shared author or intent. Unknown source integrity, functionality, observation opportunity and results stay pending.