CV0-004 Security Practice Question
A cloud administrator is deploying a new containerized workload on Google Kubernetes Engine in Google Cloud. The security team requires that the containers run with a non-root user, have a read-only root filesystem where possible, and are prevented from gaining additional Linux capabilities. Which GKE feature should the administrator enable to enforce these restrictions at the pod level?
⚠ Common exam trap
The trap here is selecting a node-hardening or image-provenance feature when the requirement is specifically about runtime pod security context enforcement.
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
✓
Pod Security Admission with the restricted profile
Pod Security Admission with the restricted profile enforces the exact pod-level controls requested: non-root execution, disallowing privilege escalation, dropping Linux capabilities, and requiring stricter seccomp and filesystem settings. Enabling it on the namespace applies the policy consistently across the workload.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Pod Security Admission with the restricted profile
Why this is correct
Pod Security Admission with the restricted profile enforces hardened pod settings, including running as non-root, disallowing privilege escalation, dropping capabilities, and requiring a seccomp profile. Applying it at the namespace level ensures every pod meets the security team's baseline. It directly maps to the non-root, read-only, and no-new-capabilities requirements.
- ✗
Shielded GKE Nodes
Why it's wrong here
Shielded GKE Nodes use secure boot, vTPM, and integrity monitoring to protect node boot and verify node identity. This hardens the underlying VM, not the pod specification. It does not enforce non-root users, read-only root filesystems, or capability restrictions inside containers, so it does not meet the stated pod-level requirements.
- ✗
Binary Authorization
Why it's wrong here
Binary Authorization ensures only container images signed by trusted attestors are deployed to the cluster. It governs image provenance, not runtime pod configuration such as user ID, filesystem mount mode, or Linux capabilities. It complements, but does not replace, pod security controls that restrict how a container runs.
- ✗
Network Policy in GKE
Why it's wrong here
Network Policy controls which pods can communicate with each other and with external endpoints. It operates at layers 3 and 4 and has no bearing on whether a container runs as root or can escalate privileges. While valuable for segmentation, it does not enforce the pod-level security context settings the team requires.
Go deeper
Related to this question
About these practice questions
Courseiva writes every CV0-004 question from scratch — 834 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 CompTIA exam blueprint
This CV0-004 practice question is part of Courseiva's free CompTIA 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 CV0-004 exam.