# Teaching notes

- Learner goal: career advancement and deeper technical security skills.
- Background: CKA, CKAD, and KodeKloud CKS training completed.
- Priority: build confidence through timed retrieval and hands-on feedback, not rewatching broad course material.
- Learner prefers original performance-based tasks at public CKS curriculum level or harder, with multi-control requirements and strict verification, so the real exam feels comparatively easy.
- Review preference: list all detected issues, then correct only one issue per round.
- Mastery tracking: use `CKS-MASTERY-CHECKLIST.md` as the canonical cross-session dashboard. Never award Hero from lesson completion alone; require the topic's tool drill, timed capstone, verification evidence, and cold retest.
- Confidence priority: deliberately rotate through named CKS tools instead of relying mainly on hand-written YAML.
- Exam-simulation rule: graded questions must be Linux command-line performance labs. Do not require PowerShell, essays, explanatory tables, multiple-choice answers, or tool-installation research as task deliverables. Grade the resulting system state and concise command/output evidence.
- Use short CKS-style prompts: designated host/context, exact end state, files/resources in scope, time limit, and verification. Hard mode may combine more controls or tighter time, but must remain a lab rather than a literature exercise.
- Local lab rule: run all future lessons in the disposable `cks-lab` environment under Ubuntu 24.04 WSL2. Use `/opt/cks-lab/kubeconfig` and require context `kind-cks-lab`; never use, copy, or merge a production kubeconfig.
- Lab targeting: use the Kind control-plane and worker containers for Kubernetes component/runtime exercises, and the enclosing Ubuntu WSL2 VM for host OS, IAM, firewall, AppArmor, seccomp, and kernel exercises.