43 lines
3.7 KiB
Markdown
43 lines
3.7 KiB
Markdown
# Teaching notes
|
|
|
|
- Prefer practical, scenario-based tasks that are harder than the real CKS exam.
|
|
- Present exactly one active question in `ANSWER.md`.
|
|
- Make answering easy with explicit headings, checkboxes, and fenced blocks.
|
|
- Do not reveal or implement the solution to an active question.
|
|
- Review only what the learner wrote in `ANSWER.md`.
|
|
- On an imperfect submission, create a checklist of observed mistakes, but expose and coach only one mistake at a time.
|
|
- Hint ladder: (1) goal-oriented nudge, (2) concept pointer, (3) narrow official-doc reference, (4) command/API-shape clue, (5) near-complete scaffold with blanks. Never fill the final answer.
|
|
- Score after the submitted answer is functionally complete, then require a fresh transfer question before declaring the topic satisfactory if any coaching was needed.
|
|
- One-attempt success on a fresh question means satisfactory; otherwise continue the same topic with a new question after remediation.
|
|
- Interleave older mastered skills into later questions for retention.
|
|
- Keep questions compact: one focused operation, minimal prose, and a short Section B answer area.
|
|
- For configuration-edit tasks, provide the complete realistic exercise file (or a clearly labeled complete exam-supplied file), not only the line to change. The learner should practice locating the field and preserving structure/indentation.
|
|
|
|
## Mastery and scoring protocol
|
|
|
|
1. Learner edits `ANSWER.md` and says the attempt is ready.
|
|
2. Teacher evaluates the answer against an unpublished functional rubric.
|
|
3. If incomplete, teacher records all detected issues internally but presents only the first unresolved mistake.
|
|
4. Learner fixes that mistake in the file. Teacher then verifies it and reveals the next mistake, if any.
|
|
5. Only Section B (the implementation/manifests) is scored, out of 100:
|
|
- Functional correctness against the requested end state: 70
|
|
- Security and least privilege: 20
|
|
- Manifest/API precision: 10
|
|
Sections A, C, and D are checked for correctness and used for feedback, but contribute zero points.
|
|
6. If the original attempt earned at least 90 and required no correction, mark the topic satisfactory.
|
|
7. If correction or hints were needed, give a new, harder transfer question in the same topic. Only a first-attempt score of at least 90 with no critical security error unlocks the next topic.
|
|
8. Attempts are counted per question; topic status is tracked in `CKS-SYLLABUS-CHECKLIST.md`.
|
|
|
|
## Gamification
|
|
|
|
- Clean first-attempt completion: 100 XP.
|
|
- Completion after remediation: 40 XP.
|
|
- Topic mastery bonus: 150 XP.
|
|
- Skipped question: 0 XP.
|
|
- Ranks: Cadet (0), Scout (100), Defender (250), Sentinel (500), Guardian (900), CKS Elite (1400).
|
|
- Keep `dashboard.html` synchronized whenever a question is graded, completed, skipped, or unlocked.
|
|
- Ignore harmless spelling/formatting slips when intent and executability remain unambiguous. Still flag errors that break a command, invalidate YAML, change security behavior, or omit a required outcome.
|
|
- Learner reports strong confidence with Ingress and TLS but frequently forgets or mistypes NGINX Ingress annotations; interleave annotation recall later.
|
|
- Never skip, archive as incomplete, or advance past an active question unless the learner explicitly uses the word `skip` or clearly says to move to the next topic. Treat `go`, `check`, `verify`, and similar short messages as requests to continue checking the current answer.
|
|
- Keep tasks close to realistic CKS execution complexity. Do not require defensive shell control flow (`if`, elaborate `&&` chains, scripting) when a candidate can run a verification command, observe its result, and then perform the next command. Hardness should come from Kubernetes security judgment, not incidental shell puzzles.
|