Lab Environment Setup Checklist
Set up a practice environment you can safely break — disposable by design, no production credentials, cost caps on anything cloud, and the habits that make a lab teach more per hour.
Markdown. No sign-up, no email.
A lab is somewhere you break things deliberately. That only works if breaking it is free and nothing important is nearby.
Lab: _______________ Date: _______
1. Disposable by design#
- [ ] I can destroy and rebuild this in under ten minutes
- [ ] Rebuild is scripted or documented, not remembered
- [ ] Nothing in it matters if it is lost
- [ ] It is not my main working machine's primary configuration
If rebuilding is painful you will avoid breaking it, and avoiding breaking it removes the entire point of a lab.
2. Isolation#
- [ ] No production credentials anywhere in this environment
- [ ] No access to real customer data
- [ ] Not on the same account or subscription as anything real
- [ ] Network exposure understood — nothing accidentally reachable from the internet
- [ ] If using company resources, I have permission
🔴 The most common lab accident is a credential with more access than intended. Create a throwaway account, scope it narrowly, and delete it afterwards.
3. Cost control — before anything runs#
- [ ] Budget alert set before creating the first resource
- [ ] Spending cap where the provider supports one
- [ ] I know what the most expensive thing here costs per hour
- [ ] Calendar reminder to tear it down
- [ ] Free tier limits understood, including what silently exceeds them
Estimated cost if I forget it for a month: ____
Answer that honestly. Most surprise cloud bills come from a lab someone meant to delete.
4. Version control#
- [ ] Everything is in a repository from the first commit
- [ ] Notes kept alongside the code
- [ ] No secrets committed — checked, not assumed
Six months later the notes are worth more than the code.
5. Working method — where the learning actually happens#
- [ ] I write down what I expect to happen before running it
- [ ] I break it deliberately, not only when it breaks by accident
- [ ] I sit with the broken state and diagnose rather than resetting immediately
- [ ] I record what surprised me — one line per session
The gap between prediction and result is the learning. Without a written prediction there is no gap to notice, and the session becomes following instructions.
Rebuilding makes the symptom go away and takes the explanation with it, which is the part you were there for.
6. Per session#
- [ ] One clear question this session answers
- [ ] Time-boxed
- [ ] Result recorded, including "did not work and I do not know why"
- [ ] Environment torn down or explicitly left running for a reason
Today's question: _______________ What surprised me: _______________
7. Teardown#
- [ ] Resources destroyed
- [ ] Cost checked after teardown, not assumed to be zero
- [ ] Throwaway credentials revoked
- [ ] Notes committed
- [ ] Anything worth keeping moved somewhere permanent
8. Working with others#
- [ ] If pairing: one person predicts, the other runs
- [ ] Discussion of the prediction gap happens before moving on
- [ ] Nobody is reading instructions aloud
Pairing on labs works well and fails in one specific way — one person drives and the other watches. Swap roles at each step.
Verdict#
| Rebuild time | |
| Cost incurred | |
| Question answered | yes / no / partially |
| One thing I would do differently |