CKS System Hardening Practice Question
A security team wants to ensure that all containers in a pod run with only the minimum required Linux capabilities. Which of the following approaches is BEST?
⚠ Common exam trap
CNCF often tests the misconception that simply dropping all capabilities is sufficient, but the trap here is that dropping all without adding necessary ones can break the application, while adding capabilities without dropping all leaves unnecessary capabilities enabled, both of which fail the 'minimum required' requirement.
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
✓
Set securityContext.capabilities.drop: ['ALL'] and add only necessary capabilities
It implements the principle of least privilege by first dropping all capabilities with `drop: ['ALL']` and then explicitly adding back only those capabilities that are strictly necessary for the container to function. This ensures that the container runs with the absolute minimum set of Linux capabilities, reducing the attack surface and adhering to Kubernetes security best practices for system hardening.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Set securityContext.capabilities.drop: ['ALL'] with no add
Why it's wrong here
Dropping all capabilities without adding any may cause the containerized application to fail at startup or during operation if it requires capabilities such as NET_BIND_SERVICE to bind to privileged ports below 1024. While this configuration does minimize the attack surface, it is an incomplete hardening measure because it ignores the application's runtime requirements. Correct security posture drops all default capabilities and then explicitly adds back only the minimal set required, ensuring both functionality and least privilege.
- ✗
Leave capabilities unset to use the default set
Why it's wrong here
Leaving capabilities unset means the container inherits the default capability set provided by the container runtime, which typically includes CHOWN, DAC_OVERRIDE, FOWNER, FSETID, KILL, NET_BIND_SERVICE, SETFCAP, SETGID, SETUID, and SYS_CHROOT. This broad set grants far more privileges than most workloads need, unnecessarily increasing the risk of privilege escalation if an attacker compromises the container. A hardened configuration must explicitly drop these defaults and add back only the specific capabilities the process actually relies on.
- ✗
Add only the necessary capabilities without dropping
Why it's wrong here
Adding only the necessary capabilities without first dropping the defaults is counterproductive because the container retains its entire default capability set in addition to the newly added ones. This results in a larger aggregate privilege set than the original, directly expanding the attack surface and violating the principle of least privilege. Secure capability management requires a two-step process: drop all capabilities to establish a clean baseline, then selectively add back only the essential ones, ensuring no unnecessary privileges persist.
- ✓
Set securityContext.capabilities.drop: ['ALL'] and add only necessary capabilities
Why this is correct
Setting securityContext.capabilities.drop to ALL and then adding only the required capabilities is the correct hardening approach because it starts with zero capabilities, eliminating every default privilege that could be exploited. By explicitly adding back only the specific capabilities needed for the application to function—such as NET_BIND_SERVICE or SYS_TIME—the container runs with the absolute minimum privilege necessary. This reduces the potential impact of a container breakout and adheres to the security principle of least privilege.
Go deeper
Related to this question
Learn chapter
Kubernetes Security Fundamentals
Key term
Seccomp Profiles
Seccomp profiles are security filters that restrict which system calls a containerized application can make to the Linux kernel, reducing the attack surface.
Key term
Service Account Hardening
Service Account Hardening is the set of security practices to restrict and protect Kubernetes service accounts from unauthorized access or misuse.
About these practice questions
One of 114 original CKS practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. 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.