CCSP Cloud Platform and Infrastructure Security Practice Question
A security architect is designing a container runtime security strategy. Which of the following controls is most effective at preventing a container from compromising the host kernel?
⚠ Common exam trap
CCSP often tests the misconception that filesystem or resource controls provide kernel-level protection, when in fact only syscall-filtering mechanisms like seccomp directly reduce the kernel attack surface from a container.
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
✓
Seccomp profile
Seccomp (secure computing mode) profiles restrict the system calls a container can make to the host kernel, directly reducing the kernel attack surface. By filtering out dangerous syscalls, seccomp is the most effective control for preventing a compromised container from exploiting kernel vulnerabilities. It operates at the syscall boundary, which is the primary interface between containers and 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.
- ✓
Seccomp profile
Why this is correct
Seccomp profiles filter the system calls a container may invoke, blocking the specific kernel interfaces an exploit needs to escalate to the host. This directly satisfies the stem's constraint of preventing host kernel compromise, since container escapes depend on unmediated syscalls rather than on network or filesystem configuration.
- ✗
Read-only root filesystem
Why it's wrong here
A read-only root filesystem prevents persistent writes to container storage but leaves the shared host kernel fully reachable through system calls. It is tempting because immutability is a recognised container hardening measure, and it would be correct for stopping tampering with application binaries, not for isolating the kernel.
- ✗
Resource limits (CPU/memory)
Why it's wrong here
CPU and memory limits constrain resource consumption to prevent denial-of-service, but they do not restrict which kernel system calls a container process may invoke. They are tempting because limits harden runtime behaviour, and they would be correct for stopping a fork bomb or memory exhaustion, not for blocking kernel exploitation.
- ✗
Image vulnerability scanning
Why it's wrong here
Scanning images detects known vulnerable packages before deployment but does nothing at runtime to stop an exploited process escaping its namespace to the host kernel. It is tempting because scanning is a core container security control, and it would be correct for shifting left on patch management, not for containing a live kernel exploit.
Go deeper
Related to this question
About these practice questions
One of 934 original CCSP 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 CCSP 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 CCSP exam.