Can you show what an assumed-compromised workload can do, remove an unwanted operation, and verify that required service still works?
I built and tested this lab to provide examples you can recreate and adapt. It accompanies Azure Reachability Assurance Lab, planned for February 16-March 4, 2027, and is available independently so you can inspect the code first.
Download and start offline
Download toolkit 0.1.1-preview and its SHA-256 checksum.
Extract the ZIP and read README.md. Python 3.10+ and its standard library are enough for the offline exercise; no Azure account or dependencies are needed. The deliberately incorrect fictional comparison should fail validation. Explain why, inspect the corrected example, then use the worksheet to define required and prohibited operations for your own environment.
The package includes Bicep, a guarded runner, fixed-target probe, evidence validator, query, runbook, approval checklist, worksheet, tests and sanitized lab findings. Filled approvals, raw operational logs and keys are excluded.
Inspect the artifacts
- Lab guide
- Runbook
- Permissions, pricing and approval checklist
- Adaptation worksheet
- Measured lab findings and negative results
- Detailed verification record
- Known limitations
What the lab established
The isolated experiment compared required, spare-container and separate-canary marker reads. Identity-only controls denied the spare and canary reads. Network-only controls left the spare read working but the canary timed out. Combined controls preserved required access. Narrow recovery restored only the required grant while the unwanted operations remained unavailable.
An initial required read still succeeded shortly after role removal; one recorded readiness retry later observed denial. That is not immediate revocation or a measured revocation SLA. The first deployment also exposed a Run Command response-format bug, corrected before a fresh source-bound run. Both groups were deleted, with final absence confirmed.
These are finite observations, not tenant-wide containment proof. A timeout alone does not establish cause. The lab permits broad AzureCloud HTTPS management egress through NAT; it is not zero-egress. DNS faults, existing sessions and hostile control-plane administrators were not tested.
Preview status and safe adaptation
This is an author-approved limited preview, not an independently reproduced assurance pack. Independent reader replay and settled-cost review are still outstanding. Billing initially had no rows and later throttled; no zero-cost claim is made. Local extracted-package tests do not substitute for another operator’s replay.
Use only a disposable environment you own or are explicitly authorized to operate. Obtain current region/SKU, quota, policy, permissions and pricing checks, a numeric spend cap, and a cleanup owner before any cloud action. Read the approval checklist; the example approval is not permission to deploy.
Adapt the evidence model to your business operations first on paper. Do not repoint the runner to production or arbitrary hosts. A tested sample is a starting point for your own review, not a production remediation script or certification.