CKS System Hardening Practice Question
A pod is running with securityContext.seccompProfile.type: Unconfined. Which statement is true?
⚠ Common exam trap
Candidates often mistake Unconfined for using the node's seccomp profile or think it means seccomp is unsupported, when in fact it explicitly disables syscall filtering.
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
✓
The container can make any system call.
When `securityContext.seccompProfile.type` is set to `Unconfined`, the container is allowed to make any system call without restriction. Seccomp (secure computing mode) is a Linux kernel feature that filters syscalls; `Unconfined` explicitly disables this filter, granting the container full syscall access. This is the most permissive seccomp profile and is the default if no profile is specified in older Kubernetes versions.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
The container is limited to a set of allowed syscalls as defined by the runtime.
Why it's wrong here
This statement describes the RuntimeDefault seccomp profile, not Unconfined. With RuntimeDefault, the container runtime applies its own default seccomp filter, which permits a curated set of syscalls and blocks potentially dangerous ones. In contrast, Unconfined means no seccomp filter is loaded at all, so no syscall is filtered or denied by seccomp.
- ✓
The container can make any system call.
Why this is correct
This is the correct interpretation. When seccompProfile is set to Unconfined, Kubernetes explicitly configures the container to run without a seccomp profile, effectively disabling kernel seccomp filtering for that container. All system calls the container makes are passed through to the kernel without being checked against a seccomp allowlist or denylist. Other security mechanisms like Linux capabilities or AppArmor may still apply, but seccomp imposes no restrictions.
- ✗
Seccomp is not supported on this node.
Why it's wrong here
Unconfined is a valid seccompProfile type in Kubernetes, and its meaning is orthogonal to whether the node supports seccomp. Seccomp is a Linux kernel feature that modern container runtimes (e.g., containerd, CRI-O) support, and Kubernetes exposes it as a stable API. Using Unconfined means 'do not enforce seccomp,' not that the node lacks the ability to use it. In fact, if seccomp were truly unsupported, the API would not allow specifying any profile type; the node would simply operate with seccomp disabled.
- ✗
The container is running with the host's seccomp profile.
Why it's wrong here
Running with the host's seccomp profile would require using the Localhost profile type, where the node filesystem provides a custom seccomp profile that is loaded for the container. Unconfined does exactly the opposite: it tells the runtime not to apply any seccomp filter, so the container has no seccomp enforcement regardless of any profile that might be installed on the host. The container's syscalls are therefore not constrained by the host's seccomp settings at all.
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.