CKS Minimize Microservice Vulnerabilities Practice Question
A pod is configured with securityContext: runAsUser: 1000 runAsGroup: 3000 fsGroup: 2000
The volume mounted at /data is owned by user 1000 and group 2000. The container process inside the pod writes to /data. Which statement about file ownership is true?
⚠ Common exam trap
The CKS exam often tests the distinction between runAsGroup (the process's primary group) and fsGroup (the group ownership applied to the volume), leading candidates to incorrectly assume that new files inherit the runAsGroup instead of the fsGroup-controlled directory 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
✓
Files created in /data will be owned by user 1000 and group 2000.
The `fsGroup: 2000` in the pod's securityContext causes Kubernetes to recursively change the group ownership of the volume to group 2000 and enable a setgid bit on the mount directory. When the container process (running as user 1000) writes new files to /data, those files inherit the group ownership of the directory (2000) due to the setgid bit, while the user ownership remains 1000 (the runAsUser). Thus, new files are owned by user 1000 and group 2000.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Files created in /data will be owned by root:root because of the volume mount.
Why it's wrong here
The volume mount itself does not force root ownership; ownership is determined by the pod's securityContext, not by the mount action. Since runAsUser: 1000 and fsGroup are set, the container writes files as UID 1000 with group ownership taken from fsGroup, overriding any default root:root behavior. Without a securityContext, the default would be root, but here it is explicitly overridden.
- ✓
Files created in /data will be owned by user 1000 and group 2000.
Why this is correct
The pod's securityContext defines runAsUser: 1000, so the process UID is 1000. Additionally, fsGroup: 2000 causes the mounted volume to be group-owned by GID 2000 and adds that group to the container's supplementary groups. Therefore, files created in /data are owned by user 1000 and group 2000, as the kernel assigns the effective UID and the volume's group (via setgid) to new files.
- ✗
Files created in /data will be owned by user 1000 and group 3000.
Why it's wrong here
The group on files in /data is controlled by fsGroup, not by runAsGroup. Even if runAsGroup were set to 3000, it would only change the primary group of the process; the volume's group ownership would still be set to fsGroup (2000) at mount time. Since fsGroup is 2000, files inherit GID 2000, never 3000.
- ✗
Files created in /data will be owned by user 1000 and group 1000.
Why it's wrong here
runAsUser only sets the UID of the process; it does not automatically set the GID to the same value. The group ownership of volume files is explicitly assigned by fsGroup, which is 2000 here. Without fsGroup, the group might be the container image's default or root, but not necessarily 1000; here the volume's group is 2000, so user 1000:group 2000 is correct, not 1000:1000.
Go deeper
Related to this question
About these practice questions
Courseiva writes every CKS question from scratch — 845 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 →
Same concept, more angles
1 more way this is tested on CKS
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. An administrator creates a Pod with the following securityContext: securityContext: runAsUser: 1000 runAsGroup: 3000 fsGroup: 2000 The container image has a binary that requires read/write access to /data, which is an emptyDir volume mounted by the Pod. The container fails to start with 'Permission denied' when writing to /data. What is the most likely cause?
medium- A.The container's base image has a restrictive umask that overrides the pod's security context.
- B.The fsGroup is set but the volume's fsGroupChangePolicy is missing.
- C.The emptyDir volume is not writable by default; it needs to be explicitly configured.
- ✓ D.The container is running as user 1000, but the volume is owned by root (uid 0) and the fsGroup 2000 does not give write permission.
Why D: The container runs as UID 1000 with GID 3000, and the emptyDir volume is owned by root (uid 0). The fsGroup 2000 causes Kubernetes to change the volume's group ownership to 2000 and set group-writable permissions, but the process's primary GID is 3000, not 2000, so it does not get write access via group membership. The result is 'Permission denied' when the binary tries to write to /data.
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This CKS 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 CKS exam.