CAS-004 Security Architecture Practice Question
A security team is hardening a Kubernetes cluster. Which control should be implemented to restrict a container's system calls to only those required by the application?
⚠ Common exam trap
CAS-005 often tests the confusion between seccomp (syscall filtering) and AppArmor/SELinux (mandatory access control on files and capabilities), so candidates who see 'restrict' and pick AppArmor miss the syscall-specific wording.
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
Seccomp (secure computing mode) is a Linux kernel feature that filters the system calls a process can make, using a BPF-based profile to allow or deny specific syscalls. In Kubernetes, seccomp profiles are applied via the securityContext.seccompProfile field (or the older seccomp.security.alpha.kubernetes.io/pod annotation), restricting a container to only the syscalls its application requires. This directly matches the requirement to limit a container's system calls.
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
Why this is correct
Seccomp profiles filter the syscalls a container may invoke, blocking everything outside an explicit allowlist. This directly satisfies the stem's requirement to restrict system calls to only those the application needs, unlike AppArmor or SELinux, which enforce mandatory access control over file paths, network ports and capabilities rather than the syscall interface itself.
- ✗
AppArmor
Why it's wrong here
AppArmor confines a process via path-based mandatory access control profiles, but it does not filter system calls by number. It is tempting because AppArmor does restrict program capabilities, yet seccomp is the mechanism that whitelists specific syscalls for a container.
- ✗
Network policies
Why it's wrong here
Network policies govern pod-to-pod traffic at layers three and four, leaving system calls untouched. They are tempting because they segment workloads effectively, but that addresses network reachability, whereas syscall restriction requires a seccomp profile applied to the container.
- ✗
Pod security policies
Why it's wrong here
Pod security policies govern pod-level attributes such as privileges and volume types, not individual system calls. They are tempting because they harden cluster workloads broadly, but syscall filtering is performed by seccomp, which pod security policies do not configure.
Go deeper
Related to this question
About these practice questions
One of 973 original CAS-005 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 CompTIA exam blueprint
This CAS-005 practice question is part of Courseiva's free CompTIA 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 CAS-005 exam.