SSCP Systems and Application Security Practice Question
A healthcare SaaS provider runs its application stack on Docker containers orchestrated by Kubernetes in a public cloud. A security administrator must reduce the risk of a compromised container accessing the underlying node's kernel. Which control BEST addresses this requirement?
⚠ Common exam trap
The trap here is assuming that any Kubernetes security feature, such as NetworkPolicy or Secrets, provides workload isolation, when only sandboxed runtimes change the kernel trust boundary.
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
✓
Deploy containers with gVisor or Kata Containers to provide a sandboxed kernel boundary.
Sandboxed container runtimes such as gVisor and Kata Containers create a kernel boundary between the workload and the node, directly reducing the impact of a compromised container. Network policies, secret encryption, and resource quotas address networking, confidentiality, and availability respectively, but none of them prevent a container from interacting with the host kernel.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Deploy containers with gVisor or Kata Containers to provide a sandboxed kernel boundary.
Why this is correct
gVisor and Kata Containers insert an isolation layer between the container and the host kernel. gVisor intercepts system calls in user space, while Kata runs each pod in a lightweight virtual machine with its own kernel. Either approach prevents a container breakout from directly reaching the node kernel, directly satisfying the requirement to limit kernel-level exposure.
- ✗
Set CPU and memory resource requests and limits on each container specification.
Why it's wrong here
Resource requests and limits govern scheduling and cap consumption to prevent noisy-neighbor effects or denial-of-service via resource exhaustion. They are availability controls, not security boundaries. A container that exceeds neither limit can still issue malicious system calls against the shared host kernel, so this does not mitigate container escape risk.
- ✗
Configure Kubernetes Secrets to encrypt environment variables used by the application.
Why it's wrong here
Kubernetes Secrets store and distribute sensitive data such as API keys to pods, optionally encrypted at rest in etcd. This protects credential confidentiality but does nothing to constrain what a running container can do to the host. A compromised container retains the same kernel access, so secret management is not an isolation control here.
- ✗
Enable Kubernetes NetworkPolicy to restrict pod-to-pod traffic on the cluster network.
Why it's wrong here
NetworkPolicy operates at Layers 3 and 4 to control which pods can communicate with each other or with external endpoints. It does not isolate a container's system calls from the host kernel, so a compromised container could still exploit a kernel vulnerability. Traffic filtering is orthogonal to kernel-level separation and therefore does not satisfy the stated objective for this containerized workload.
Go deeper
Related to this question
About these practice questions
One of 971 original SSCP practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. 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 ISC2 exam blueprint
This SSCP practice question is part of Courseiva's free ISC2 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 SSCP exam.