Courseiva

CKAD Practice Question: Application Environment, Configuration and Security

You are a Kubernetes administrator responsible for a production cluster. A development team has deployed a Pod named 'app-pod' that runs a container with a PostgreSQL database. The team reports that the Pod is failing to start with an error: 'Error: container has runAsNonRoot and image will run as root (runtime error)'. The Pod YAML is as follows:

```yaml apiVersion: v1 kind: Pod metadata: name: app-pod spec: containers: - name: db image: postgres:latest securityContext: runAsNonRoot: true ```

The team wants to ensure the container runs securely without running as root. What is the BEST course of action?

⚠ Common exam trap

Many exam-takers think removing `runAsNonRoot` is the simplest fix, but the question explicitly requires the container to run securely without root, so the correct action is to specify a non-root user ID rather than disabling the security constraint.

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

Add `runAsUser: 999` to the container's securityContext to run the container as the postgres user.

The PostgreSQL official image runs as the 'postgres' user with UID 999 by default. Adding `runAsUser: 999` to the container's securityContext overrides the user to a non-root UID, satisfying the `runAsNonRoot: true` constraint and allowing the container to start without the runtime error.

Answer analysis

Option-by-option breakdown

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

  • Add `runAsUser: 999` to the container's securityContext to run the container as the postgres user.

    Why this is correct

    Setting `runAsUser: 999` explicitly instructs the kubelet to start the container process with UID 999, which is non-zero. This satisfies the `runAsNonRoot: true` validation because the runtime verifies that the effective UID is not 0. Since the Postgres image commonly defines a `postgres` user with UID 999, this aligns with the image's intended user and avoids running as root. This is the standard, least-privilege fix for a `runAsNonRoot` enforcement failure.

  • Remove `runAsNonRoot: true` from the securityContext to allow the container to run as root.

    Why it's wrong here

    Deleting `runAsNonRoot: true` would disable the security check and allow the container to start as UID 0 (root). However, this anti-pattern violates the Pod Security Standard and increases the risk of container breakout and privilege escalation. Moreover, if a cluster-level Pod Security Admission restricted policy is enforced, removing the flag alone will not prevent the pod from being rejected—the Pod must still conform to the policy. This does not solve the underlying security requirement and is not an appropriate remediation.

  • Increase the Pod's resource limits because the error is due to insufficient memory.

    Why it's wrong here

    The error that triggers `runAsNonRoot` enforcement is a validation failure of the securityContext, not an out-of-memory condition. Insufficient memory would manifest as `OOMKilled`, failed scheduling due to insufficient resources, or a `CreateContainerConfigError` with a different cause. Elevating resource limits or requests does not influence the UID validation performed by the kubelet, so this change would leave the Pod stuck in a failed state. It misidentifies the error class and provides no benefit.

  • Create a PodSecurityPolicy that allows running as root.

    Why it's wrong here

    PodSecurityPolicy is deprecated and removed in Kubernetes v1.25, so creating one may have no effect on newer clusters. Even if it were active, a PSP that permits root would lower the security posture of the entire namespace, and it still does not overwrite the explicit `runAsNonRoot: true` in the Pod spec—the Pod would still fail its own securityContext validation. The immediate, targeted fix is to adjust the Pod's securityContext to run as a non-root user, rather than making a cluster-wide policy exception.

About these practice questions

One of 160 original CKAD practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →

How Courseiva writes practice questions · Editorial policy

JA

Written by Johnson Ajibi, MSc IT Security

Senior Network & Security Engineer · founder of Courseiva

This CKAD 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 CKAD exam.