CKS: Certified Kubernetes Security Specialist Practice Exam

What the CKS exam covers

• Cluster Setup65 questions
• Cluster Hardening83 questions
• System Hardening73 questions
• Minimize Microservice Vulnerabilities80 questions
• Supply Chain Security75 questions
• Monitoring, Logging and Runtime Security74 questions

Free CKS sample questions

A sample of 10 questions with answers and explanations. Sign up free to practice all 450.

1. Question 1Supply Chain SecuritySelect all that apply

   Which TWO controls together provide defense-in-depth for image trust from build to runtime? (Choose TWO)

   • AContinuously scan images (build, registry, and running) and gate on severityCorrect
   • BStop monitoring once images are signed
   • CAllow unsigned images if they're internal
   • Dsign images at build and verify signature/identity at admissionCorrect
   ✓ Correct answer: A, D

   sign images at build and verify signature/identity at admission Defense-in-depth for the software supply chain layers complementary controls so a weakness in one does not break the whole chain. Continuous vulnerability scanning at build, in the registry, and against running workloads catches CVEs that appear or are disclosed after an image was first pushed, and severity gating blocks deployment of images with critical findings. Signing images at build time and verifying the signature and signer identity at admission (for example with Cosign and a policy controller such as Kyverno, Connaisseur, or sigstore policy-controller) guarantees provenance and integrity so only trusted, untampered images run. Together, scanning addresses content quality while signing addresses authenticity and integrity, covering both 'is it safe?' and 'is it really ours?'.

   Why the other options are wrong

   • BStop monitoring once images are signed is incorrect because a signature only attests to provenance and integrity at signing time; it does not detect vulnerabilities discovered later, so ongoing scanning and runtime monitoring must continue.
   • CAllow unsigned images if they're internal is incorrect because exempting internal images from signature verification creates a trust gap that an attacker who compromises the build pipeline or registry can exploit to inject unsigned malicious images.
2. Question 2Monitoring, Logging and Runtime Security

   A Falco rule should fire when a package manager (apt, yum) runs inside a running container. Which Falco construct best expresses 'these are the package-manager binaries'?

   • AA NetworkPolicy egress list
   • BAn audit policy omitStages entry
   • CA securityContext capability list
   • DA list of binary names referenced by a macro/condition in the ruleCorrect
   ✓ Correct answer: D

   In Falco, a list is a named collection of values, making it the idiomatic way to enumerate package-manager binaries such as apt, apt-get, yum, dnf, and rpm. The rule's condition (often via a macro) then tests whether the executed process name is in that list, for example proc.name in (package_mgmt_binaries), and fires when a package manager runs inside a running container. This separation keeps the list of binaries easy to maintain independently of the rule logic.

   Why the other options are wrong

   • AA NetworkPolicy egress list is incorrect because NetworkPolicy egress rules filter network destinations, not process or binary names, and are unrelated to Falco.
   • BAn audit policy omitStages entry is incorrect because omitStages controls which API request stages the audit log skips, not which binaries Falco matches.
   • CA securityContext capability list is incorrect because capability lists add or drop Linux capabilities on a container and cannot express runtime detection of which binaries are executing.
3. Question 3Monitoring, Logging and Runtime SecuritySelect all that apply

   To retain API audit logs safely and bound disk usage with the file backend, which TWO kube-apiserver flags apply? (Choose TWO)

   • A--audit-log-maxage (days to retain)Correct
   • B--audit-log-compress-level=9
   • C--audit-log-maxbackup (number of rotated files to keep)Correct
   • D--audit-retention=forever
   ✓ Correct answer: A, C

   --audit-log-maxbackup (number of rotated files to keep) The kube-apiserver file backend includes built-in log rotation and retention controls. --audit-log-maxage sets the maximum number of days to retain old rotated audit log files, bounding how long data is kept. --audit-log-maxbackup sets the maximum number of rotated log files to keep, bounding total disk usage; together with --audit-log-maxsize they manage rotation safely so audit data is retained without filling the disk.

   Why the other options are wrong

   • B--audit-log-compress-level=9 is incorrect because there is no such flag; compression of rotated files is toggled by --audit-log-compress (a boolean), with no configurable level flag.
   • D--audit-retention=forever is incorrect because no --audit-retention flag exists, and retention is expressed via maxage/maxbackup/maxsize, not an unbounded 'forever' value.
4. Question 4Monitoring, Logging and Runtime Security

   Falco can capture syscalls via different drivers. Which statement is accurate?

   • AFalco can use a kernel module or a (modern) eBPF probe to source syscall eventsCorrect
   • BFalco requires modifying each container image
   • CFalco uses a NetworkPolicy to capture syscalls
   • DFalco only works by parsing the API server audit log
   ✓ Correct answer: A

   Falco needs visibility into kernel syscalls, and it obtains this through a driver. Historically this was a loadable kernel module, and modern deployments commonly use an eBPF probe (including a CO-RE / modern eBPF option) that runs in the kernel without a custom module. Either driver feeds the same userspace engine that evaluates the rules, so the choice of driver is about how syscalls are captured, not what is detected.

   Why the other options are wrong

   • BFalco requires modifying each container image is incorrect because Falco observes the host kernel from a node-level agent and needs no changes to application images.
   • CFalco uses a NetworkPolicy to capture syscalls is incorrect because NetworkPolicy filters pod network traffic and has no ability to capture syscalls.
   • DFalco only works by parsing the API server audit log is incorrect because Falco's primary source is kernel syscall events via its driver; it can optionally consume Kubernetes audit events as a plugin but is not limited to them.
5. Question 5Monitoring, Logging and Runtime Security

   You want to build a seccomp allowlist by first OBSERVING which syscalls an app uses, without blocking it. Which seccomp action supports this 'audit' approach?

   • ASCMP_ACT_LOG (logs syscalls instead of denying), to learn the profile before switching to SCMP_ACT_ERRNOCorrect
   • BSCMP_ACT_TRAP only
   • CSCMP_ACT_ALLOW with no logging
   • DSCMP_ACT_KILL for everything
   ✓ Correct answer: A

   SCMP_ACT_LOG permits the syscall to proceed but writes a kernel log entry recording it, which lets you observe the complete set of syscalls an application actually makes without breaking it. By setting the profile's defaultAction (or specific rules) to SCMP_ACT_LOG and collecting the logged syscalls, you can build an accurate allowlist and then tighten the profile by switching the default to SCMP_ACT_ERRNO to deny everything not explicitly allowed. This audit-first workflow is the recommended way to author least-privilege seccomp profiles.

   Why the other options are wrong

   • BSCMP_ACT_TRAP only is incorrect because SCMP_ACT_TRAP sends a SIGSYS signal that typically terminates the offending thread/process, so it blocks rather than passively observing.
   • CSCMP_ACT_ALLOW with no logging is incorrect because it permits syscalls silently and produces no record, giving you no data from which to learn the profile.
   • DSCMP_ACT_KILL for everything is incorrect because it terminates the process on a disallowed syscall, which blocks the app rather than observing its behavior.
6. Question 6Monitoring, Logging and Runtime Security

   Which runtime behavior would a Falco rule flag as a likely reverse shell from a container?

   • AA readiness probe succeeding
   • BA shell process with its stdin/stdout redirected to an outbound network socketCorrect
   • CA ConfigMap being mounted
   • DA container being scheduled
   ✓ Correct answer: B

   A classic reverse shell pattern is a shell (such as bash or sh) whose standard input and output file descriptors are wired to a network socket connecting outbound to an attacker. Falco can detect this by matching on a shell process whose stdin/stdout point at an outbound connection (its built-in reverse-shell rules inspect fd types and process lineage). This behavior is highly anomalous for normal containers and is a strong compromise indicator.

   Why the other options are wrong

   • AA readiness probe succeeding is incorrect because a healthy probe is normal lifecycle behavior with no relation to attacker-controlled I/O redirection.
   • CA ConfigMap being mounted is incorrect because mounting configuration is a routine, expected operation and does not involve a shell bound to a network socket.
   • DA container being scheduled is incorrect because scheduling is a normal control-plane action and exhibits none of the syscall/socket characteristics of a reverse shell.
7. Question 7Monitoring, Logging and Runtime Security

   An attacker with node access might delete local audit logs to hide activity. Which design choice best counters this?

   • ARotate logs every minute and discard old ones
   • BDisable auditing to avoid tampering
   • Cship audit events off-node in real time to an append-only/immutable store (e.g., via the webhook backend to a SIEM)Correct
   • DKeep audit logs only on the node with 777 permissions
   ✓ Correct answer: C

   If audit events are streamed off the node as they occur, typically through the apiserver's webhook audit backend to a SIEM or immutable/WORM store, an attacker who later gains node access cannot retroactively erase the already-shipped evidence. Real-time export to tamper-resistant storage breaks the dependency on local files that an intruder could delete. This preserves a reliable forensic record despite node compromise.

   Why the other options are wrong

   • ARotate logs every minute and discard old ones is incorrect because aggressive rotation that discards data actually destroys evidence faster and still leaves it locally deletable.
   • BDisable auditing to avoid tampering is incorrect because turning off auditing removes the security record entirely, the opposite of preserving evidence.
   • DKeep audit logs only on the node with 777 permissions is incorrect because world-writable, node-local logs are trivially modified or deleted by an attacker, maximizing rather than countering tampering risk.
8. Question 8Monitoring, Logging and Runtime Security

   How do you override a built-in Falco rule's behavior (e.g., raise its priority) without editing the shipped file?

   • ARules can't be overridden once shipped
   • BDelete the Falco binary and recompile
   • CSet an annotation on the pod
   • DRedefine a rule with the same name in a custom rules file loaded AFTER the defaults (last definition wins)Correct
   ✓ Correct answer: D

   Falco loads rules files in the order listed in falco.yaml, and when two rules share the same name, the last one parsed takes precedence and fully replaces the earlier definition. By keeping the shipped default rules file untouched and adding your own file later in the load order that redefines the rule with the same name, you can change its condition, output, or priority without modifying vendor-supplied content. This keeps upgrades clean because the shipped file can be replaced wholesale while your overrides persist in a separate file. Falco also supports append: true to extend a rule's condition rather than fully replacing it.

   Why the other options are wrong

   • ARules can't be overridden once shipped is incorrect because Falco is explicitly designed for overriding and appending to rules via load order and the append keyword.
   • BDelete the Falco binary and recompile is incorrect because rule behavior is defined in YAML configuration, not compiled into the binary, so recompilation is unnecessary and ineffective.
   • CSet an annotation on the pod is incorrect because Falco evaluates kernel syscalls and rule files, and pod annotations have no influence on which rules fire or their priority.
9. Question 9Monitoring, Logging and Runtime Security

   Which audit-log pattern could indicate an attacker cleaning up after themselves?

   • Aunexpected delete operations on Secrets, pods, or audit/log resources by an unusual identityCorrect
   • BRoutine node heartbeats
   • CA controller listing pods
   • DA user reading their own ConfigMap
   ✓ Correct answer: A

   After achieving their objective, attackers frequently attempt to destroy evidence by deleting Secrets they exfiltrated, removing pods they used as a foothold, or wiping logging-related resources to frustrate investigation. In the audit log this shows as delete verbs on sensitive resources performed by an identity that does not normally perform such deletions. Correlating the actor, resource, and timing distinguishes malicious cleanup from legitimate administrative housekeeping. This anti-forensic pattern is a strong indicator that a compromise is being actively concealed.

   Why the other options are wrong

   • BRoutine node heartbeats is incorrect because heartbeats are periodic status updates from kubelets and represent normal, expected baseline activity.
   • CA controller listing pods is incorrect because controllers continuously watch and list resources to reconcile state, which is benign read traffic.
   • DA user reading their own ConfigMap is incorrect because a get on a ConfigMap the user is authorized for is a routine read that destroys no evidence.
10. Question 10Monitoring, Logging and Runtime Security

    A container process truncates /var/log files or clears shell history. What does this most likely indicate?

    • ARoutine log rotation
    • BA normal health check
    • CAnti-forensics / log tampering — an attacker covering tracks, worth a runtime alertCorrect
    • DA scheduled backup
    ✓ Correct answer: C

    A container process that truncates files under /var/log or clears shell history is exhibiting classic anti-forensic behavior aimed at erasing evidence of intrusion. Legitimate applications rarely wipe system logs or command history themselves, so a runtime tool observing these file-truncation and history-clearing syscalls should raise an alert. Catching this activity helps preserve the remaining audit trail and indicates an active attacker attempting to evade detection. It is a strong behavioral indicator of compromise rather than routine maintenance.

    Why the other options are wrong

    • ARoutine log rotation is incorrect because log rotation is normally handled by dedicated tooling (logrotate or the runtime) that archives logs rather than a container process abruptly truncating them or clearing history.
    • BA normal health check is incorrect because health checks probe application readiness/liveness and never truncate logs or wipe shell history.
    • DA scheduled backup is incorrect because backups copy and preserve data, the opposite of destructively truncating logs and clearing history.

CKS practice exam FAQ