CKAD Practice Question: Application Environment, Configuration and Security
A Pod specification includes: securityContext: { seccompProfile: { type: RuntimeDefault } }. What does this configuration do?
⚠ Common exam trap
Watch out — candidates often confuse `RuntimeDefault` with disabling seccomp or allowing all syscalls, when in fact it applies a restrictive, runtime-specific default profile that is neither fully permissive nor custom.
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
✓
It applies the container runtime's default seccomp profile
Setting `seccompProfile.type: RuntimeDefault` in the Pod's securityContext instructs the container runtime (e.g., containerd or CRI-O) to apply its own default seccomp profile to the container. This default profile restricts system calls to a safe subset, blocking dangerous or unnecessary syscalls while allowing common ones required for typical application execution. It is the recommended way to enable seccomp without managing a custom profile.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
It disables seccomp for the pod
Why it's wrong here
Setting `type: RuntimeDefault` in the securityContext's seccompProfile does not disable seccomp; rather, it opts the pod into the container runtime's default seccomp policy. Disabling seccomp entirely would require `type: Unconfined` (or omitting the field, which often results in Unconfined unless a cluster-wide default is set). Therefore, RuntimeDefault is the opposite of disabling seccomp.
- ✓
It applies the container runtime's default seccomp profile
Why this is correct
A `seccompProfile` with `type: RuntimeDefault` instructs the container runtime (e.g., Docker, containerd) to apply its built-in default seccomp filter, which is typically a restricted profile that blocks dangerous syscalls like `kexec_load`, `reboot`, and `keyctl` while permitting common operations. This provides a security-hardened baseline automatically, without needing to author or manage a custom profile. It is the recommended option for most workloads unless specific syscalls must be allowed.
- ✗
It allows all syscalls
Why it's wrong here
Allowing every syscall is the behavior of `seccompProfile.type: Unconfined`, which disables seccomp filtering entirely. In contrast, `RuntimeDefault` applies a curated allowlist of syscalls, with many high-risk or rarely needed ones blocked. Thus, choosing `RuntimeDefault` does not grant unrestricted syscall access; it actively reduces the attack surface of the container.
- ✗
It uses a custom seccomp profile from a file
Why it's wrong here
A custom seccomp profile from a file is configured using `type: Localhost` and the `localhostProfile` field, which points to a JSON profile stored on the node. `RuntimeDefault` is a built-in type that references the runtime's own default profile, not a user-supplied file. Therefore, there is no file path or custom profile configuration associated with `RuntimeDefault`; it is a completely different mechanism for applying seccomp.
Go deeper
Related to this question
About these practice questions
Courseiva writes every CKAD question from scratch — 826 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or 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 CKAD 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 CKAD exam.