CKS System Hardening Practice Question
What is the default seccomp profile for Kubernetes containers when no seccompProfile is specified?
⚠ Common exam trap
A common trap is the misconception that no seccomp profile means 'no restrictions' (Unconfined), but the correct default is `RuntimeDefault`, which applies a secure baseline profile automatically.
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
✓
RuntimeDefault
When no `seccompProfile` is specified in the Pod or container security context, Kubernetes applies the `RuntimeDefault` seccomp profile by default. This profile is defined by the container runtime (e.g., containerd or CRI-O) and blocks a specific set of syscalls that are considered dangerous or unnecessary for containers, while allowing normal application operations. This default behavior was introduced in Kubernetes 1.19 and became the default for all pods in Kubernetes 1.22, enhancing security without requiring explicit configuration.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Localhost
Why it's wrong here
The `Localhost` seccomp profile type cannot be the default because it requires explicit per-pod configuration: an operator must set `seccompProfile.type: Localhost` in the securityContext and provide a `localhostProfile` path to a JSON file on the node. Without that custom file present on every node, Kubernetes has nothing to load, so the runtime falls back to its built-in `RuntimeDefault` policy.
- ✗
No profile is applied
Why it's wrong here
This option is false because the container runtime always applies a seccomp profile to every container, even when the Kubernetes API does not explicitly specify one. CRI implementations such as containerd and CRI-O install their own compiled default profile, which filters dangerous syscalls by default. Therefore, stating that no profile is applied ignores the runtime-level enforcement that occurs regardless of Kubernetes settings.
- ✓
RuntimeDefault
Why this is correct
The effective default seccomp profile for containers in Kubernetes is `RuntimeDefault`, which instructs the container runtime to apply its own built-in seccomp policy. This policy allows common application syscalls while blocking privileged or rarely needed ones such as `mount`, `reboot`, and `kexec_load`, providing a secure baseline. Even though a pod's `securityContext` may omit `seccompProfile`, the runtime enforces this profile automatically; in v1.29+ this is the expected behavior unless explicitly overridden.
- ✗
Unconfined
Why it's wrong here
`Unconfined` disables seccomp filtering completely, allowing every syscall to pass through without inspection. It was effectively the implicit behavior in early Kubernetes versions before seccomp support matured, but it is not the default in v1.29 and later. Modern security guidance expects `RuntimeDefault`; using `Unconfined` is reserved for workloads with special compatibility needs and represents a deliberate weakening of the container isolation.
Go deeper
Related to this question
About these practice questions
This CKS question is part of Courseiva's 845-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. 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.