CKS Minimize Microservice Vulnerabilities Practice Question
A security scanner reports that a microservice container image contains a critical vulnerability (CVE-2024-1234) in a system library. The team cannot immediately rebuild the image. What is the most effective temporary mitigation at the Kubernetes level?
⚠ Common exam trap
CNCF often tests the distinction between seccomp (syscall filtering) and AppArmor/SELinux (MAC on files and capabilities), leading candidates to confuse AppArmor as a syscall blocker when it is not.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Apply a custom seccomp profile that blocks the vulnerable syscall
A custom seccomp (secure computing mode) profile can restrict the system calls (syscalls) a container is allowed to make. By blocking the specific vulnerable syscall exploited by CVE-2024-1234, you can prevent the vulnerability from being triggered at runtime without rebuilding the image. This is a temporary, Kubernetes-native mitigation that directly addresses the attack vector at the syscall level.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Apply a NetworkPolicy to block egress traffic from the Pod
Why it's wrong here
A NetworkPolicy governs network flow at L3/L4 and cannot restrict the syscalls a container process can invoke. A vulnerable system library is present in the image and executes locally; even blocking all egress, an attacker who compromises the container can still trigger the syscall inside the Pod. Therefore it does not address the reported library vulnerability.
- ✓
Apply a custom seccomp profile that blocks the vulnerable syscall
Why this is correct
A custom seccomp profile restricts the set of syscalls a process may make, and if the scanner mapped the library CVE to a specific syscall, denying that syscall creates a direct mitigation at the kernel boundary. Even when the vulnerable library remains in the image, the exploit cannot complete because the necessary syscall is rejected with EPERM. This is the only option that acts directly on syscall invocation.
- ✗
Apply an AppArmor profile to the Pod
Why it's wrong here
AppArmor is a mandatory access control LSM that constrains file paths, capabilities, and network access but does not provide fine-grained syscall filtering. Many syscalls tied to library CVEs require no file access, so an AppArmor profile may allow the vulnerable call. Unlike seccomp, it cannot reliably block the specific syscall by number, making it an incomplete fix.
- ✗
Use a PodSecurityPolicy to drop all capabilities
Why it's wrong here
PodSecurityPolicy, deprecated and removed in Kubernetes 1.25, controls security context features such as capabilities, but capabilities are privilege flags, not syscall denylists. A system library CVE is often exploitable through an unprivileged syscall, so dropping all capabilities leaves the vulnerable syscall available. The legacy PSP mechanism also cannot be applied on modern clusters and is not a syscall mitigation.
Go deeper
Related to this question
About these practice questions
This CKS question is part of Courseiva's 845-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This CKS practice question is part of Courseiva's free CNCF certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the CKS exam.