CKS Minimize Microservice Vulnerabilities Practice Question
Network Topology
A security engineer runs the following command to inspect a container's security context. What vulnerability does this configuration expose?
⚠ Common exam trap
CNCF often tests the distinction between 'default Docker capabilities' (which are secure and limited) and 'all capabilities' (which is a severe vulnerability), and the trap here is that candidates may confuse 'all capabilities' with the default set or think that dropping all capabilities is the only insecure state.
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 capabilities enabled, which is a security risk
The command `docker run --privileged` or a similar configuration that grants all capabilities (e.g., `--cap-add=ALL`) removes all kernel-level isolation, giving the container full access to the host's kernel capabilities. This means the container can perform privileged operations like loading kernel modules, modifying network settings, and accessing raw devices, which directly violates the principle of least privilege and exposes the host to container breakout attacks.
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 is running without any capabilities
Why it's wrong here
The command output shows a non-zero CapEff bitmask with many capability bits set. A process with no capabilities would report CapEff as 0x0, but here the effective set grants the container process numerous privileged operations. The presence of these bits directly refutes the claim that the container is running capability-less.
- ✓
The container has all capabilities enabled, which is a security risk
Why this is correct
The CapEff value is a full mask, meaning every capability supported by the kernel is present in the container process's effective set. With all capabilities, the process can invoke privileged syscalls such as mount(), ptrace(), and operations guarded by CAP_SYS_ADMIN, essentially matching root on the host for capability-restricted actions. This dramatically increases the host attack surface if the container is compromised, so the configuration is a significant security risk.
- ✗
The container has dropped all capabilities except NET_BIND_SERVICE
Why it's wrong here
If only CAP_NET_BIND_SERVICE were retained, the CapEff bitmask would contain exactly one bit set (bit 10, corresponding to the value 0x400). The observed mask is far broader than a single bit, so the container retains many other capabilities. Dropping to that single capability would be a restrictive posture, but it is not what the data shows.
- ✗
The container has default Docker capabilities, which is secure
Why it's wrong here
Docker's default container capability set is a curated subset, typically around 14 capabilities such as CHOWN, DAC_OVERRIDE, NET_RAW, and SETUID, and excludes dangerous ones like SYS_ADMIN and SYS_MODULE. The provided CapEff mask includes all capability bits, not just that allowed default subset. Therefore claiming it is a secure default is incorrect; the mask must equal Docker's default list, which it does not.
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.