KCNA Kubernetes Fundamentals Practice Question
A pod in the 'default' namespace has the following YAML snippet: securityContext: runAsUser: 1000 runAsGroup: 3000 fsGroup: 2000 What is the effect of the fsGroup field?
⚠ Common exam trap
A common trap is confusing the role of `runAsGroup` (which sets the primary GID of the container process) with `fsGroup` (which sets the group ownership of mounted volumes), leading candidates to incorrectly select option D.
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
✓
It sets the group ID for any volumes mounted into the pod.
The `fsGroup` field in a Pod's security context sets the group ID (GID) that will be used for ownership of any volumes mounted into the pod. When a volume is mounted, Kubernetes recursively changes the group ownership of the volume's files to the specified GID (2000 in this case) and makes them readable and writable by that group. This ensures that processes running in the container, which may have a different primary group (3000 from `runAsGroup`), can still access the volume files if they are members of the fsGroup.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
It restricts the pod to run only on nodes with that group ID.
Why it's wrong here
fsGroup sets the supplementary group applied to mounted volumes so their files are group-owned by that GID; it never constrains node scheduling. Node selection by group ID is not a Kubernetes concept — nodeSelector, affinity or taints govern placement instead.
- ✓
It sets the group ID for any volumes mounted into the pod.
Why this is correct
fsGroup applies a supplementary group ID to all processes in the pod and changes ownership of mounted volume contents, so files become group-writable. This satisfies the stem's question about volume group ownership, distinct from runAsGroup, which sets the primary group for the container process itself.
- ✗
It defines the group ID for the pod's service account.
Why it's wrong here
fsGroup governs volume ownership and permissions, not the service account, whose group membership is unrelated to this field. It tempts because service accounts do carry identity, but their group IDs come from RBAC bindings, not from a pod securityContext setting.
- ✗
It sets the group ID for the container's main process.
Why it's wrong here
The container's main process group is set by runAsGroup (3000 here), not fsGroup. fsGroup instead applies a supplementary GID to mounted volumes so shared files are group-owned correctly; confusing the two is easy since both fields specify numeric group IDs.
Go deeper
Related to this question
About these practice questions
Courseiva writes every KCNA question from scratch — 930 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 KCNA 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 KCNA exam.