CKAD Practice Question: Application Environment, Configuration and Security
A Pod spec includes 'securityContext' with 'runAsUser: 1000' and 'runAsGroup: 3000'. The container process inside the pod is expected to write to a mounted volume. Which securityContext field should be set to ensure the volume's group ownership is 3000?
⚠ Common exam trap
A common mix-up: candidates confuse `fsGroup` with `supplementalGroups` or `runAsGroup`, mistakenly thinking that setting the container's group ID alone will automatically adjust the volume's permissions, when in fact `fsGroup` is the only field that modifies the volume's ownership.
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
✓
fsGroup: 3000
The `fsGroup` field in the Pod's `securityContext` specifies the group ID (GID) that Kubernetes should assign to any volume mounted into the Pod. When `fsGroup: 3000` is set, Kubernetes recursively changes the ownership of the volume's files and directories to group ID 3000, and any new files created by the container process will inherit that group ownership. This ensures the container process, which runs with `runAsGroup: 3000`, can write to the volume without permission errors.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
supplementalGroups: [3000]
Why it's wrong here
supplementalGroups: [3000] adds GID 3000 to the container's supplementary group list, so the process can access files already owned by that group subject to mode bits. However, it does nothing to the ownership of the mounted volume itself; the volume's root directory likely remains owned by root (GID 0) unless fsGroup is specified. Since the intended access depends on the volume's group being changed to 3000, this setting alone is insufficient.
- ✗
fsGroup: 1000
Why it's wrong here
Setting fsGroup to 1000 would direct Kubernetes to change the mounted volume's group ownership to GID 1000, but the scenario requires group 3000 to own the volume. The container's user is already UID 1000, but that identity is irrelevant here; fsGroup is about the volume's group, not the user. Consequently, the volume would be owned by the wrong group and writes requiring group 3000 permissions would fail.
- ✓
fsGroup: 3000
Why this is correct
fsGroup: 3000 is the correct mechanism because it simultaneously changes the group ownership of the volume's root directory to GID 3000 and adds that GID to the container's supplementary groups. With the process running as UID 1000, the group permissions on the volume now allow access via group 3000. This is exactly the Kubernetes-defined meaning of fsGroup: it alters the volume's ownership metadata to match the group that should be permitted.
- ✗
runAsGroup: 3000
Why it's wrong here
runAsGroup: 3000 sets the primary group ID of the container's main processes to 3000, which is useful for process-level group identity. It does not, however, touch the filesystem metadata of any mounted volume; the volume's group ownership remains whatever was set by the storage class or default (often GID 0). Even though the process is now in group 3000, it cannot write unless the volume's actual group is also 3000, which only fsGroup can enforce.
Go deeper
Related to this question
About these practice questions
Courseiva writes every CKAD question from scratch — 160 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.