Creating Labs

Best Practices

Guidelines for creating effective, maintainable POV Demo labs.

Lab Design

Target 30–45 minutes total completion time. Labs shorter than 20 minutes feel too easy; labs longer than 60 minutes lose learners.
Design for progressive difficulty: start with exploration tasks, build to creation, end with a validation or production scenario.
Each lab should teach one focused skill or workflow, not a comprehensive overview of a technology.
Write learning objectives before writing tasks — if you can't state what the learner will be able to do after the lab, the scope is unclear.

Each command in task instructions should be in its own code block. Do not combine multiple commands into one block.

Avoid

Both commands in one block:

kubectl create deployment my-app --image=nginx && kubectl expose deployment my-app --port=80

Correct

Each command in its own block:

kubectl create deployment my-app --image=nginx

Verify the deployment was created:

kubectl expose deployment my-app --port=80

Learners can run commands one at a time, verify the output of each, and understand what each command does before proceeding.

1.4–5 steps per task maximum. Restructure into multiple tasks if you need more.
2.Always reference the tab title in instructions: “In the Terminal tab, run:” (not just “Run:”).
3.Start each task with exploration — show the learner the current state before asking them to change anything.
4.End each task with a verification step — let the learner confirm their work before moving on.

Always use #!/bin/bash -l as the shebang to load the login shell profile
Always use set -e to fail fast on errors (required in solve scripts, strongly recommended everywhere)
Pin all software versions explicitly: apt-get install -y kubectl=1.28.0-00 not apt-get install -y kubectl
Make all scripts idempotent — they may be run more than once
Use history -s "cmd" to pre-populate terminal history; never use set -o history (causes HISTSIZE overflow)
Test scripts against a clean VM before submitting