CKS System Hardening Practice Question
Which THREE of the following are restrictions enforced by the 'baseline' Pod Security Standard? (Select three.)
⚠ Common exam trap
The CKS exam often tests the distinction between baseline and restricted profiles, and the trap here is that candidates confuse the baseline's capability restriction (which only blocks dangerous capabilities, not all) with the restricted profile's stricter requirement to drop all capabilities.
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
✓
Host network access (hostNetwork) is not allowed
The 'baseline' Pod Security Standard (PSS) enforces several restrictions to provide a reasonable level of security without breaking most workloads. The three correct restrictions are: - A: Host network access (hostNetwork) is not allowed. The baseline profile prohibits sharing host namespaces, including hostNetwork, to isolate pods from the host network. - B: Capabilities must be limited to a minimal set. While the baseline profile does not require dropping all capabilities (drop: ["ALL"]), it prohibits adding dangerous capabilities such as CAP_SYS_ADMIN, CAP_NET_RAW, or CAP_SYS_PTRACE. This prevents escalation of privileges through capability misuse. - D: Privilege escalation must be disabled (AllowPrivilegeEscalation: false). This is a baseline requirement to prevent processes from gaining more privileges than their parent. Option C (seccomp profile must be set to RuntimeDefault or Localhost) and Option E (containers must run as non‑root) are both requirements of the 'restricted' profile, not the baseline. Therefore, they are incorrect selections.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Host network access (hostNetwork) is not allowed
Why this is correct
The baseline profile explicitly forbids setting hostNetwork: true, which would place the pod in the host's network namespace and expose all physical network interfaces. This isolation ensures that processes in containers cannot bind to host ports or sniff/monitor host traffic, providing a hard boundary between the pod and the underlying host. Enabling hostPID or hostIPC is also forbidden, but hostNetwork is specifically called out in the option.
- ✓
Capabilities must be limited to a minimal set (drop: ["ALL"] is not required but must not add dangerous capabilities)
Why this is correct
Baseline does not demand a full drop of all Linux capabilities—that stronger requirement is part of the restricted profile. Instead, baseline requires that any capabilities added to a container must be from a predefined default set, and it explicitly prohibits dangerous capabilities like CAP_SYS_ADMIN and CAP_NET_ADMIN. While dropping all capabilities is a sound hardening practice, the rule for baseline is about not adding beyond the allowed set, not necessarily starting from zero.
- ✗
Seccomp profile must be set to RuntimeDefault or Localhost
Why it's wrong here
Seccomp profile configuration is a restricted-profile control, not a baseline one. Baseline allows seccomp to be unset or default, while restricted requires the pod/container seccomp profile to be RuntimeDefault or Localhost unless an annotation exempts it. Because the question asks about baseline restrictions, requiring RuntimeDefault/Localhost is an overstatement that does not apply at the baseline level.
- ✓
Privilege escalation must be disabled (AllowPrivilegeEscalation: false)
Why this is correct
AllowPrivilegeEscalation: false is a baseline profile requirement that prevents a container process from gaining more privileges than its parent process, such as through setuid or setgid binaries or supplementary capabilities. Because escalation can bypass other security controls, the baseline pod security policy requires this field to be false to prevent breakouts. Note that this is distinct from simply disallowing root; a root process without escalation is still allowed under baseline.
- ✗
Containers must run as non-root (runAsNonRoot: true)
Why it's wrong here
Under the Pod Security Standards baseline profile, containers are not required to run as a non-root user; the baseline permits root UIDs as long as privileged containers are disallowed and other restrictions are met. The runAsNonRoot: true constraint is part of the more restrictive 'restricted' profile, which forces the container's user to be a non-zero UID and requires additional hardening. Therefore, marking this as a baseline requirement is incorrect because a workload may legitimately run as root under baseline.
Visual reference
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.