CKS Minimize Microservice Vulnerabilities Practice Question
You need to drop all Linux capabilities from a container. Which YAML snippet is correct?
⚠ Common exam trap
CNCF often tests the distinction between `drop` and `remove` in the capabilities field, where `drop` is the correct Kubernetes API field name, and `remove` is a common but incorrect alternative that candidates might mistakenly use.
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"] } }
In Kubernetes, to drop Linux capabilities from a container, you must use the `capabilities.drop` field inside `securityContext`. Option D correctly nests `capabilities` under `securityContext`. Option B is incorrect because it places `capabilities` directly under the container spec without the `securityContext` wrapper, which is not valid in most Kubernetes API versions. Options A and C use invalid keywords (`remove` and `none`). Therefore, only Option D is correct.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
capabilities: { remove: ["ALL"] }
Why it's wrong here
The `remove` key is not part of the Kubernetes capabilities API. The only fields recognized inside `capabilities` are `add` and `drop`; `remove` is simply ignored or rejected by the schema, so it would have no effect at runtime. Use `drop: ["ALL"]` to strip capabilities.
- ✗
capabilities: { drop: ["ALL"] }
Why it's wrong here
While the inner syntax `drop: ["ALL"]` is correct, it appears at the wrong location. In Kubernetes, a container’s fields are grouped into resources, limits, and a `securityContext`; there is no top-level `capabilities` key in the container spec. The kubelet expects `securityContext.capabilities`, so without that wrapper the setting is not applied and the container will retain its default capabilities.
- ✗
capabilities: { none: true }
Why it's wrong here
Kubernetes does not define a `none` field in the capabilities specification, so `capabilities: { none: true }` is not a valid construct. Capability configuration is exclusively list-based: you explicitly list capabilities to add or drop. To remove all capabilities, you must provide a list containing `"ALL"` under `drop`.
- ✓
securityContext: { capabilities: { drop: ["ALL"] } }
Why this is correct
This is correct because the `securityContext` at the container level is the only place where Linux capabilities are configured in Kubernetes. The `capabilities.drop` list accepts `"ALL"` as a special token that removes every capability from the container's effective and permitted sets, giving a minimal attack surface. Because it is nested under `securityContext`, the kubelet applies it when creating the container via the container runtime.
Go deeper
Related to this question
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.