GSEC Container Security Practice Question
A GSEC consultant is hardening a Kubernetes cluster that runs multi-tenant workloads. A developer reports that a pod in the tenants namespace was able to read the contents of the kubelet's host filesystem at /var/lib/kubelet. The pod spec includes hostPath: {path: /var/lib/kubelet, type: Directory} under volumes and mounts it at /host. The cluster has Pod Security Admission enabled with the restricted profile enforced cluster-wide, but the tenants namespace was labeled pod-security.kubernetes.io/enforce: privileged to unblock a legacy job. Which action most directly closes this exposure?
⚠ Common exam trap
The trap here is focusing on pod-level runtime hardening such as seccomp or privilege-escalation flags, when the actual enabler was a namespace-level admission exemption that permitted the hostPath mount in the first place.
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
✓
Remove the privileged label from the tenants namespace so the restricted profile is enforced there, and refactor the legacy job to run without a hostPath mount.
Pod Security Admission decides admission based on the namespace's pod-security.kubernetes.io/enforce label, and the privileged value on the tenants namespace overrode the cluster-wide restricted profile. That exemption is precisely what let a pod mount the node's /var/lib/kubelet directory via hostPath. Removing the label restores restricted enforcement, which forbids hostPath volumes, and refactoring the legacy job removes the need for the exemption so the exposure cannot be recreated.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Enable the NodeRestriction admission plugin and rotate the kubelet client certificates on all worker nodes.
Why it's wrong here
NodeRestriction limits what a kubelet can modify in the API, and certificate rotation hardens node identity, but neither affects whether a pod may mount a hostPath volume. The pod would continue to read /var/lib/kubelet because the mount is permitted by the namespace's privileged enforcement label. This option addresses node-to-API authorization, which is unrelated to the described filesystem exposure.
- ✗
Add a seccomp profile of RuntimeDefault to the pod and set allowPrivilegeEscalation to false in its securityContext.
Why it's wrong here
These runtime hardening settings limit syscall exposure and privilege escalation, but they do not prevent the hostPath volume from being mounted. The pod would still see the node's kubelet directory, and the restricted profile already requires these settings anyway, so the exposure persists. The real enabler is the permissive namespace label combined with the hostPath volume, neither of which this option changes.
- ✗
Create an OPA Gatekeeper constraint that denies pods whose namespaces carry the privileged enforcement label.
Why it's wrong here
Denying the label is a convoluted workaround that leaves the namespace's enforcement posture ambiguous and can break other workloads that legitimately need the exemption. It also does not remove the existing hostPath volume from the running pod or prevent the legacy job from being re-admitted under a different namespace. The straightforward fix is to remove the exemption and eliminate the hostPath mount, not to build a policy around the exemption.
- ✓
Remove the privileged label from the tenants namespace so the restricted profile is enforced there, and refactor the legacy job to run without a hostPath mount.
Why this is correct
The hostPath volume is what exposes the node's kubelet directory to the pod, and the namespace's privileged enforcement label is what allowed that volume to be admitted despite the cluster-wide restricted profile. Restoring restricted enforcement blocks hostPath volumes entirely and forces the legacy job to be reworked, directly removing the pod's ability to read node files. The other options leave the mount or the permissive label in place.
About these practice questions
Courseiva writes every GSEC question from scratch — 351 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 and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official GIAC exam blueprint
This GSEC practice question is part of Courseiva's free GIAC 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 GSEC exam.