SSCP Systems and Application Security Practice Question
A financial services firm is migrating a customer-facing web application to a containerized platform. The security team wants to reduce the risk of a compromised container accessing the host kernel or other containers. Which of the following is the MOST effective control to limit the impact of a container breakout?
⚠ Common exam trap
The trap here is equating preventive scanning or logging with runtime containment, when the control that actually limits a breakout must restrict what the running process can ask the kernel to do.
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
✓
Enforcing a seccomp profile that allows only required system calls
Seccomp profiles constrain the system call interface exposed to container processes, directly shrinking the kernel attack surface an attacker can use to escape. Read-only filesystems, image scanning, and logging all add value at different stages but do not restrict runtime kernel interactions. Restricting syscalls is the most effective way to limit breakout impact on a shared host.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Scanning container images for known vulnerabilities before deployment
Why it's wrong here
Image scanning identifies outdated packages and known CVEs before deployment, which is valuable for reducing initial compromise risk. However, it does not constrain what a running container can do once exploited, so it cannot limit the impact of a breakout. The scenario asks about containing an active escape attempt, which scanning does not address directly.
- ✗
Enabling verbose logging of container stdout and stderr
Why it's wrong here
Capturing container output supports detection and forensics after an incident, but logging is passive and does not block malicious system calls or privilege escalation. An attacker who escapes the container may never emit useful log entries. While observability is important, it does not reduce the technical impact of a breakout, making it the weakest choice for this objective.
- ✗
Running containers with a read-only root filesystem
Why it's wrong here
A read-only root filesystem prevents an attacker from writing persistent changes inside the container image layer, which reduces tampering but does not restrict kernel system calls. A container breakout typically abuses kernel interfaces, so blocking writes alone leaves the primary escape path available. It is a useful hardening step but not the most effective control against kernel-level escape.
- ✓
Enforcing a seccomp profile that allows only required system calls
Why this is correct
Seccomp filters restrict which system calls a container process may invoke, directly limiting the kernel attack surface an attacker can use during a breakout attempt. By allowing only the calls the application needs, the profile blocks dangerous syscalls that are commonly abused for privilege escalation or container escape. This makes it the most effective control for reducing breakout impact.
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.