The correct answer is that the volume is owned by group 2000, while the container runs with user 1000 and group 3000. This is because `fsGroup: 2000` specifically sets the group ownership of any mounted volume to group ID 2000 and adds that group as a supplemental group for the container’s processes, while `runAsUser: 1000` and `runAsGroup: 3000` define the primary user and group for the running process. On the CKAD exam, this concept tests your understanding of how security contexts interact with volume permissions—a common trap is confusing `runAsGroup` with `fsGroup`, thinking the volume inherits the container’s primary group. In reality, `fsGroup` overrides volume group ownership independently. A helpful memory tip: think of `fsGroup` as “filesystem group”—it only touches the volume’s group, not the process’s primary group.
CKAD Practice Question: Application Environment, Configuration and Security
This CKAD practice question tests your understanding of application environment, configuration and security. Match the stated requirement to the specific cloud service, access model, or configuration option — many options are valid in isolation but not for this scenario. After answering, compare your reasoning against the explanation and wrong-answer breakdown below. Once you have made your selection, read the full explanation to reinforce the concept and understand why each distractor is designed to mislead on exam day.
Given the following partial pod spec:
```yaml
securityContext:
runAsUser: 1000
runAsGroup: 3000
fsGroup: 2000
```
Which combination correctly describes the resulting permissions on a mounted volume?
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Volume owned by user 1000, group 2000; container runs with user 1000 and group 3000
Option C is correct because `runAsUser: 1000` sets the container's primary user ID to 1000, `runAsGroup: 3000` sets the primary group ID to 3000, and `fsGroup: 2000` changes the group ownership of any mounted volume to group 2000, while also granting the container's processes supplemental group access to group 2000. The volume's user ownership remains the default (often root or the image's user) unless explicitly changed, but the key point is that the volume is group-owned by 2000 and the container runs with UID 1000 and GID 3000.
Key principle: Answer the scenario, not the keyword: identify the specific constraint before choosing the most familiar-sounding option.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
✗
Volume owned by user 2000, group 1000; container runs with user 2000 and group 1000
Why it's wrong here
Incorrect mapping; runAsUser and runAsGroup affect container, fsGroup affects volume.
✗
Volume owned by user 3000, group 2000; container runs with user 1000 and group 3000
Why it's wrong here
runAsUser sets the container's user ID, not the volume's owner.
✓
Volume owned by user 1000, group 2000; container runs with user 1000 and group 3000
Why this is correct
runAsUser sets the container user to 1000; runAsGroup sets the primary group to 3000; fsGroup sets the volume's group ownership to 2000.
Related concept
Read the scenario before looking for a memorised answer.
✗
Volume owned by user 1000, group 3000; container runs with user 1000 and group 2000
Why it's wrong here
The fsGroup sets the volume's group to 2000, not the container's group.
Common exam traps
Common exam trap: answer the scenario, not the keyword
The trap here is confusing `runAsGroup` (which sets the container's primary GID) with `fsGroup` (which sets the volume's group ownership and adds a supplemental group), leading candidates to incorrectly assign the volume's group to the container's primary group or vice versa.
Detailed technical explanation
How to think about this question
Under the hood, the `fsGroup` field in the PodSecurityContext triggers the kubelet to recursively `chown` the volume's group ownership to the specified GID (2000) during volume mount setup, and it adds that GID to the container's supplementary groups list via the `setgroups` system call. This ensures that even if the container runs with a different primary GID (3000), it can still write to the volume because the volume's group permission bits (e.g., 770) grant write access to group 2000. A real-world scenario is a shared filesystem where multiple containers need to write to the same volume but run with different primary UIDs/GIDs—`fsGroup` provides a consistent group-based access control.
KKey Concepts to Remember
Read the scenario before looking for a memorised answer.
Find the constraint that changes the correct option.
Eliminate answers that are true in general but not in this case.
TExam Day Tips
→Watch for words such as best, first, most likely and least administrative effort.
→Review why wrong options are wrong, not only why the correct option is correct.
Key takeaway
Answer the scenario, not the keyword: identify the specific constraint before choosing the most familiar-sounding option.
Real-world example
How this comes up in practice
A small business has 20 workstations on the 192.168.1.0/24 network and one public IP from its ISP. The router uses PAT (NAT overload) so all 20 devices share one public address using different source ports. NAT questions test whether you understand the four address terms and which direction each translation applies.
Related glossary terms
Concepts from this question explained
These glossary pages explain the core terms tested in this CKAD question in full detail.
Application Environment, Configuration and Security — This question tests Application Environment, Configuration and Security — Read the scenario before looking for a memorised answer..
What is the correct answer to this question?
The correct answer is: Volume owned by user 1000, group 2000; container runs with user 1000 and group 3000 — Option C is correct because `runAsUser: 1000` sets the container's primary user ID to 1000, `runAsGroup: 3000` sets the primary group ID to 3000, and `fsGroup: 2000` changes the group ownership of any mounted volume to group 2000, while also granting the container's processes supplemental group access to group 2000. The volume's user ownership remains the default (often root or the image's user) unless explicitly changed, but the key point is that the volume is group-owned by 2000 and the container runs with UID 1000 and GID 3000.
What should I do if I get this CKAD question wrong?
Identify which exam domain this question belongs to, review the core concept, then practise similar questions from the same domain.
What is the key concept behind this question?
Read the scenario before looking for a memorised answer.
About these practice questions
Courseiva creates original exam-style practice questions with explanations and wrong-answer analysis. It does not publish real exam questions, exam dumps, or protected exam content. Learn why practice questions differ from exam dumps →
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. 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?
medium
A.supplementalGroups: [3000]
B.fsGroup: 1000
✓ C.fsGroup: 3000
D.runAsGroup: 3000
Why C: Option C is correct because 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.
Variation 2. A pod is running with a SecurityContext that sets 'runAsUser: 1000' and 'runAsGroup: 3000'. The container process is running as user 1000. However, the container needs to access a file on a mounted volume that is owned by user 1000 and group 2000. Which SecurityContext setting should be added to ensure the container can read the file?
medium
✓ A.Set fsGroup: 2000 in the pod-level securityContext
B.Set readOnlyRootFilesystem: true
C.Set runAsGroup: 2000
D.Add capability: CAP_DAC_READ_SEARCH
Why A: The 'fsGroup' field in the pod's SecurityContext changes the group ownership of any files in the mounted volumes to the specified GID, and all container processes are part of the supplementary group. This allows the container to read files with group 2000 if fsGroup is set to 2000. Option A (runAsGroup: 2000) would change the primary group of the process, but the file's group is 2000 and the container runs as user 1000, which might not own the file; fsGroup is the correct approach. Option C adds capabilities, which are not related to file access groups. Option D sets readOnlyRootFilesystem, which doesn't help with volume access.
Last reviewed: Jun 25, 2026
Question Discussion
Share a tip, memory trick, or ask about the reasoning behind this question. Do not post real exam questions, leaked content, braindumps, or copyrighted exam material. Comments are moderated and may be removed without notice.
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.
Question Discussion
Share a tip, memory trick, or ask about the reasoning behind this question. Do not post real exam questions, leaked content, braindumps, or copyrighted exam material. Comments are moderated and may be removed without notice.
Sign in to join the discussion.