CKAD Practice Question: Application Environment, Configuration and Security
A developer creates a pod with the following YAML snippet:
securityContext: runAsUser: 1000 runAsGroup: 3000 fsGroup: 2000
The pod mounts an emptyDir volume. What is the owner and group of the mounted directory inside the container?
⚠ Common exam trap
Many exam-takers confuse `runAsGroup` (which sets the primary GID of the container process) with `fsGroup` (which sets the group ownership of mounted volumes), leading them to pick Option A or B instead of recognizing that `fsGroup` overrides the volume's group.
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
✓
Owner: 1000, Group: 2000
When a pod specifies `fsGroup: 2000`, Kubernetes recursively changes the group ownership of any volume mounted into the pod (including emptyDir) to that GID (2000). The `runAsUser: 1000` sets the container process's UID, but the volume's group ownership is overridden by `fsGroup`. Thus, the mounted emptyDir directory is owned by UID 1000 (the process user) and GID 2000 (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.
- ✗
Owner: 1000, Group: 3000
Why it's wrong here
This is incorrect because the group ownership of the mounted volume is dictated by the `fsGroup` field in the pod's security context, not by `runAsGroup`. While `runAsGroup` changes the primary group ID for the container processes, Kubernetes applies `fsGroup` specifically to all volumes mounted into the pod, overriding any default group. Since the snippet sets `fsGroup: 2000`, the volume's group will be 2000, not 3000.
- ✗
Owner: 1000, Group: 1000
Why it's wrong here
The volume's owner is correctly set from `runAsUser: 1000`, but the group is not the same as the user. Even if `runAsGroup` is unspecified, Kubernetes does not default the volume group to the user ID; instead, `fsGroup` explicitly overrides it for all mounted volumes. Because `fsGroup: 2000` is defined, the group ownership becomes 2000, not 1000, making this option incorrect.
- ✓
Owner: 1000, Group: 2000
Why this is correct
This is the correct outcome. The `runAsUser: 1000` field determines the owner UID of the pod's processes and, by extension, the ownership of the mounted volume's root directory as seen by the container. The `fsGroup: 2000` field explicitly sets the group ownership for all volume mounts, and also makes that group supplementary for the container's processes, allowing access. Therefore, the volume ends up owned by UID 1000 and GID 2000.
- ✗
Owner: 0, Group: 2000
Why it's wrong here
The group ownership is correctly 2000 because of `fsGroup`, but the owner is incorrectly assumed to be root (UID 0). The `runAsUser` field explicitly sets the container's user ID to 1000, which also becomes the owner of the mounted volumes when they are accessed. Since `runAsUser: 1000` is specified, the owner is UID 1000, not UID 0, so this option is wrong.
Go deeper
Related to this question
About these practice questions
This CKAD question is part of Courseiva's 826-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam 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.