CKS System Hardening Practice Question
A security admin wants to drop all Linux capabilities for a container and then add only CAP_NET_BIND_SERVICE. Which YAML snippet correctly achieves this?
⚠ Common exam trap
CNCF often tests the distinction between the correct `capabilities` object syntax and the incorrect flat field names like `capDrop`/`capAdd`, and the trap is that candidates confuse `privileged: true` with a fine-grained capability control, when in fact it bypasses all capability restrictions.
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
✓
securityContext: capabilities: drop: ['ALL'] add: ['NET_BIND_SERVICE']
It uses the standard Kubernetes `securityContext.capabilities` field with `drop: ['ALL']` to remove all Linux capabilities from the container, then `add: ['NET_BIND_SERVICE']` to grant only the `CAP_NET_BIND_SERVICE` capability. This is the proper YAML syntax for the desired capability set.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
securityContext: capabilities: drop: ['ALL'] add: ['NET_BIND_SERVICE'] privileged: true
Why it's wrong here
Including privileged: true negates the capability drop and add rules because a privileged container bypasses the kernel's capability restriction mechanisms and receives all capabilities. Even though drop: ALL appears, the privileged flag overrides it, granting full root privileges on the host, so the security intent is lost. The fix is to remove privileged and keep only the capability drop/add.
- ✗
securityContext: capabilities: drop: ['NET_BIND_SERVICE'] add: ['ALL']
Why it's wrong here
This configuration reverses the intended least-privilege model: it drops only NET_BIND_SERVICE and adds ALL, meaning the container ends up with every Linux capability instead of none. If the workload requires binding to a privileged port, NET_BIND_SERVICE is the only capability needed; adding ALL exposes the container to unnecessary attack surface. The correct order is drop ALL first, then explicitly add NET_BIND_SERVICE.
- ✗
securityContext: capDrop: ['ALL'] capAdd: ['NET_BIND_SERVICE']
Why it's wrong here
Kubernetes does not recognize the keys capDrop and capAdd inside a securityContext; the proper API fields are capabilities.drop and capabilities.add. Because these fields are unknown to the API server, they are either rejected during validation or silently ignored, leaving the container with the default capability set. You must nest them under an object named capabilities.
- ✓
securityContext: capabilities: drop: ['ALL'] add: ['NET_BIND_SERVICE']
Why this is correct
This is correct because it first removes every capability from the container's permitted and effective sets, then adds back exactly one capability, NET_BIND_SERVICE, which is required to bind sockets to ports below 1024. This follows the principle of least privilege, ensuring the container only has the minimum kernel access needed. It is the standard pattern for running unprivileged containers that still need low-port binding.
Go deeper
Related to this question
About these practice questions
One of 845 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 →
Same concept, more angles
1 more way this is tested on CKS
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. Which of the following correctly adds the NET_ADMIN capability to a container in a Kubernetes pod?
medium- A.securityContext: capabilities: cap_add: - ALL
- ✓ B.securityContext: capabilities: add: - NET_ADMIN
- C.securityContext: capabilities: cap_add: - NET_ADMIN (but placed at pod spec level)
- D.securityContext: capabilities: cap_add: - NET_ADMIN
Why B: In Kubernetes, the correct field to add a Linux capability to a container is `capabilities.add` in the container's `securityContext`. Option B uses `add: - NET_ADMIN` at the container level, which is the proper syntax. Option D uses `cap_add`, which is Docker Compose syntax and invalid in Kubernetes. Option A uses `cap_add` with `ALL`, which adds all capabilities and is not specific. Option C places the `securityContext` at the pod spec level, but the pod-level `securityContext` does not support a `capabilities` field; capabilities must be set in each container's `securityContext`. Therefore, C is invalid, not just less precise.
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.