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.

• ✗

  The command fails with an error because the container has an immutable root filesystem

  Why it's wrong here

  The readOnlyRootFilesystem field only makes the container's root mount read-only; it does not prevent the runtime from launching a process. The kubectl exec command delegates to the container runtime's exec handler, which locates the requested binary in the container's writable layer or mounted filesystem and executes it. An immutable root filesystem would only cause failure if the shell binary itself were missing or could not be executed, not because the filesystem is read-only.

• ✗

  The shell starts and can write to any directory because 'exec' bypasses the restriction

  Why it's wrong here

  The container runtime enforces the read-only root mount for every process within the container's mount namespace, including those spawned by exec. When you exec into a container, the new process joins the same mount and PID namespace and thus sees the same root filesystem mounted with the same flags. The exec channel only transmits stdin/stdout/stderr and the command; it cannot lift kernel-mandated mount restrictions, so any write attempt outside explicitly mounted writable volumes is still denied.

• ✓

  The shell starts successfully, but any attempt to write to the root filesystem will be denied

  Why this is correct

  A successful kubectl exec starts a shell only if the container image contains that shell binary; the readOnlyRootFilesystem flag does not block process creation. Once the shell is running, it inherits the container's read-only root mount, meaning operations like touch /file or redirecting output to /root/out.txt will fail with a read-only file system error. Only paths backed by writable volumes defined in the pod spec, such as emptyDir or a mounted persistent volume, will accept writes.

• ✗

  The pod is restarted with a writable filesystem

  Why it's wrong here

  Exec does not trigger a Pod lifecycle change; it injects an ephemeral process into an existing container. The Pod's securityContext is fixed at creation time, and the kubelet does not recreate the Pod merely because a user runs kubectl exec. To change readOnlyRootFilesystem, you must edit the Pod's securityContext and recreate the Pod, which would be a separate explicit operation rather than an automatic restart.

Go deeper

Related to this question