# Lab Environment Setup Checklist

> 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 | |