Application Environment, Configuration and Security →hardMultiple Select

CKAD Practice Question: Application Environment, Configuration and Security

You are troubleshooting a Pod that cannot start because it fails with 'Error: container has runAsNonRoot and image will run as root'. The Pod's SecurityContext has 'runAsNonRoot: true' and no explicit 'runAsUser'. Which three actions could resolve this? (Choose three.)

⚠ Common exam trap

Candidates often think setting 'runAsGroup' or 'readOnlyRootFilesystem' can indirectly fix the user mismatch, but neither changes the effective UID, so they do not resolve the runAsNonRoot violation.

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

✓

Remove 'runAsNonRoot: true' from the SecurityContext.

Removing 'runAsNonRoot: true' eliminates the constraint that the container image must run as a non-root user. Since the image runs as root by default and no 'runAsUser' is set, the Pod fails. Removing the flag allows the container to start with its default root user.

Answer analysis

Option-by-option breakdown

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

✓
Remove 'runAsNonRoot: true' from the SecurityContext.
Why this is correct
The 'runAsNonRoot: true' field tells the kubelet to reject the pod if the container would start as UID 0. Because this image runs as root by default, that validation triggers the failure. Removing the flag disables the admission-time check and lets the container start with root privileges, though it also drops this particular security hardening control.
✗
Set 'readOnlyRootFilesystem: true' in the SecurityContext.
Why it's wrong here
This setting mounts the container's root filesystem as read-only, but it does nothing to change the UID the process runs with. The kubelet's runAsNonRoot verification still looks at the effective UID; even with a read-only filesystem, a process running as root would still be rejected. It addresses write permissions, not user identity, so it cannot fix the startup failure.
✓
Use a container image that runs as a non-root user by default.
Why this is correct
When the container image defines a non-root numeric USER (for example, USER 1000) in its Dockerfile, the kubelet sees a non-zero UID and allows the pod even with runAsNonRoot: true. This resolves the issue at the image level without weakening the pod's security context. The trade-off is that you must either switch to a compatible image or rebuild the image to explicitly specify a non-root user.
✗
Set 'runAsGroup: 3000' in the SecurityContext.
Why it's wrong here
The runAsGroup field changes only the primary group ID (GID) of the container process and does not affect the UID. The runAsNonRoot check specifically validates that the effective user ID is not zero; a process with GID 3000 can still be running as root (UID 0) and will be rejected. Therefore, this setting does not address the root-user condition causing the failure.
✓
Set 'runAsUser: 1000' in the SecurityContext.
Why this is correct
Setting runAsUser to 1000 explicitly overrides the image's default USER and forces the container process to run with UID 1000. Since 1000 is a non-zero UID, it satisfies the runAsNonRoot requirement and the pod is allowed to start. This is a targeted, direct fix that preserves the security control rather than removing it.

Visual reference

Go deeper

CKAD Practice Question: Application Environment, Configuration and Security

Why each option matters

Option-by-option breakdown

Related to this question