Completed upto lesson 35
This commit is contained in:
11
learning-records/0006-audit-impact-and-containment-order.md
Normal file
11
learning-records/0006-audit-impact-and-containment-order.md
Normal file
@@ -0,0 +1,11 @@
|
||||
# Audit impact and containment order
|
||||
|
||||
The learner completed the substantive reasoning in Lesson 32. They distinguished a rejected RBAC attempt from a successful RoleBinding creation by checking `responseStatus.code`, identified the authenticated ServiceAccount principal, traced Secret access and Pod exec, and ordered containment as RBAC revocation, workload isolation, then credential rotation.
|
||||
|
||||
## Evidence
|
||||
|
||||
The incident note correctly identifies `system:serviceaccount:checkout:release-bot`, RoleBinding `checkout/release-bot-secret-reader`, Secret `checkout/payment-gateway`, and the exec target `checkout/checkout-api-6d8f`.
|
||||
|
||||
## Remaining evidence gap
|
||||
|
||||
The answer does not include the exact structured JSON filter command requested by the lesson. Continue requiring commands or output when a task asks for reproducible investigation evidence.
|
||||
11
learning-records/0007-security-context-placement.md
Normal file
11
learning-records/0007-security-context-placement.md
Normal file
@@ -0,0 +1,11 @@
|
||||
# SecurityContext placement retrieval
|
||||
|
||||
The learner completed Lesson 33 and explicitly preferred its manifest-hardening format. The final static manifest correctly separates Pod-wide identity and seccomp settings from container-level privilege escalation, capabilities, and read-only-root controls. It also confines the sidecar's writable state to an `emptyDir` mount.
|
||||
|
||||
## Coaching adjustment
|
||||
|
||||
Increase subsequent work to original, timed, multi-control tasks aligned with the public CKS curriculum or harder. Preserve exam-style brevity, require verification evidence, and continue listing all issues while correcting one per review round.
|
||||
|
||||
## Evidence limitation
|
||||
|
||||
The manifest passed static review. Runtime rollout and filesystem verification were not observed in the teaching shell.
|
||||
@@ -0,0 +1,15 @@
|
||||
# Multi-control workload and network boundary
|
||||
|
||||
The learner completed Lesson 34, an original hard-mode task combining a hardened two-container Deployment with one bidirectional NetworkPolicy. The final static manifest correctly preserves workload fields, disables automatic token mounting, applies Pod- and container-level security controls, provides only deliberate writable paths, and composes namespace and Pod selectors in the same NetworkPolicy peer.
|
||||
|
||||
## Evidence
|
||||
|
||||
The final NetworkPolicy isolates ingress and egress, permits only the edge gateway, database, and CoreDNS flows, and includes TCP and UDP DNS. The learner corrected schema placement and exact resource naming during review.
|
||||
|
||||
## Evidence limitation
|
||||
|
||||
Elapsed time was not recorded. Runtime rollout and connectivity checks were not observed in the teaching shell.
|
||||
|
||||
## Coaching adjustment
|
||||
|
||||
Continue with original multi-file, node-level, and multi-domain tasks at public CKS curriculum difficulty or harder. Require the learner to preserve unrelated operational configuration while correcting security weaknesses.
|
||||
11
learning-records/0009-hero-based-cks-mastery-system.md
Normal file
11
learning-records/0009-hero-based-cks-mastery-system.md
Normal file
@@ -0,0 +1,11 @@
|
||||
# Hero-based CKS mastery system
|
||||
|
||||
The learner requested an exhaustive, persistent checklist for every public CKS syllabus topic, with several tool-based questions per topic and visible done-versus-remaining status. The canonical state is stored in `CKS-MASTERY-CHECKLIST.md` so a different computer or agent can resume from repository files.
|
||||
|
||||
## Hero standard
|
||||
|
||||
A topic receives Hero only after the learner completes its tool drill, a timed original capstone at exam difficulty or harder, supplies verification evidence, and passes a cold retest on a later session without stepwise prompting. Existing lessons count as training evidence but do not grant Hero retroactively.
|
||||
|
||||
## Coaching behavior
|
||||
|
||||
At the start and end of each future CKS session, update the checklist dashboard, topic evidence, attempt log, next task, and done-versus-remaining summary. Prefer tools that have not yet been exercised enough, including kube-bench, kubeadm, Kubesec, KubeLinter, Trivy image scanning, Syft, Cosign, Falco, AppArmor tooling, and host-network inspection tools.
|
||||
Reference in New Issue
Block a user