CKS System Hardening Practice Question
A container runs with the default seccomp profile but the application needs to make a specific syscall that is blocked. Which approach should be taken?
⚠ Common exam trap
CNCF often tests the misconception that capabilities can override seccomp restrictions, but in reality, seccomp and capabilities are independent security mechanisms; a blocked syscall cannot be unblocked by adding capabilities.
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
✓
Create a custom seccomp profile that allows the syscall and apply it via type: Localhost
The default seccomp profile (RuntimeDefault) blocks a specific set of syscalls for security. When an application requires a blocked syscall, the proper approach is to create a custom seccomp profile that explicitly allows that syscall, then apply it to the container via `seccompProfile.type: Localhost` and reference the profile file. This maintains security by only relaxing the necessary restriction, rather than disabling the profile entirely.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Use the RuntimeDefault profile and add capabilities
Why it's wrong here
Setting securityContext.seccompProfile to RuntimeDefault while adding capabilities does not resolve a blocked syscall because seccomp filters are evaluated before capabilities are checked. Capabilities like SYS_ADMIN grant additional privilege checks inside syscalls that are allowed to run, but they cannot re-enable a syscall that seccomp has denied at the syscall entry point. Even a container with all capabilities will still receive EPERM for syscalls excluded by the default profile. The only way to allow the specific syscall is to modify the seccomp filter itself.
- ✗
Change the seccomp profile to another runtime default
Why it's wrong here
Switching to another runtime default, such as CRI-O's default profile, is ineffective because all common runtimes base their default on the same Docker/containerd seccomp policy, which blocks a well-known set of syscalls that includes the one causing the failure. The default profiles are intentionally similar and often identical for the dangerous syscalls, so the application will likely still be blocked. This approach also makes the workload's behavior dependent on which runtime happens to be installed, making it non-portable. A targeted profile is needed to allow only the required syscall.
- ✗
Set seccompProfile to Unconfined
Why it's wrong here
Setting seccompProfile to Unconfined disables seccomp filtering entirely, bypassing the kernel's security layer and allowing all syscalls to execute. While this would permit the blocked syscall, it also re-enables dangerous syscalls such as mount, ptrace, and kexec_load, dramatically increasing the risk of container breakout and compromising the host. This violates the principle of least privilege and is far broader than necessary. A custom profile that allows only the one missing syscall preserves protection for everything else.
- ✓
Create a custom seccomp profile that allows the syscall and apply it via type: Localhost
Why this is correct
The correct approach is to create a custom seccomp profile, a JSON file with a syscall allowlist that explicitly permits the missing syscall while retaining the default deny/safe list for all other syscalls. Place the profile on the node under the kubelet seccomp root, normally /var/lib/kubelet/seccomp, then reference it in the pod spec as securityContext.seccompProfile.type: Localhost with localhostProfile set to the filename. This gives fine-grained control and keeps the container secure, only widening the filter exactly where needed. It is the recommended way to handle seccomp exceptions.
Go deeper
Related to this question
About these practice questions
One of 845 original CKS 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 by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This CKS practice question is part of Courseiva's free CNCF 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 CKS exam.