GSEC Virtualization, Cloud, and AI Essentials Practice Question
A financial services firm runs containerized workloads on a managed Kubernetes service. An auditor asks how the firm can ensure that only container images that passed its internal vulnerability scan can be deployed to the cluster. Which control should the firm implement?
⚠ Common exam trap
A common mix-up: candidates confuse image pull behavior or runtime hardening with admission control, when only an admission controller can reject a pod before it is scheduled based on image provenance.
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
✓
Enable a Kubernetes admission controller that validates image signatures or scan attestations.
Admission control is the enforcement point in Kubernetes that can evaluate an image's signature or scan attestation before a pod is scheduled. By requiring a valid signature or attestation from the internal scanner, the firm guarantees that only images that passed its process can be deployed. Network policies, pull policies, and non-root settings affect runtime behavior but not image admissibility.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Set the imagePullPolicy to Always on every container manifest.
Why it's wrong here
imagePullPolicy Always only forces the kubelet to fetch the image from the registry each time a pod starts. It does not verify that the image was scanned or approved, and an attacker could still push a malicious tag. The control affects caching behavior, not admission decisions, so it fails to meet the audit requirement.
- ✗
Configure the container runtime to run all pods as non-root users.
Why it's wrong here
Running as non-root reduces the impact of a container breakout but says nothing about image provenance. An unscanned or malicious image can run perfectly well as a non-root user and still introduce vulnerabilities. This setting addresses runtime privilege, not the requirement to block images that failed scanning, so it does not satisfy the auditor.
- ✗
Configure a network policy that denies egress from all namespaces.
Why it's wrong here
Network policies restrict pod-to-pod and pod-to-external traffic at Layers 3 and 4. They do not inspect image provenance or block the scheduling of a pod based on which image it references. A pod built from an unscanned image would still be admitted and run, so this control does not satisfy the auditor's requirement for image integrity enforcement.
- ✓
Enable a Kubernetes admission controller that validates image signatures or scan attestations.
Why this is correct
An admission controller such as one backed by Sigstore Cosign or a policy engine can reject pod creation unless the image carries a valid signature or attestation from the firm's scanner. This enforces the requirement at the API server before scheduling, ensuring only scanned, approved images reach the cluster.
About these practice questions
This GSEC question is part of Courseiva's 351-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam 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.