CKAD Practice Question: Application Environment, Configuration and Security
A pod must run with a seccomp profile that only allows specific syscalls. Which SecurityContext field is used to specify the seccomp profile type?
⚠ Common exam trap
Test-takers frequently confuse the older annotation-based approach (`seccomp.security.alpha.kubernetes.io/pod`) with the newer native `seccompProfile` field, or they mistakenly think the field is simply named `seccomp` instead of `seccompProfile`.
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
✓
seccompProfile
`seccompProfile` is the field within the Pod or container `SecurityContext` that specifies the seccomp profile type (e.g., `RuntimeDefault`, `Localhost`, or `Unconfined`). This field was introduced in Kubernetes v1.19 (beta) and replaces the older annotation-based seccomp configuration, allowing you to define the profile type directly in the pod spec.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
appArmorProfile
Why it's wrong here
AppArmor is a separate Linux security module (LSM) that mediates file access and program capabilities through profiles, not a syscall filter. Kubernetes configures AppArmor using annotations such as container.apparmor.security.beta.kubernetes.io/<container>, not an appArmorProfile field. Therefore, this option would not apply a seccomp profile; it would either be ignored or not represent a real API field.
- ✗
seLinuxOptions
Why it's wrong here
SELinux is another Linux security module that provides mandatory access control via labels (e.g., user:role:type). The seLinuxOptions field in a Pod's securityContext configures the SELinux context for the container, such as the 'type' to enforce. It has no effect on seccomp syscall filtering, so selecting this field would not apply the desired seccomp profile.
- ✗
seccomp
Why it's wrong here
There is no field literally named 'seccomp' in the Kubernetes securityContext API. The correct field name is 'seccompProfile', which was introduced in Kubernetes v1.19 and became beta in v1.19. If you use an unknown field, it will be ignored (or rejected by strict validation), so the seccomp profile would not be applied. Older annotation-based seccomp configuration is deprecated and not a drop-in replacement for this field.
- ✓
seccompProfile
Why this is correct
The seccompProfile field within the securityContext is the correct way to specify a seccomp profile. It supports three types: RuntimeDefault (the container runtime's default syscall filter), Localhost (a custom profile stored on the node), and Unconfined (no seccomp filtering). Setting this field ensures the Pod's containers run with the specified seccomp syscall restrictions.
Go deeper
Related to this question
About these practice questions
This CKAD question is part of Courseiva's 826-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 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.