CKS Monitoring, Logging and Runtime Security Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  securityContext: { runAsNonRoot: true }

  Why it's wrong here

  This setting enforces that the container process has a numeric user ID other than 0, either by using the image's user or causing a runtime error if the user is root. However, a non-root user with sufficient filesystem permissions (e.g., uid 1000 in a custom image) can still create, modify, or delete files in the container's writable layer. The root filesystem remains mounted read-write, so runAsNonRoot does not satisfy the requirement of a read-only filesystem.

• ✗

  securityContext: { privileged: false }

  Why it's wrong here

  Setting privileged: false explicitly places the container in standard (non-privileged) mode — also the default — meaning the container cannot access host devices directly or gain extended Linux capabilities beyond the configured set. This reduces the attack surface but has no effect on how the root filesystem is mounted; the container can still write to its writable layer. It is neither a privilege-escalation control nor a filesystem-mount option, so it does not establish read-only behavior.

• ✗

  securityContext: { capabilities: { drop: ["ALL"] } }

  Why it's wrong here

  Dropping all capabilities removes kernel privileges such as CAP_NET_BIND_SERVICE, CAP_CHOWN, or CAP_DAC_OVERRIDE, which limits certain privileged operations, but writes to a container's filesystem are governed by filesystem permissions, mount options, and UID mappings rather than the capability set alone. If the container runs as root and the root filesystem is writable, dropping capabilities may still allow file modifications depending on the exact image layer permissions and user namespace configuration. The writable mount remains unchanged, so this option does not enforce a read-only root filesystem.

• ✓

  securityContext: { readOnlyRootFilesystem: true }

  Why this is correct

  Setting readOnlyRootFilesystem: true causes the container runtime to mount the container's root filesystem as read-only, so the write layer is not writable from the container's perspective; any attempt to modify an existing file or create a new file in the root directory tree will fail with EROFS. This directly prevents an attacker who compromises the container from persisting changes in the container layer, though ephemeral writes can still be accommodated by mounting volumes (e.g., emptyDir) at specific paths such as /tmp. It is the only option among those listed that enforces the filesystem-level read-only requirement.

Go deeper

Related to this question