Lab evidence record template
Copy this note into a private training journal after each lab. Do not paste secrets, tokens, access keys, customer names, tenant IDs, subscription IDs, or production URLs. A completed record supports learning and later review; it does not automatically change an audit row to verified.
Lab and source
- Lab and date:
- Training scope and cost owner:
- Source links and checked date:
- Expected outcome:
Workload map
| Concern | Your evidence |
|---|---|
| Owner and business outcome | |
| Runtime, data, and network boundary | |
| Identity, authorization role, and scope | |
| Delivery path and change identifier | |
| Observability signal and success condition | |
| Recovery action and cost/cleanup owner |
Learn → Do → Verify → Break → Fix → Clean up
| Stage | What you did | Observable evidence | What it means |
|---|---|---|---|
| Learn | |||
| Do | |||
| Verify | |||
| Break | |||
| Fix | |||
| Clean up |
Use a scrubbed command, screenshot description, resource state, pipeline run, log query, or error code for each observable-evidence cell. Record the expected and actual result separately. An empty cleanup row means the lab remains incomplete.
Three practice modes
- Configure/design: What would you choose for a similar workload, and why?
- Diagnose: Which signal proved the deliberate failure’s cause, and why did the fix change behavior?
- Distinguish: Which plausible alternative did you reject, and what boundary makes it different?
Re-audit trigger
State the source or product change that would make this procedure unsafe or inaccurate. Recheck the cited official documentation before repeating a lab after a long gap.
Related
workload · Readiness standard · Source-to-Vault Audit · All labs