Cheat sheet & self-check

Pick an answer to see if you got it, and why.

1. Q1. Which audit level records request metadata (who, what, when) but not the request or response body?

   1. ANone
   2. BMetadata
   3. CRequest
   4. DRequestResponse
   Show answer

   B. Metadata is the right level for Secrets: you learn who read which Secret, without writing the secret values into the log.

   From lesson 13 · Audit logging & runtime detection

2. Q2. What does Falco detect that API audit logs can't?

   1. Akubectl commands
   2. BBehaviour inside running containers and on nodes: shells spawned, sensitive files read, unexpected network connections
   3. CRBAC changes
   4. DCertificate expiry
   Show answer

   B. Audit logs cover the API. An attacker in a container never touches the API to read /etc/shadow or open a reverse shell; runtime detection sees it.

   From lesson 13 · Audit logging & runtime detection

3. Q3. Why not log every request at RequestResponse level?

   1. AIt's forbidden
   2. BHuge volume and cost, plus secrets and tokens would end up in logs
   3. CIt breaks kubectl
   4. DIt disables RBAC
   Show answer

   B. Audit policy is a trade-off: detail where it matters (RBAC changes, exec), metadata elsewhere, nothing for noisy low-value requests.

   From lesson 13 · Audit logging & runtime detection

4. Q4. What does kube-bench do?

   1. ALoad-tests the cluster
   2. BChecks the configuration of control-plane components, kubelets and node files against the CIS Kubernetes Benchmark
   3. CScans images
   4. DEncrypts etcd
   Show answer

   B. It reads flags, config files and file permissions, and reports PASS/FAIL/WARN per benchmark recommendation.

   From lesson 14 · CIS benchmark hardening

5. Q5. Why is the kubelet's read-only port (10255) a risk?

   1. AIt's slow
   2. BIt serves pod and node information without authentication
   3. CIt allows exec
   4. DIt opens SSH
   Show answer

   B. Anyone who can reach the node can read details about pods (names, images, environment hints). Set readOnlyPort: 0.

   From lesson 14 · CIS benchmark hardening

6. Q6. kube-bench reports FAIL for a control-plane check on a managed service (e.g. EKS). What's the right reaction?

   1. AIgnore all results
   2. BUse the provider-specific benchmark: managed control planes are the provider's responsibility and aren't visible to node-level scans
   3. CRebuild the control plane
   4. DDisable the check globally
   Show answer

   B. CIS publishes managed-service benchmarks (EKS, GKE, AKS) covering what you actually control: nodes, RBAC, policies.

   From lesson 14 · CIS benchmark hardening

7. Q7. What is 'defence in depth'?

   1. AOne very strong control
   2. BSeveral independent layers, so an attacker who defeats one still meets others
   3. CDeep packet inspection
   4. DEncrypting disks twice
   Show answer

   B. No control is perfect. Layers (identity, admission, network policy, secrets, runtime detection) make a single failure survivable.

   From lesson 15 · Capstone: hardened cluster from scratch

8. Q8. Why run an attack checklist against your own cluster?

   1. ATo break it
   2. BTo prove each control actually works as intended, and find gaps before an attacker does
   3. CIt's required by Kubernetes
   4. DTo test performance
   Show answer

   B. Configuration that has never been tested often isn't doing what you think. Evidence beats assumptions.

   From lesson 15 · Capstone: hardened cluster from scratch