CKS System Hardening Practice Question
Exhibit
Refer to the exhibit.
```
apiVersion: v1
kind: Pod
metadata:
name: test-pod
spec:
containers:
- name: test
image: alpine
securityContext:
runAsUser: 1000
runAsGroup: 3000
allowPrivilegeEscalation: false
capabilities:
drop: ["ALL"]
```A pod manifest is shown. What security issue remains in this configuration?
⚠ Common exam trap
Candidates often assume the default security context is secure, but CNCF tests the specific omission of `readOnlyRootFilesystem: true` as a distinct hardening requirement, even when other settings like `runAsNonRoot: true` are present.
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 a writable root filesystem
The pod manifest does not set `readOnlyRootFilesystem: true` in the container's security context. Without this setting, the container's root filesystem is writable by default, allowing an attacker who compromises the container to modify binaries, configuration files, or write malicious scripts to persistent storage, thereby increasing the attack surface and potentially enabling persistence or privilege escalation.
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 runs as root (user 0)
Why it's wrong here
If the manifest already specifies runAsUser with a non-zero UID, or runAsNonRoot true, the container does not run as root, so this is not the remaining issue. It is tempting because running as UID 0 is a real finding whenever no runAsUser or runAsNonRoot constraint is declared.
- ✓
The container has a writable root filesystem
Why this is correct
Without readOnlyRootFilesystem set to true in the container's securityContext, the container can write to its root filesystem. This leaves the pod able to modify its own image layers, which is the remaining security issue in the manifest.
- ✗
The container has dangerous capabilities
Why it's wrong here
If the manifest already drops ALL capabilities, or adds only benign ones such as NET_BIND_SERVICE, no dangerous capability remains, so this is not the issue. It is tempting because CAP_SYS_ADMIN or added capabilities genuinely constitute a finding when the securityContext leaves them in place.
- ✗
The container can escalate privileges
Why it's wrong here
Privilege escalation via allowPrivilegeEscalation governs setuid binaries and file capabilities inside the container, not the manifest's actual gap. It tempts because that field is the standard hardening control when a container runs as non-root yet retains capabilities. Here the manifest already sets it false, so the residual issue lies elsewhere.
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.