CKS System Hardening Practice Question
Which TWO of the following are valid methods to apply a seccomp profile to a Kubernetes pod? (Select two.)
⚠ Common exam trap
CNCF often tests the distinction between the GA field (securityContext.seccompProfile) and the deprecated annotation method, and candidates may confuse the incomplete annotation format (e.g., missing container name) with a valid option.
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 pod annotation: seccomp.security.alpha.kubernetes.io/pod
The seccomp.security.alpha.kubernetes.io/pod annotation was the original method to apply a seccomp profile to an entire pod in Kubernetes versions prior to v1.19. This annotation specifies the seccomp profile path or type (e.g., 'runtime/default' or 'localhost/<profile>') for the pod's containers, and it remains valid in older clusters or when using legacy configurations.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Using the field: spec.seccompProfile
Why it's wrong here
spec.seccompProfile is not a valid field directly under the pod spec. The Kubernetes API requires seccomp configuration to be nested inside securityContext, which may be set at the pod or container level. Attempting to set this unknown field would cause the manifest to be rejected, so it is not a valid method.
- ✓
Using the pod annotation: seccomp.security.alpha.kubernetes.io/pod
Why this is correct
The annotation seccomp.security.alpha.kubernetes.io/pod is a legacy but still functional method to apply a seccomp profile to the entire pod. It predates the seccompProfile field in securityContext and is deprecated in favor of the structured API, yet many existing workloads still rely on it. Placing this key on the Pod object tells the runtime to use the referenced profile, making it a valid approach.
- ✓
Using the field: securityContext.seccompProfile.type
Why this is correct
securityContext.seccompProfile.type is the current, GA way to configure seccomp in Kubernetes. The type field accepts values like RuntimeDefault or Localhost, and when set to Localhost, you must also provide the path via the localhostProfile field. This structured API is recommended because it is more discoverable and supports per-container settings without relying on annotations.
- ✗
Using the command line flag: --seccomp-profile when running kubectl run
Why it's wrong here
The kubectl run command does not expose a --seccomp-profile flag; seccomp settings are not part of the CLI's supported options. kubectl run can only generate a basic Pod manifest and requires editing the YAML or using --override to inject securityContext fields. Since there is no such flag, this is not a valid method.
- ✗
Using the pod annotation: container.seccomp.security.alpha.kubernetes.io
Why it's wrong here
The annotation container.seccomp.security.alpha.kubernetes.io is incomplete and invalid as written because per-container seccomp annotations must include a container name suffix, such as container.seccomp.security.alpha.kubernetes.io/nginx. Additionally, it is not the AppArmor annotation; AppArmor uses container.apparmor.security.beta.kubernetes.io. Therefore, this exact key does not work for applying seccomp.
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 →
Same concept, more angles
1 more way this is tested on CKS
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. Which TWO of the following are valid methods to apply a seccomp profile to a pod in Kubernetes?
medium- ✓ A.Setting 'securityContext.seccompProfile.type' in the pod spec
- B.Adding annotation 'container.apparmor.security.beta.kubernetes.io/<container>'
- C.Including 'seccomp' profile in PodSecurityPolicy
- D.Including 'seccompProfile' under 'spec.securityContext' at the pod level
- ✓ E.Adding annotation 'seccomp.security.alpha.kubernetes.io/pod'
Why A: Option A is correct because Kubernetes supports the native seccomp field 'securityContext.seccompProfile.type' (with values such as RuntimeDefault, Localhost, or Unconfined) directly in the pod or container security context, which is the modern, stable way to apply a seccomp profile. Option E is correct because the legacy annotation 'seccomp.security.alpha.kubernetes.io/pod' was the original mechanism for applying a seccomp profile to an entire pod before the securityContext field existed, and it is still recognized for backward compatibility. Option B is incorrect because 'container.apparmor.security.beta.kubernetes.io/<container>' applies an AppArmor profile, not a seccomp profile. Option C is incorrect because PodSecurityPolicy (deprecated and removed in Kubernetes 1.25) controlled seccomp via its own allowed/required annotations and fields, not by embedding a seccomp profile definition itself. Option D is incorrect because the seccompProfile field belongs under 'securityContext' (pod-level) or a container's securityContext, but the option's phrasing of including it under 'spec.securityContext' as a distinct method is not a valid separate mechanism from A.
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.