Challenge · Optional exploration
Follow a fix into running systems
A release succeeds and every health check passes. Decide what the runtime inventory still requires you to investigate.
Think it through with your agent
Give your agent this URL. It contains the scenario and guidance to ask one question at a time. Start with your own prediction or explanation, then check it against the book.
Use with your task. Apply runtime pressure and examine recovery. Keep discoveries in your existing evidence or learning notes.
Follow the argument. Follow a fix through affected deployments.
Read the exercise
Scenario#
Use this invented paper fixture to extend the recovery discussion, keeping findings in the existing pressure-map notes.
Revision r18 fixes a workspace-isolation defect in r17; its acceptance checks pass, and the release job reports success.
Four interchangeable API instances can serve the tracker, and all return 200 from their general health endpoint.
At 14, the runtime inventory is complete for this fixture:
| Instance | Running revision | Receives requests | General health |
|---|---|---|---|
api-1 |
r18 |
Yes | Pass |
api-2 |
r18 |
Yes | Pass |
api-3 |
r17 |
Yes | Pass |
api-4 |
r17 |
Yes | Pass |
Investigate#
- State which claims the acceptance checks, release result, health probes, and runtime inventory each support. Which known instances remain affected, and what does successful traffic leave unresolved?
- Propose a workspace-isolation check that allows an authorized request and denies a cross-workspace request. Bind the result to the actual instance, running artifact, configuration, and observation time; explain why one successful probe through the load balancer cannot clear every instance.
- Name the owner of the remaining rollout and declare a completion criterion. If you propose a temporary mitigation, state how to verify its effect and which repair obligations remain.
- Change one assumption: after the current instances are updated, a replacement starts
r17from an old launch template. What additional configuration and replacement check would keep the vulnerable revision from returning?
Measure time from the confirmed finding to verified remediation and track remaining affected instances alongside patch and release progress. In a real system, an incomplete inventory leaves additional exposure unknown; report the scope and time of the evidence rather than treating a successful release as a system-wide security verdict.
Show worked reasoning
At 14, api-3 and api-4 still serve r17; the successful release and general health checks do not establish that their workspace-isolation defect is fixed.
The fixture's complete inventory supports that specific exposure statement at that time.
Verify the intended authorized and cross-workspace behavior against each actual instance, artifact, and configuration; a request through the load balancer may reach only one of them.
A completion criterion needs verified remediation of the affected serving instances and the configuration that creates replacements.
An old launch template can reintroduce r17 after the current inventory is clear.
A temporary mitigation needs its own effect check and does not remove the remaining repair obligations.
In a real system, incomplete inventory leaves unknown exposure; bind the claim to the coverage and observation time.
This is optional, ungraded exploration. The course brief defines the required work.