CKAD Practice Question: Application Environment, Configuration and Security
Which THREE of the following are valid fields in a PodSecurityContext (pod-level securityContext)? (Select 3)
⚠ Common exam trap
CNCF often tests the distinction between pod-level and container-level securityContext fields, and the trap here is that candidates confuse `readOnlyRootFilesystem` and `capabilities` as pod-level fields when they are actually only valid at the container level.
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
✓
runAsUser
`runAsUser` is a valid field in a PodSecurityContext that sets the user ID (UID) for all containers in the pod, overriding any container-level `securityContext.runAsUser`. This is defined in the Kubernetes API under `PodSecurityContext` and is commonly used to enforce non-root execution.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
runAsUser
Why this is correct
In the PodSecurityContext, runAsUser specifies the UID that all containers in the pod run with, overriding any image-level USER directive. It is a pod-level field because it belongs to the pod's security context and applies uniformly to every container's primary process. Setting it ensures consistent privilege separation at the pod level.
- ✓
fsGroup
Why this is correct
fsGroup in the PodSecurityContext defines the group ID that owns all volume mounts (and any files created) in the pod, enabling shared access across containers. It also triggers a recursive chown of volume contents to that group, which is a pod-level operation. This field is distinct from runAsGroup, which applies to the container process's group, whereas fsGroup applies to mounted volumes.
- ✗
readOnlyRootFilesystem
Why it's wrong here
readOnlyRootFilesystem is a field within a container's SecurityContext, not the PodSecurityContext. It forces the container's root filesystem to be read-only, which is a per-container behavior because each container has its own filesystem layer. Since it must be set individually for each container (e.g., in a deployment's container spec), it cannot be specified at the pod level.
- ✗
capabilities
Why it's wrong here
Linux capabilities (e.g., NET_ADMIN) are added or dropped via the capabilities field in a container's SecurityContext. They are process-level attributes that apply to the specific container's processes, and the PodSecurityContext does not have a capabilities field. This is because different containers in the same pod may require different privilege sets, so capabilities must be configured per container.
- ✓
seccompProfile
Why this is correct
seccompProfile can be defined in the PodSecurityContext to apply a seccomp profile (e.g., RuntimeDefault or Localhost) to all containers in the pod. It was promoted to beta in Kubernetes 1.19, allowing it to be set at the pod level rather than solely as an annotation. This pod-level setting ensures consistent syscall filtering across the entire pod, though it can also be overridden at the container level.
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.