Don't just build it.
Be able to explain it.
Turn the lab into a clear architecture record: what runs, who can reach it, what costs money, and what you proved when something failed.
These are sample names, not our infrastructure. Before copying commands, read Customize the examples: paths, keys, IPs and names. Substitute your own authorized account and resources. Existing lab? Retain its original resource names, usernames and state; renamed samples can cause replacement. See the existing-lab warning before applying updated recipes.
A worksheet, not another cloud service
Download the Markdown template and fill it in locally using any text editor. It creates no cloud resources and sends no answers to Guidewell Cloud. Use an invented project label in a public copy; keep account IDs, names, addresses, credentials and raw logs private.
A photo of your toy tells us what it looks like. This record tells us how the pieces fit, what each piece does, and how you would fix it if it breaks.
A worked example: the container lab
| Decision | Example answer | Reason |
|---|---|---|
| Scope | One short-lived Ubuntu VM already created in one cloud | Learn containers without a new orchestration platform |
| Access | Laptop loopback 8082, verified SSH 22, server loopback 8081, container 8080 | No new public application port |
| App identity | Non-root container UID 10001; no cloud workload permissions | Static demo does not call cloud APIs |
| Data | Public HTML bind-mounted read-only; no customer records | Separate content changes from image upgrades |
| Image | Reviewed Python image digest recorded in .env | Explicit version selection; not proof of vulnerability freedom |
| Recovery | Restore the lab HTML and compare hashes; restore previous image reference separately | File recovery and image rollback solve different problems |
| Costs | VM runtime, disk, public IP where billed, downloads/traffic | Compose limits/down do not stop cloud charges |
| Limit | One VM; demo HTTP server; no public HTTPS or real data backup | Honest boundaries matter more than a production label |
This is an example answer, not evidence that your deployment succeeded. Replace it with observations from your own authorized lab.
Evidence beats “it should work”
- Configuration: retain a reviewed, secret-free recipe and record the selected image reference.
- Access: verify the intended path and lack of unintended public bindings. Do not rely only on a screenshot of an allow rule.
- Health: record application response and the difference between VM state and container/service health.
- Recovery: record what changed, what was restored, the expected result and matching checksums where applicable.
- Removal: record the exact resources removed and which retained objects still require a decision.
Write timestamps and observed outcomes in your private record. In a public portfolio, summarize results and redact screenshots. Do not invent test results, uptime claims, exact savings or production readiness.
A useful runbook fits a real failure
Scope: my dedicated disposable VM only
Symptom: laptop curl to 127.0.0.1:8082 fails
1. Confirm the tunnel terminal is open and the VM IP is current.
2. Check verified SSH access; do not disable host-key checking.
3. Inside the VM, curl 127.0.0.1:8081.
4. If local curl fails, inspect Compose ps/logs and the image/mount.
5. If local curl works, inspect tunnel target and occupied laptop ports.
6. Do not add public port 8081 or widen the SSH source range.
7. After repair, retest local curl AND the laptop tunnel.
Escalate: unexpected target identity, missing data, or a shared host.A runbook should state scope, diagnostic evidence, safe actions, stop conditions and verification. “Restart everything” is not a diagnosis. Do not automate destructive repairs just because a check fails.
Build a portfolio without publishing your identity
Keep a private working record and make a separate sanitized public version. Review account/subscription/project identifiers, terminal usernames, IPs, domain ownership details, paths, log contents, email addresses and screenshots. Never share private keys, sessions, state files, credential files or a plan containing sensitive values.
Use a project/brand label rather than a personal byline. Repository history, author metadata and external profile links can reveal details even when the page does not. Do not upload private lab material to the public website package. This site does not verify domain-registration privacy or guarantee anonymity.
Can you answer these without guessing?
- Where does the app process run, and who owns its operating system?
- What is the exact traffic path and which access controls apply?
- Which identity creates resources, logs in, and calls cloud APIs?
- Where is important data, and what survives VM deletion?
- Which failure did you deliberately diagnose or restore from?
- What costs money while running and after stopping?
- Which claims have evidence, and which capabilities are only planned?