CKS System Hardening Practice Question
Which TWO of the following are valid methods to apply a seccomp profile to a container? (Select 2 correct answers)
⚠ Common exam trap
Kubernetes often tests the distinction between alpha (`seccomp.security.alpha.kubernetes.io/pod`) and beta (`seccomp.security.beta.kubernetes.io/pod`) annotations, where the beta version never existed for seccomp, causing candidates to confuse it with the AppArmor beta annotation pattern.
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
✓
Using the seccomp.security.alpha.kubernetes.io/pod annotation
The `seccomp.security.alpha.kubernetes.io/pod` annotation was the original method to apply a seccomp profile to a pod in Kubernetes versions prior to v1.19. This annotation allows you to specify a seccomp profile path (e.g., 'localhost/my-profile') or a runtime default ('runtime/default') directly on the pod, which then applies to all containers in the pod. Option E is correct because `securityContext.seccompProfile.type` is the current, stable API field (GA since v1.19) that sets the seccomp profile at the container or pod level, accepting values like 'RuntimeDefault', 'Localhost', or 'Unconfined'.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Setting securityContext.seLinuxOptions.type
Why it's wrong here
Setting securityContext.seLinuxOptions.type configures SELinux labels for the container, which enforce mandatory access control on files, processes, and other objects. It does not interact with the kernel's syscall filtering mechanism, so it cannot limit which system calls a container makes. Seccomp requires a dedicated profile that allowlists or denylists syscalls, and this field is orthogonal to that concern.
- ✓
Using the seccomp.security.alpha.kubernetes.io/pod annotation
Why this is correct
The seccomp.security.alpha.kubernetes.io/pod annotation was the original way to request seccomp enforcement, allowing values like localhost/profile.json or runtime/default. It is alpha-qualified and deprecated; since Kubernetes 1.19 the preferred expression is the seccompProfile field. The annotation still functions in many legacy clusters, but it has no beta counterpart and will be removed as the alpha API is abandoned.
- ✗
Using the container.apparmor.security.beta.kubernetes.io annotation
Why it's wrong here
The container.apparmor.security.beta.kubernetes.io annotation is a legacy mechanism for applying AppArmor profiles to containers, which restrict programs via path-based rules rather than raw syscall filtering. AppArmor is a Linux Security Module and is fundamentally different from seccomp, which provides a kernel-level syscall sandbox. This annotation therefore has no effect on seccomp configuration, and it is also marked beta and deprecated.
- ✗
Using the seccomp.security.beta.kubernetes.io/pod annotation
Why it's wrong here
There is no such annotation as seccomp.security.beta.kubernetes.io/pod; the only annotation-based seccomp key was the alpha variant seccomp.security.alpha.kubernetes.io/pod. A beta transition was skipped in favor of introducing the structured securityContext.seccompProfile field. Because this annotation is nonexistent, the kubelet would ignore it, and the pod would remain unconfined.
- ✓
Setting securityContext.seccompProfile.type
Why this is correct
Setting securityContext.seccompProfile.type is the contemporary, stable API for seccomp configuration, introduced in Kubernetes 1.19 and GA in later releases. It supports RuntimeDefault, Localhost, and Unconfined, and it is placed directly in the pod or container securityContext. This approach supersedes the deprecated alpha annotations and clearly expresses the intended profile at the pod or container level.
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.