CKS System Hardening Practice Question
An administrator wants to prevent a container from accessing the host's network. Which pod security context field should be set to false?
⚠ Common exam trap
CNCF often tests the distinction between `hostNetwork` and `privileged` — candidates mistakenly think that disabling `privileged` alone prevents host network access, but `privileged` controls capabilities and device access, not namespace isolation, so `hostNetwork` must be explicitly set to `false`.
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
✓
hostNetwork
The `hostNetwork` field in the Pod Security Context, when set to `true`, allows the container to use the host's network namespace directly, bypassing the pod's own network stack. Setting it to `false` (the default) ensures the container uses an isolated network namespace, preventing direct access to host network interfaces, iptables rules, and network services. This is the correct field to disable to meet the requirement of preventing container access to the host's network.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
hostIPC
Why it's wrong here
`hostIPC: false` keeps the container in its own IPC namespace, shielding it from the host's System V semaphores, message queues, and shared memory segments. However, IPC isolation is orthogonal to networking; even with `hostIPC: false`, the container still uses the normal Pod networking and can reach host network services or external IPs. Therefore, this setting does nothing to block host network access.
- ✗
privileged
Why it's wrong here
A privileged container receives all capabilities and lifts many device cgroup restrictions, effectively making it as powerful as root on the host kernel. While a privileged process could abuse raw sockets or Ptrace to pivot into network activity, the `privileged` flag itself does not attach the container to the host network namespace. Network isolation is governed by `hostNetwork`; setting `privileged: false` (or true) neither enables nor disables host network visibility.
- ✗
hostPID
Why it's wrong here
`hostPID: false` gives the container its own PID namespace so it cannot see host processes or send signals to them, which is a process-visibility control, not a network control. Even when `hostPID` is false, the container retains its Pod network identity and can initiate connections to the host or other destinations unless `networkPolicy` or `hostNetwork: false` is applied. Thus, it is irrelevant for preventing host network access.
- ✓
hostNetwork
Why this is correct
Setting `hostNetwork: false` (the default) places the container in its own network namespace with a virtual Ethernet pair, so it only sees the Pod IP and cannot bind to or sniff the host's IP addresses and ports. Without `hostNetwork: true`, the container's network stack is isolated from the host, preventing direct access to host interfaces, routes, and iptables rules. This boolean is the precise network isolation control in the Pod spec.
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.