CKS-Lessons/CKS-MASTERY-CHECKLIST.md

CKS Mastery Checklist

Canonical progress record for CKS preparation. Update this file after every graded task so another computer or agent can resume without relying on chat history.

Dashboard

Last updated: 2026-08-27

Domain	Weight	Hero	Training	Not started	Total
Cluster Setup	15%	0	5	0	5
Cluster Hardening	15%	0	3	1	4
System Hardening	10%	0	2	2	4
Minimize Microservice Vulnerabilities	20%	0	4	0	4
Supply Chain Security	20%	0	3	1	4
Monitoring, Logging and Runtime Security	20%	0	5	0	5
Total	100%	0	22	4	26

The syllabus supplied for this program contains 26 tracked topics.

Status Legend

• [ ] NOT STARTED: no dedicated practical evidence.
• [~] TRAINING: relevant lessons exist, but the Hero gate is incomplete.
• [x] HERO: tool drill, timed capstone, evidence, and cold retest all passed.
• BLOCKED: environment prevents practice; record the exact limitation and use a valid alternate environment.

Hero Gate

A topic becomes Hero only when every item is checked:

• Tool drill completed using the topic's primary operational tools.
• Original capstone completed at exam difficulty or harder within its time limit.
• Verification evidence saved: commands plus meaningful output, not YAML alone.
• No critical security or scope error remains after review.
• Cold retest passed in a later session without stepwise prompting.
• Evidence paths and date added to this checklist.

Minor syntax corrections during training are expected. A cold retest fails when the solution needs field-by-field coaching, grants excess privilege, breaks required behavior, omits proof, or changes resources outside scope.

Exam-Simulation Rules

• Every graded question is a Linux command-line lab on a designated host or Kubernetes context.
• Prompts specify an end state; the learner changes files, resources, processes, or policies to reach it.
• Deliverables are the resulting state plus short command/output evidence. Essays, prose tables, PowerShell parsing, and multiple-choice answers are not graded tasks.
• Tools are used directly when the syllabus names them. A scanner task requires running the scanner and changing the system, not writing about scanner theory.
• Harder-than-exam means more interacting controls, realistic faults, or a tighter time limit. It does not mean more literature questions.
• When the current computer lacks the required Linux/Kubernetes environment, mark the task environment-blocked and use a Linux lab; do not replace it with a written substitute.

Resume Protocol

1. Read MISSION.md, NOTES.md, the newest learning record, and this file.
2. Show the dashboard and list Hero, Training, Not Started, and Blocked topics.
3. Continue Next task unless the learner selects another topic.
4. Save each answer under lab/, each lesson under lessons/, and durable insight under learning-records/.
5. After grading, update status, Hero-gate boxes, evidence, attempt log, dashboard counts, and Next task.
6. Show the learner the updated done-versus-remaining summary.

Next Task

Finish the one-time local lab installation after Windows restarts, then run CS-02.Q1 as revised Lesson 0036 on kind-cks-lab. Do not use the learner's Kubernetes v1.36 production cluster: kube-bench v0.16.0 has automatic version mappings only through v1.34.

Local Lab Environment

Status: WINDOWS RESTART REQUIRED

• Platform: Ubuntu 24.04 on WSL2, Docker Engine, two-node Kind cluster, and Calico.
• Kubernetes: pinned to v1.34.0; kube-bench: pinned to v0.16.0.
• Cluster and context: cks-lab / kind-cks-lab.
• Kubeconfig: /opt/cks-lab/kubeconfig; it is never merged with a production config.
• Setup and recovery files: lab-environment/.
• Resume after restart: run lab-environment\\02-install-and-build.ps1, then lab-environment\\verify-lab.ps1.
• Lesson scope: use Kind nodes for Kubernetes tasks and the disposable Ubuntu WSL2 VM for host/kernel hardening tasks.

---

Cluster Setup - 15%

CS-01 - Use network security policies to restrict cluster-level access

Status: [~] TRAINING

Tools: kubectl, NetworkPolicy API, curl/wget, temporary test Pods, CNI policy observability where available.

Prior evidence: Lessons 0002, 0008, 0029, and 0034. The learner can build default-deny and selector-scoped ingress/egress policies, include CoreDNS, and combine Namespace and Pod selectors.

Question bank:

• CS-01.Q1 - Given five namespaces and six traffic requirements, produce the minimum additive policy set and prove every allowed and denied flow with disposable client Pods.
• CS-01.Q2 - Repair a policy where split peer items accidentally OR namespace and Pod selectors; demonstrate the over-permitted flow before and denial after.
• CS-01.Q3 - Isolate control-plane and node endpoints from an application namespace while preserving DNS and one internal API dependency.
• CS-01.Q4 - Hard capstone: troubleshoot a syntactically valid policy that has no effect because of selectors, CNI behavior, or existing additive policies; submit packet-flow evidence.

Hero-specific acceptance: prove ingress and egress outcomes, explain additive policy behavior, and avoid wildcard peers, IP-based shortcuts, or accidental DNS failure.

Hero gate: [ ] Tool drill [ ] Timed capstone [ ] Evidence [ ] Cold retest

CS-02 - Use CIS benchmarks to review Kubernetes components

Status: [~] TRAINING

Tools: kube-bench, systemctl, ps, grep, kubectl, static manifests, kubelet config, CoreDNS ConfigMap.

Prior evidence: Lessons 0015, 0022, 0028, and 0035 cover kubelet and kube-apiserver manually. Dedicated kube-bench, etcd, and CoreDNS review evidence is missing.

Question bank:

• CS-02.Q1 - Run kube-bench for control-plane and node checks; classify PASS, FAIL, WARN, and manual checks without blindly applying recommendations.
• CS-02.Q2 - Harden an etcd static manifest: client certificate authentication, peer TLS, trusted CAs, ownership, and metrics exposure; preserve cluster membership flags.
• CS-02.Q3 - Review kubelet flags plus KubeletConfiguration, reconcile conflicting settings, and verify the effective running process.
• CS-02.Q4 - Review CoreDNS deployment, ServiceAccount, RBAC, ConfigMap, image, and security context; distinguish CIS-relevant component configuration from workload hardening.
• CS-02.Q5 - Hard capstone: given kube-bench output containing false positives and manual checks, remediate only proven failures across API server, etcd, kubelet, and CoreDNS.

Hero-specific acceptance: correlate scanner output with effective configuration and preserve required component behavior.

Hero gate: [ ] Tool drill [ ] Timed capstone [ ] Evidence [ ] Cold retest

CS-03 - Properly set up Ingress with TLS

Status: [~] TRAINING

Tools: openssl, kubectl, Ingress API, TLS Secrets, curl -vk, openssl s_client.

Prior evidence: Lesson 0016. Ingress v1 nesting and host alignment required correction; live certificate inspection needs more practice.

Question bank:

• CS-03.Q1 - Generate a certificate and key, create a TLS Secret, configure v1 Ingress, and verify hostname, chain, and backend routing.
• CS-03.Q2 - Repair mismatched rule host, TLS host, Secret namespace, backend schema, and path type without changing the Service.
• CS-03.Q3 - Use openssl s_client and curl --resolve to distinguish certificate, DNS, Ingress, and backend failures.
• CS-03.Q4 - Hard capstone: migrate two HTTP routes to TLS with separate hostnames and prove that plaintext behavior matches stated redirect requirements.

Hero-specific acceptance: certificate identity, Secret scope, route semantics, and end-to-end TLS evidence must all be correct.

Hero gate: [ ] Tool drill [ ] Timed capstone [ ] Evidence [ ] Cold retest

CS-04 - Protect node metadata and endpoints

Status: [~] TRAINING

Tools: NetworkPolicy, curl, cloud metadata addresses, CNI policy tools, workload identity controls, ss, systemctl, kubelet configuration, client certificates.

Prior evidence: Lessons 0015, 0028, and 0029 cover link-local metadata isolation plus kubelet anonymous auth, webhook modes, read-only port, and certificate rotation.

Question bank:

• CS-04.Q1 - Demonstrate metadata reachability from a disposable Pod, then deny it without breaking required internal egress.
• CS-04.Q2 - Compare broad ipBlock denial with positive egress allowlisting and explain residual paths through proxies or host networking.
• CS-04.Q3 - Harden a cloud workload using both network isolation and workload identity rather than static cloud credentials.
• CS-04.Q4 - Hard capstone: contain metadata access for selected tenants while preserving DNS, API-server access, and one external HTTPS destination.
• CS-04.Q5 - Enumerate listening Kubernetes node endpoints and identify which require authentication, authorization, or removal.
• CS-04.Q6 - Harden kubelet config and prove anonymous requests fail while authorized health and management paths remain functional.
• CS-04.Q7 - Review metrics, health, debug, and read-only ports; distinguish binding exposure from application-layer authorization.
• CS-04.Q8 - Hard capstone: remediate metadata, kubelet, and node-firewall exposure together, then prove effective endpoint behavior.

Hero-specific acceptance: show before-and-after metadata requests, verify listening sockets and authenticated endpoint behavior, and identify NetworkPolicy limitations for host-network or unsupported CNI cases.

Hero gate: [ ] Tool drill [ ] Timed capstone [ ] Evidence [ ] Cold retest

CS-05 - Verify platform binaries before deploying

Status: [~] TRAINING

Tools: sha256sum/Get-FileHash, signed checksum files, gpg, release metadata, package-manager verification.

Prior evidence: Lesson 0019 verifies pinned Kubernetes binaries against checksums.

Question bank:

• CS-05.Q1 - Download a pinned Kubernetes binary and official checksum, verify it, and record provenance.
• CS-05.Q2 - Detect a tampered binary among valid artifacts without executing any candidate.
• CS-05.Q3 - Verify a signed checksum manifest with GPG, then verify the binary against that trusted manifest.
• CS-05.Q4 - Hard capstone: build a repeatable verification chain for kubelet, kubectl, and a security scanner, including failure handling.

Hero-specific acceptance: pin versions, verify the trust root, fail closed on mismatch, and save exact commands and hashes.

Hero gate: [ ] Tool drill [ ] Timed capstone [ ] Evidence [ ] Cold retest

---

Cluster Hardening - 15%

CH-01 - Use RBAC to minimize exposure

Status: [~] TRAINING

Tools: kubectl auth can-i, kubectl auth reconcile, RBAC API, impersonation flags, structured manifest inspection.

Prior evidence: Lessons 0003, 0009, and 0024. Namespace scope, subresources, resourceNames, and negative permission tests are established strengths after correction.

Question bank:

• CH-01.Q1 - Replace a wildcard Role with the smallest verbs, API groups, resources, subresources, and named resources that satisfy a workload.
• CH-01.Q2 - Find privilege-escalation paths involving bind, escalate, impersonate, token creation, and workload creation.
• CH-01.Q3 - Prove positive and negative permissions using impersonation for users, groups, and ServiceAccounts.
• CH-01.Q4 - Hard capstone: remediate overlapping RoleBindings and ClusterRoleBindings without breaking one required cross-namespace workflow.

Hero-specific acceptance: no wildcard privilege, every required permission proven, and every prohibited permission denied.

Hero gate: [ ] Tool drill [ ] Timed capstone [ ] Evidence [ ] Cold retest

CH-02 - Exercise caution with ServiceAccounts

Status: [~] TRAINING

Tools: kubectl, TokenRequest API, projected ServiceAccount tokens, RBAC, Pod inspection.

Prior evidence: Lessons 0007 and 0034 cover automount suppression and least privilege.

Question bank:

• CH-02.Q1 - Disable the default token for a namespace and enable a short-lived projected token only for one container with a fixed audience.
• CH-02.Q2 - Replace use of the default ServiceAccount with a dedicated identity and minimal Role/RoleBinding.
• CH-02.Q3 - Inspect a Pod for legacy Secret-based tokens, projected tokens, audiences, expiration, and unintended mounts.
• CH-02.Q4 - Hard capstone: preserve one API-calling sidecar while preventing every other container from receiving cluster credentials.

Hero-specific acceptance: token exposure and RBAC authority must both be minimized and verified.

Hero gate: [ ] Tool drill [ ] Timed capstone [ ] Evidence [ ] Cold retest

CH-03 - Restrict access to the Kubernetes API

Status: [~] TRAINING

Tools: kube-apiserver flags, authentication and authorization config, admission plugins, firewall/listener inspection, audit logs.

Prior evidence: Lessons 0022 and 0035 cover anonymous auth, Node/RBAC authorization, ServiceAccount lookup, profiling, NodeRestriction, and audit integration.

Question bank:

• CH-03.Q1 - Harden an API-server static manifest while preserving certificates, etcd, ServiceAccount signing, and admission configuration.
• CH-03.Q2 - Restrict network reachability to the secure API endpoint and prove unauthorized and authorized outcomes.
• CH-03.Q3 - Identify dangerous authentication files, anonymous paths, permissive authorization, and insecure profiling/debug exposure.
• CH-03.Q4 - Hard capstone: reconcile flags with structured authentication/authorization configuration and verify the effective process.

Hero-specific acceptance: preserve control-plane availability and prove both network and request-layer restrictions.

Hero gate: [ ] Tool drill [ ] Timed capstone [ ] Evidence [ ] Cold retest

CH-04 - Upgrade Kubernetes to avoid vulnerabilities

Status: [ ] NOT STARTED

Tools: kubeadm, kubectl drain, apt/dnf, package holds, version-skew policy, release notes.

Prior evidence: none dedicated.

Question bank:

• CH-04.Q1 - Inspect current versions, choose a supported target using version-skew rules, and produce the control-plane upgrade plan.
• CH-04.Q2 - Upgrade kubeadm, run kubeadm upgrade plan, apply the selected version, then upgrade kubelet and kubectl safely.
• CH-04.Q3 - Drain, upgrade, restart, and uncordon a worker while preserving workload availability.
• CH-04.Q4 - Hard capstone: recover from a partially completed upgrade with mismatched kubeadm, kubelet, and API-server versions.

Hero-specific acceptance: version selection, node ordering, drain behavior, package holds, health verification, and rollback reasoning must be demonstrated.

Hero gate: [ ] Tool drill [ ] Timed capstone [ ] Evidence [ ] Cold retest

---

System Hardening - 10%

SH-01 - Minimize host OS footprint

Status: [ ] NOT STARTED

Tools: systemctl, ss, ps, package manager, filesystem permissions, system logs.

Prior evidence: none dedicated.

Question bank:

• SH-01.Q1 - Inventory installed packages, running services, listening sockets, and scheduled jobs on a Kubernetes node.
• SH-01.Q2 - Disable and remove unnecessary services without disrupting kubelet, runtime, networking, storage, or time synchronization.
• SH-01.Q3 - Review sensitive Kubernetes directories and correct unsafe ownership or permissions.
• SH-01.Q4 - Hard capstone: reduce an intentionally bloated node image and prove cluster health plus reduced attack surface.

Hero-specific acceptance: every removal needs a dependency justification and post-change node-health evidence.

Hero gate: [ ] Tool drill [ ] Timed capstone [ ] Evidence [ ] Cold retest

SH-02 - Use least-privilege host identity and access management

Status: [ ] NOT STARTED

Tools: Linux users/groups, sudo, SSH configuration, systemd unit identity, file capabilities, ownership and modes.

Prior evidence: Kubernetes RBAC experience exists, but host IAM has no dedicated practical evidence.

Question bank:

• SH-02.Q1 - Replace shared root access with named accounts and narrowly scoped sudo commands.
• SH-02.Q2 - Run a node service under a dedicated non-login account with minimal filesystem access.
• SH-02.Q3 - Audit SSH root login, password authentication, authorized keys, group membership, and sudoers fragments.
• SH-02.Q4 - Hard capstone: contain a compromised maintenance account without breaking kubelet or container runtime operation.

Hero-specific acceptance: prove denied privilege escalation and preserved operational access using audit-friendly named identities.

Hero gate: [ ] Tool drill [ ] Timed capstone [ ] Evidence [ ] Cold retest

SH-03 - Minimize external network access

Status: [~] TRAINING

Tools: ss, nft/iptables, cloud firewall/security groups, host firewall, curl, nc, NetworkPolicy.

Prior evidence: Lessons 0015, 0029, and 0034 cover workload and kubelet exposure; host-firewall evidence is missing.

Question bank:

• SH-03.Q1 - Enumerate listeners and map each socket to process, interface, required clients, and authentication control.
• SH-03.Q2 - Restrict node management ports to an administration CIDR while preserving cluster traffic.
• SH-03.Q3 - Distinguish host firewall, cloud firewall, Service exposure, and NetworkPolicy responsibilities.
• SH-03.Q4 - Hard capstone: reduce external exposure across a node, NodePort Service, and host-network workload, then prove allowed and denied paths.

Hero-specific acceptance: evidence must cover effective listeners and remote reachability from both permitted and prohibited sources.

Hero gate: [ ] Tool drill [ ] Timed capstone [ ] Evidence [ ] Cold retest

SH-04 - Use AppArmor and seccomp appropriately

Status: [~] TRAINING

Tools: apparmor_parser, aa-status, AppArmor profiles, seccomp profiles, Pod securityContext, runtime events.

Prior evidence: Lessons 0004, 0011, and 0033. AppArmor enforcement was blocked by the Docker Desktop/WSL2 kernel; seccomp manifest work is established.

Question bank:

• SH-04.Q1 - Create, load, and enforce an AppArmor profile that permits required reads but denies a sensitive write.
• SH-04.Q2 - Apply RuntimeDefault seccomp and diagnose a workload that requires a narrowly justified custom profile.
• SH-04.Q3 - Compare Pod-level and container-level profile scope and prove enforcement with an attempted forbidden operation.
• SH-04.Q4 - Hard capstone: harden a multi-container workload with different profiles and debug a node/profile-name mismatch.

Hero-specific acceptance: must run on an AppArmor-enabled Linux host for AppArmor Hero; manifest-only evidence remains Training.

Hero gate: [ ] Tool drill [ ] Timed capstone [ ] Evidence [ ] Cold retest

---

Minimize Microservice Vulnerabilities - 20%

MM-01 - Use appropriate Pod Security Standards

Status: [~] TRAINING

Tools: Pod Security Admission labels, PSS documentation, dry runs, admission output, workload security contexts.

Prior evidence: Lessons 0005, 0021, 0031, 0033, and 0034.

Question bank:

• MM-01.Q1 - Classify workloads against Privileged, Baseline, and Restricted, identifying every violating field.
• MM-01.Q2 - Migrate a namespace through warn, audit, and enforce with pinned policy versions and no avoidable outage.
• MM-01.Q3 - Remediate a Deployment to Restricted while preserving required writable paths and network binding.
• MM-01.Q4 - Hard capstone: manage exemptions and mixed legacy workloads without weakening the entire namespace.

Hero-specific acceptance: prove admitted compliant workloads and rejected noncompliant workloads at the correct scope.

Hero gate: [ ] Tool drill [ ] Timed capstone [ ] Evidence [ ] Cold retest

MM-02 - Manage Kubernetes Secrets

Status: [~] TRAINING

Tools: Secret API, projected volumes, encryption configuration, RBAC, etcdctl, rotation workflow.

Prior evidence: Lessons 0010, 0018, and 0032 cover selective projection, encryption at rest, exposure investigation, and rotation reasoning.

Question bank:

• MM-02.Q1 - Project only one Secret key into one container with correct file mode and no environment-variable exposure.
• MM-02.Q2 - Configure encryption at rest, rewrite existing Secrets, and prove ciphertext in etcd plus readable API behavior.
• MM-02.Q3 - Identify Secret exposure through RBAC, Pod specs, logs, shell history, and mounted tokens; remediate each path.
• MM-02.Q4 - Hard capstone: rotate an accessed external credential across producers and consumers without retaining the old value.

Hero-specific acceptance: minimize distribution, prove storage encryption, and demonstrate actual credential invalidation.

Hero gate: [ ] Tool drill [ ] Timed capstone [ ] Evidence [ ] Cold retest

MM-03 - Implement isolation and multi-tenancy

Status: [~] TRAINING

Tools: namespaces, RBAC, quotas, NetworkPolicy, Pod Security Admission, admission policy, RuntimeClass/sandboxed runtime.

Prior evidence: Lessons 0017, 0031, and 0034 cover scoped admission and workload/network isolation. Sandboxed runtime evidence is missing.

Question bank:

• MM-03.Q1 - Build a tenant namespace baseline combining RBAC, quotas, PSS, default-deny networking, and dedicated ServiceAccounts.
• MM-03.Q2 - Prevent host namespace, privileged, hostPath, and unsafe capability use with correctly scoped admission logic.
• MM-03.Q3 - Configure and select a sandboxed RuntimeClass, then verify the effective runtime handler.
• MM-03.Q4 - Hard capstone: isolate two tenants while preserving one explicitly shared service and administrative break-glass path.

Hero-specific acceptance: prove cross-tenant denials at API, network, storage, and runtime boundaries.

Hero gate: [ ] Tool drill [ ] Timed capstone [ ] Evidence [ ] Cold retest

MM-04 - Implement Pod-to-Pod encryption

Status: [~] TRAINING

Tools: Cilium CLI/status, WireGuard status, Istio istioctl, PeerAuthentication, AuthorizationPolicy, traffic capture where allowed.

Prior evidence: Lessons 0023, 0025, and 0026 cover Cilium WireGuard, Istio strict mTLS, and workload authorization.

Question bank:

• MM-04.Q1 - Enable Cilium WireGuard and prove node encryption status plus encrypted Pod traffic.
• MM-04.Q2 - Enforce namespace-wide Istio STRICT mTLS and identify workloads that fail because they lack sidecars.
• MM-04.Q3 - Pair mTLS with AuthorizationPolicy so encryption does not become mistaken for authorization.
• MM-04.Q4 - Hard capstone: diagnose mixed plaintext/encrypted traffic across namespaces and prove the final data path.

Hero-specific acceptance: use implementation-specific status tools and traffic evidence, not policy YAML alone.

Hero gate: [ ] Tool drill [ ] Timed capstone [ ] Evidence [ ] Cold retest

---

Supply Chain Security - 20%

SC-01 - Minimize base image footprint

Status: [ ] NOT STARTED

Tools: Docker/BuildKit, multi-stage builds, distroless or minimal images, Trivy, Dive where available.

Prior evidence: no dedicated image-rebuild and comparison task.

Question bank:

• SC-01.Q1 - Convert a development image into a multi-stage production build with no compiler or package manager in the final stage.
• SC-01.Q2 - Compare package count, size, users, shell availability, and vulnerability results before and after minimization.
• SC-01.Q3 - Run the final image as non-root with a read-only root filesystem and explicit writable paths.
• SC-01.Q4 - Hard capstone: minimize an image without breaking TLS roots, timezone data, health checks, or runtime dependencies.

Hero-specific acceptance: quantitative before/after evidence plus successful runtime behavior is required.

Hero gate: [ ] Tool drill [ ] Timed capstone [ ] Evidence [ ] Cold retest

SC-02 - Understand the supply chain

Status: [~] TRAINING

Tools: Syft, CycloneDX/SPDX, CI logs, artifact repositories, provenance/attestations, dependency metadata.

Prior evidence: Lesson 0030 generates and interprets a CycloneDX SBOM with Syft.

Question bank:

• SC-02.Q1 - Generate CycloneDX and SPDX SBOMs with Syft and compare component identity and relationships.
• SC-02.Q2 - Trace a deployed digest back through registry metadata, build job, source revision, and SBOM.
• SC-02.Q3 - Use an SBOM to answer impact from a newly disclosed component vulnerability without claiming exploitability.
• SC-02.Q4 - Hard capstone: investigate a mismatched SBOM, image digest, and deployment reference and identify the broken provenance link.

Hero-specific acceptance: distinguish inventory, vulnerability, provenance, signature, and deployment policy evidence.

Hero gate: [ ] Tool drill [ ] Timed capstone [ ] Evidence [ ] Cold retest

SC-03 - Secure permitted registries and validate artifacts

Status: [~] TRAINING

Tools: Cosign, container registry, image digests, admission policy, public-key or keyless verification, attestations.

Prior evidence: Lessons 0013 and 0019 cover digest enforcement and artifact checksum verification. Cosign signing and verification are missing.

Question bank:

• SC-03.Q1 - Sign a pinned image digest with Cosign and verify it using the intended trust identity.
• SC-03.Q2 - Enforce an allowed registry and immutable digest policy across regular, init, and ephemeral containers.
• SC-03.Q3 - Validate an SBOM or provenance attestation and reject a signature from the wrong identity or repository.
• SC-03.Q4 - Hard capstone: admit only correctly signed images from permitted registries while preserving an audited break-glass process.

Hero-specific acceptance: verification must bind identity, repository, and digest; signature presence alone is insufficient.

Hero gate: [ ] Tool drill [ ] Timed capstone [ ] Evidence [ ] Cold retest

SC-04 - Perform static analysis of workloads and images

Status: [~] TRAINING

Tools: Kubesec, KubeLinter, Trivy config/image, scanner exit codes, CI integration.

Prior evidence: Lesson 0027 uses Trivy configuration scanning. Kubesec, KubeLinter, and Trivy image scanning remain unpracticed.

Question bank:

• SC-04.Q1 - Scan the same manifest with Kubesec, KubeLinter, and Trivy; normalize overlapping and tool-specific findings.
• SC-04.Q2 - Scan a pinned image with Trivy, prioritize exploitable/runtime-relevant findings, and avoid equating count with risk.
• SC-04.Q3 - Configure CI to fail on a justified severity/fixability policy while preserving machine-readable reports.
• SC-04.Q4 - Hard capstone: remediate manifest and image findings, rerun every scanner, and explain accepted residual risk and false positives.

Hero-specific acceptance: use at least three named tools, preserve raw reports, and distinguish configuration from package-vulnerability results.

Hero gate: [ ] Tool drill [ ] Timed capstone [ ] Evidence [ ] Cold retest

---

Monitoring, Logging and Runtime Security - 20%

MR-01 - Perform behavioral analytics

Status: [~] TRAINING

Tools: Falco, rule files, JSON output, baseline comparison, process/network telemetry.

Prior evidence: Lesson 0020 covers runtime shell detection with Falco-style evidence.

Question bank:

• MR-01.Q1 - Establish a workload behavior baseline and identify process, file, and network deviations.
• MR-01.Q2 - Write and test a Falco rule for an interactive shell or sensitive file access inside a container.
• MR-01.Q3 - Tune a noisy rule using workload identity and syscall context without hiding real attacks.
• MR-01.Q4 - Hard capstone: correlate multiple low-confidence events into one high-confidence malicious sequence.

Hero-specific acceptance: provide triggering and non-triggering tests plus a justified noise-control strategy.

Hero gate: [ ] Tool drill [ ] Timed capstone [ ] Evidence [ ] Cold retest

MR-02 - Detect threats across infrastructure, apps, networks, data, users, and workloads

Status: [~] TRAINING

Tools: Falco, audit logs, host logs, NetworkPolicy/CNI flow logs, application logs, identity events, file-integrity evidence.

Prior evidence: Lessons 0012, 0020, and 0032 cover API and runtime signals; full cross-layer correlation is missing.

Question bank:

• MR-02.Q1 - Map one signal source and one high-value detection to each of the six threat surfaces.
• MR-02.Q2 - Detect suspicious node login, privileged workload creation, lateral network movement, Secret access, and runtime execution.
• MR-02.Q3 - Separate preventive controls from detective evidence and identify blind spots in each layer.
• MR-02.Q4 - Hard capstone: correlate host, Kubernetes, network, and application telemetry into one defensible incident timeline.

Hero-specific acceptance: identify principal, asset, action, outcome, source, and timestamp from more than one telemetry layer.

Hero gate: [ ] Tool drill [ ] Timed capstone [ ] Evidence [ ] Cold retest

MR-03 - Investigate phases of attack and bad actors

Status: [~] TRAINING

Tools: jq/PowerShell JSON parsing, audit logs, Falco events, Pod and RBAC inspection, timeline notes.

Prior evidence: Lessons 0012 and 0032 reconstruct escalation, Secret access, and exec activity with ordered containment.

Question bank:

• MR-03.Q1 - Reconstruct initial access, privilege escalation, discovery, credential access, execution, and persistence from mixed logs.
• MR-03.Q2 - Distinguish rejected attempts from successful actions using response codes and runtime outcomes.
• MR-03.Q3 - Pivot by authenticated principal, source IP, workload identity, resource, and time without using audit IDs as identities.
• MR-03.Q4 - Hard capstone: produce a concise incident report with evidence, confidence, blast radius, and ordered containment.

Hero-specific acceptance: include the exact structured query command and cite the event evidence for every conclusion.

Hero gate: [ ] Tool drill [ ] Timed capstone [ ] Evidence [ ] Cold retest

MR-04 - Ensure container immutability at runtime

Status: [~] TRAINING

Tools: securityContext, read-only root filesystem, volumes, image digests, admission policy, Falco/file-integrity checks.

Prior evidence: Lessons 0006, 0013, 0033, and 0034 cover immutable images and read-only roots with explicit writable volumes.

Question bank:

• MR-04.Q1 - Harden a workload with read-only roots and discover every required writable runtime path empirically.
• MR-04.Q2 - Enforce digest-only image references and prove mutable-tag rejection.
• MR-04.Q3 - Detect executable creation or package installation inside a running container and contain it.
• MR-04.Q4 - Hard capstone: combine preventive admission, runtime filesystem controls, and behavioral detection without breaking the application.

Hero-specific acceptance: prove immutable image identity, failed root writes, allowed explicit writes, and runtime alert behavior.

Hero gate: [ ] Tool drill [ ] Timed capstone [ ] Evidence [ ] Cold retest

MR-05 - Use Kubernetes audit logs to monitor access

Status: [~] TRAINING

Tools: audit Policy, kube-apiserver flags and mounts, jq, log rotation, event correlation.

Prior evidence: Lessons 0012, 0014, 0032, and 0035 cover policy design, persistent logging, filtering, and incident reconstruction.

Question bank:

• MR-05.Q1 - Design an ordered audit policy for Secrets, RBAC changes, Pod exec, authentication failures, and a Metadata catch-all.
• MR-05.Q2 - Configure file-backend persistence and rotation in a kube-apiserver static Pod and prove the effective process flags.
• MR-05.Q3 - Write structured queries for principal, source, verb, resource, response code, and time windows.
• MR-05.Q4 - Hard capstone: diagnose missing events caused by rule ordering, level choice, omitted stages, path mounts, or log rotation.

Hero-specific acceptance: prove event generation end to end from API request through persisted log and structured query.

Hero gate: [ ] Tool drill [ ] Timed capstone [ ] Evidence [ ] Cold retest

---

Attempt Log

Append one row after every graded attempt.

Date	Task	Topic	Time	Result	Critical errors	Evidence	Next action
2026-08-26	Lesson 0035	CH-03 / MR-05	Not recorded	Training pass	0 after review	lab/lesson-35-kube-apiserver-answer.yaml, lab/lesson-35-audit-policy.yaml	Cold retest later
2026-08-26	Lesson 0034	CS-01 / MM-01	Not recorded	Training pass	0 after review	lab/lesson-34-answer.yaml	Cold retest later
2026-08-25	Lesson 0032	MR-03	Not recorded	Training; evidence incomplete	0 substantive; command omitted	lab/lesson-32-answer.md	Require structured query next time

Current Summary

Hero topics: none yet.

Training topics: CS-01, CS-02, CS-03, CS-04, CS-05, CH-01, CH-02, CH-03, SH-03, SH-04, MM-01, MM-02, MM-03, MM-04, SC-02, SC-03, SC-04, MR-01, MR-02, MR-03, MR-04, MR-05.

Not started: CH-04, SH-01, SH-02, SC-01.

Blocked: AppArmor runtime enforcement on the current Docker Desktop/WSL2 kernel. Use an AppArmor-enabled Linux host for the Hero attempt.