CKS System Hardening Practice Question
What is the effect of setting 'hostPID: true' in a pod's spec?
⚠ Common exam trap
CNCF often tests the distinction between the three host namespace settings (hostPID, hostIPC, hostNetwork) and candidates frequently confuse 'hostPID' with 'hostNetwork' or 'hostIPC' due to similar naming patterns.
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 runs in the host's PID namespace.
Setting 'hostPID: true' in a pod's spec allows the container to share the host node's PID namespace, meaning the container can see and interact with all processes running on the host, not just those within its own PID namespace. This is a privileged-level setting that bypasses the default process isolation provided by Kubernetes and Linux namespaces.
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 with the host's IPC namespace.
Why it's wrong here
The container runs with the host's IPC namespace. This is incorrect because that behavior is controlled by hostIPC: true, not hostPID. The IPC namespace governs System V IPC and POSIX message queues, not process tables. Setting hostPID: true leaves the IPC namespace untouched, so inter-process communication remains isolated within the pod unless hostIPC is explicitly enabled. This option describes a completely different field from the one in question.
- ✗
The container can access the host's network interfaces.
Why it's wrong here
The container can access the host's network interfaces. This is incorrect because hostPID: true only shares the PID namespace; network access is determined by the network namespace configured via hostNetwork: true. Without hostNetwork, the container retains a virtual network interface and cannot see the host's IP addresses, routing table, or network sockets. Hence, this option incorrectly implies a network capability that hostPID does not provide.
- ✗
The container can mount the host's filesystem.
Why it's wrong here
The container can mount the host's filesystem. This is incorrect: sharing the PID namespace does not grant filesystem access. Mounting the host filesystem requires an explicit volume definition such as hostPath with the appropriate mountPath and read/write permissions. hostPID only changes process visibility, not what filesystems are mounted inside the container. The container still gets its usual root filesystem and any volumes declared in the pod spec.
- ✓
The container runs in the host's PID namespace.
Why this is correct
The container runs in the host's PID namespace. This is correct because when hostPID: true is set, the container sees the exact same process list and process IDs as processes on the host, and processes inside the container are visible to all host processes. This removes process isolation, letting the container inspect or send signals (if permitted) to any host process. It effectively makes the container's own PID 1 correspond to the host's init process, so there is no separate PID namespace.
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.