CKS Minimize Microservice Vulnerabilities Practice Question
A security engineer runs the following command to inspect a pod's security context:
kubectl get pod secure-pod -o jsonpath='{.spec.containers[0].securityContext.capabilities}'The output is: {"drop":["ALL"]}
What does this indicate?
⚠ Common exam trap
The CKS exam often tests the misconception that the `drop` field is invalid or that dropping all capabilities leaves some capabilities intact, when in fact `drop:["ALL"]` is a valid and restrictive configuration that removes every Linux capability.
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
✓
The container has all Linux capabilities dropped
The output `{"drop":["ALL"]}` indicates that the container's security context explicitly drops all Linux capabilities via the `drop` field. This is a common security hardening practice to reduce the attack surface by removing all privileged operations, such as `CAP_NET_ADMIN` or `CAP_SYS_ADMIN`, from the container's effective 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.
- ✓
The container has all Linux capabilities dropped
Why this is correct
The capabilities field shows drop: ["ALL"], meaning every Linux capability is removed from the container's effective, permitted and inheritable sets. The container therefore runs with no capabilities, which is the hardened posture the security engineer intended to verify.
- ✗
The output is invalid because capabilities should be in add field
Why it's wrong here
The output is valid: capabilities accepts both add and drop keys, and drop:["ALL"] is a legitimate, common configuration. It is tempting because add is the field most often seen in examples, so a drop-only result can look malformed — yet dropping all capabilities is exactly the hardened posture this scenario demonstrates.
- ✗
The container has no capability restrictions
Why it's wrong here
Dropping ALL capabilities removes every Linux capability from the container, which is the strongest restriction, not an absence of restrictions. It is tempting because an empty capabilities block would indicate no explicit policy, but here the drop list is populated, so the container runs with none.
- ✗
The container has only the NET_ADMIN capability added
Why it's wrong here
The jsonpath output shows only a drop list containing ALL, with no add field present, so no capabilities are added. It is tempting because NET_ADMIN is a common capability granted via the add field, which would appear as {"add":["NET_ADMIN"]} — the correct choice when a container genuinely needs that specific capability.
Go deeper
Related to this question
About these practice questions
Courseiva writes every CKS question from scratch — 845 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or 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.