CKS System Hardening Practice Question
Which of the following correctly adds the NET_ADMIN capability to a container in a Kubernetes pod?
⚠ Common exam trap
The correct Kubernetes syntax for adding capabilities is `add` in the container's `securityContext`. A common pitfall is using `cap_add` (Docker Compose syntax) or attempting to place `capabilities` under the pod-level `securityContext`, which is not supported.
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: add: - NET_ADMIN
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.
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: cap_add: - ALL
Why it's wrong here
This configuration uses `cap_add`, which is a Docker Compose field and not a recognized key in a Kubernetes securityContext. If a developer mistakenly used it in Kubernetes, the API server would reject the manifest, but the intent to add `ALL` is also dangerous: it would grant every Linux capability, effectively giving the container root-like privileges and defeating the principle of least privilege. Even if the syntax were corrected to `add`, specifying `ALL` is much broader than the requested `NET_ADMIN` and introduces unnecessary security risk.
- ✓
securityContext: capabilities: add: - NET_ADMIN
Why this is correct
This is the correct Kubernetes syntax: the container-level securityContext contains a `capabilities` field with an `add` list. The key `add` is part of the Kubernetes API and instructs the container runtime to grant the specified Linux capabilities to the container's processes. Here, `NET_ADMIN` enables administrative operations on network devices and settings, which is a common requirement for networking containers. Placing this securityContext at the container level is also required for it to take effect.
- ✗
securityContext: capabilities: cap_add: - NET_ADMIN (but placed at pod spec level)
Why it's wrong here
Placing a capabilities block in the pod-level securityContext is invalid because Kubernetes only defines the `capabilities` field under a container's securityContext. Even if the YAML were moved to a container, the `cap_add` key is not recognized by Kubernetes; the correct key is `add`. This configuration would be rejected by the API server, and even with a custom admission controller it would not map to a Linux capability. The NET_ADMIN capability, if actually intended, must be added inside the container-level securityContext using `add: [NET_ADMIN]`.
- ✗
securityContext: capabilities: cap_add: - NET_ADMIN
Why it's wrong here
This option is still incorrect because `cap_add` is not a valid key in a Kubernetes securityContext; the API expects `add` (and optionally `drop`) inside a `capabilities` object. Even though this securityContext may be placed at the container level, the unrecognized field would cause a validation error, and no capability would actually be added in a running pod. The correct declaration would be `capabilities: { add: [NET_ADMIN] }` to achieve the intended effect.
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 →
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.