CKS System Hardening Practice Question
A Pod is being deployed with a securityContext that sets runAsUser: 1000 and runAsGroup: 3000. The container image's files are owned by root:root with permissions 755. The application needs to write to a directory /data that is mounted as an emptyDir volume. What will happen when the container attempts to write to /data?
⚠ Common exam trap
The trap here is assuming that setting runAsUser and runAsGroup automatically adjusts volume permissions, when actually fsGroup is needed to change volume 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
✓
The write will fail with a permission denied error because the emptyDir volume is owned by root and the container runs as user 1000.
An emptyDir volume is created with root:root ownership and 0755 permissions by default. The container runs as user 1000 and group 3000, which are not the owner and do not have write permission on the volume root. Unless a fsGroup is specified to change the group ownership and permissions, the write will fail with a permission denied error. The other options incorrectly assume automatic writability or misattribute the cause.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
The write will fail because emptyDir volumes are read-only by default.
Why it's wrong here
emptyDir volumes are not read-only by default; they are writable. The failure in this scenario is due to file permissions, not a read-only mount. The volume is mounted read-write, but the process lacks the necessary permissions to write to the root of the volume.
- ✓
The write will fail with a permission denied error because the emptyDir volume is owned by root and the container runs as user 1000.
Why this is correct
By default, an emptyDir volume is created with ownership root:root and permissions 0755. Since the container process runs as user 1000 and group 3000, it lacks write permission on the volume root. Without a fsGroup setting to change ownership or permissions, the write will fail with a permission denied error.
- ✗
The write will succeed because runAsUser and runAsGroup automatically change the ownership of mounted volumes.
Why it's wrong here
runAsUser and runAsGroup only set the UID and GID for the container process; they do not alter the ownership of mounted volumes. Volume ownership is controlled by fsGroup or by the volume plugin. Therefore, setting these fields does not grant write access to a root-owned emptyDir.
- ✗
The write will succeed because emptyDir volumes are always writable by any user.
Why it's wrong here
emptyDir volumes are initially created with permissions based on the pod's securityContext, but they are not automatically writable by any user. The volume's ownership and permissions are set by the kubelet, often to root:root with 0755 unless fsGroup is specified. A non-root user may not have write access, so this statement is incorrect.
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 →
JA
Written and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official CNCF exam blueprint
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.