SSCP Systems and Application Security Practice Question
A DevOps team deploys containerized microservices and wants to reduce the impact of a compromised container. They need a control that limits which system calls each container process can make, without changing the application image. Which Linux kernel feature should they enable?
⚠ Common exam trap
The trap here is treating resource limits or read-only file systems as syscall restrictions, when only seccomp filters the actual kernel calls a container may make.
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 profiles applied to the container
seccomp attaches a filter to each process that permits or denies individual system calls, so even a fully compromised container is constrained at the kernel boundary. Because profiles are supplied by the container runtime at launch, the team avoids modifying the application image while gaining strong containment.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Read-only root file system for the container
Why it's wrong here
Mounting the root file system read-only prevents persistent writes to the image layers, which is useful hardening, but it does not stop a process from invoking privileged system calls that affect the host kernel. The requirement specifically targets system call filtering, which this setting does not provide.
- ✓
seccomp profiles applied to the container
Why this is correct
seccomp filters the system calls a process may invoke, so a compromised container can be blocked from dangerous calls such as mounting file systems or loading kernel modules. Profiles are applied by the runtime at container start, requiring no change to the application image, which fits the team's constraint exactly.
- ✗
Dropping all Linux capabilities from the container
Why it's wrong here
Removing capabilities revokes specific privileged operations, but many kernel interfaces remain reachable through ordinary system calls, and capability sets are coarse-grained. It narrows the attack surface without providing the fine-grained, per-call filtering the team asked for.
- ✗
Linux cgroups v2 memory limits
Why it's wrong here
cgroups control resource consumption such as CPU, memory, and I/O, which limits denial-of-service impact but does not restrict what operations a process can perform. A container with a memory cap can still issue any system call. Resource isolation and syscall restriction are complementary but distinct controls.
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.