Creating Labs

Best Practices

Guidelines for creating effective, maintainable POV Demo labs.

Lab Design

  • Choose a completion time that fits the learning objective and intended audience.
  • 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.

Command Separation

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.

Task Structure

  1. 1.Keep tasks focused; split a task when its instructions become hard to follow.
  2. 2.Reference the tab title in instructions when learners need to switch context: “In the Terminal tab, run:”.
  3. 3.Start each task with exploration — show the learner the current state before asking them to change anything.
  4. 4.End each task with a verification step — let the learner confirm their work before moving on.

Script Guidelines

  • Source the required profile explicitly when a script needs login-shell configuration; non-check scripts run with bash -e, so their shebang is ignored.
  • Use set -e when it makes failure handling clearer; the runtime executes non-check scripts with bash -e.
  • Pin all software versions explicitly: apt-get install -y kubectl=1.28.0-00 not apt-get install -y kubectl
  • Prefer idempotent scripts so a rerun does not create duplicate state.
  • Use history -s "cmd" when pre-populating terminal history.
  • Test scripts against a clean VM before submitting