CKAD Timed Hard Questions — 25 Difficult Questions

Question 1

You need to create a Pod that mounts a Secret named 'mysecret' as an environment variable 'SECRET_DATA'. The secret has a key 'password'. Which YAML snippet correctly achieves this?

Accepted Answer

env:
- name: SECRET_DATA
  valueFrom:
    secretKeyRef:
      name: mysecret
      key: password. Option B is correct because it uses the `secretKeyRef` field under `valueFrom` to reference a specific key from a Secret named 'mysecret' and inject its value into the environment variable `SECRET_DATA`. This is the standard Kubernetes syntax for exposing a Secret's key-value pair as an environment variable.

Answer

env:
- name: SECRET_DATA
  valueFrom:
    configMapKeyRef:
      name: mysecret
      key: password

Answer

env:
- name: SECRET_DATA
  valueFrom:
    secretKeyRef:
      name: password
      key: mysecret

Answer

volumeMounts:
- name: secret-volume
  mountPath: /etc/secret
volumes:
- name: secret-volume
  secret:
    secretName: mysecret
    items:
    - key: password
      path: secret.txt

Question 2

A security requirement states that a container must run with a read-only root filesystem. Which field must be set in the container's securityContext?

Accepted Answer

readOnlyRootFilesystem: true. Setting `readOnlyRootFilesystem: true` in the container's `securityContext` enforces that the container's root filesystem is mounted as read-only, preventing any writes to the filesystem at the root level. This satisfies the security requirement by ensuring that even if a process is compromised, it cannot modify system binaries, configuration files, or other critical files within the container's root filesystem.

Answer

runAsUser: 1000

Answer

capabilities:
  drop: ["ALL"]

Answer

allowPrivilegeEscalation: false

Question 3

A pod must run with a seccomp profile that only allows specific syscalls. Which SecurityContext field is used to specify the seccomp profile type?

Accepted Answer

seccompProfile. Option D is correct because `seccompProfile` is the field within the Pod or container `SecurityContext` that specifies the seccomp profile type (e.g., `RuntimeDefault`, `Localhost`, or `Unconfined`). This field was introduced in Kubernetes v1.19 (beta) and replaces the older annotation-based seccomp configuration, allowing you to define the profile type directly in the pod spec.

Answer

appArmorProfile

Answer

seLinuxOptions

Answer

seccomp

Question 4

A ConfigMap named 'env-config' has keys 'DB_HOST' and 'DB_PORT'. A pod needs to set the environment variable 'DATABASE_HOST' to the value of 'DB_HOST' from the ConfigMap, and 'DB_PORT' directly as 'DB_PORT'. Which YAML snippet correctly achieves this?

Accepted Answer

env:
- name: DATABASE_HOST
  valueFrom:
    configMapKeyRef:
      name: env-config
      key: DB_HOST
envFrom:
- configMapRef:
    name: env-config. Option B is correct: for 'DATABASE_HOST', it uses valueFrom with configMapKeyRef mapping key 'DB_HOST' to the env var. For 'DB_PORT', it uses envFrom with configMapRef to load all keys. Option A uses envFrom for both, but that would not rename 'DB_HOST'. Option C uses envFrom for DATABASE_HOST, which won't rename. Option D uses env with configMapKeyRef for DB_PORT, but then envFrom overrides it? Actually, order matters: envFrom is processed after env, so env would be overwritten. But the correct approach is to use env for the renamed variable and envFrom for the rest.

Answer

env:
- name: DB_PORT
  valueFrom:
    configMapKeyRef:
      name: env-config
      key: DB_PORT
envFrom:
- configMapRef:
    name: env-config

Answer

envFrom:
- configMapRef:
    name: env-config
env:
- name: DATABASE_HOST
  value: DB_HOST

Answer

envFrom:
- configMapRef:
    name: env-config
  prefix: DATABASE_

Question 5

A Pod is configured with securityContext: { runAsUser: 1000, runAsGroup: 2000, fsGroup: 3000 }. The container's image runs a process that must listen on a TCP port below 1024 (e.g., port 80). The process is currently failing to start. What should you modify to allow the process to bind to a privileged port?

Accepted Answer

Add 'capabilities.add: [NET_BIND_SERVICE]' to the container's securityContext. Option C is correct. When a container runs as a non-root user (runAsUser: 1000), it cannot bind to ports below 1024. Adding the NET_BIND_SERVICE capability to the container's capabilities allows it to bind to privileged ports without being root. Dropping all capabilities is not necessary.

Answer

Set 'allowPrivilegeEscalation: true'

Answer

Add 'capabilities.drop: [ALL]' to the container's securityContext

Answer

Set runAsUser: 0 to run as root

Question 6

A cluster administrator wants to enforce that no pod in namespace 'prod' uses more than 4Gi of memory. Which Kubernetes resource should be created?

Accepted Answer

LimitRange. Option C is correct because a LimitRange resource in the 'prod' namespace can set a default memory limit and a maximum memory limit per container or pod, enforcing that no pod exceeds 4Gi of memory. This is the appropriate Kubernetes primitive for per-pod resource constraints within a namespace, as it applies to all pods that do not specify their own limits.

Answer

PodDisruptionBudget

Answer

NetworkPolicy

Answer

ResourceQuota

Question 7

You have a pod that needs to mount a Secret as a volume. The Secret has keys 'username' and 'password'. How should the volumes and volumeMounts be configured to mount the secret at /etc/secret with each key as a file?

Accepted Answer

volumes:
- name: secret-vol
  secret:
    secretName: my-secret
containers:
- volumeMounts:
  - name: secret-vol
    mountPath: /etc/secret. Option D is correct because it uses the `secret` volume type with `secretName: my-secret`, which mounts the specified Kubernetes Secret as a volume. When mounted at `/etc/secret`, each key in the Secret (e.g., 'username' and 'password') becomes a file in that directory, with the file name matching the key and the file content being the decoded value of the key. This is the standard method for exposing Secret data as files in a pod.

Answer

volumes:
- name: secret-vol
  hostPath:
    path: /etc/secret
containers:
- volumeMounts:
  - name: secret-vol
    mountPath: /etc/secret

Answer

volumes:
- name: secret-vol
  configMap:
    name: my-secret
containers:
- volumeMounts:
  - name: secret-vol
    mountPath: /etc/secret

Answer

volumes:
- name: secret-vol
  emptyDir: {}
containers:
- volumeMounts:
  - name: secret-vol
    mountPath: /etc/secret

Question 8

You want to apply a Pod Security Admission (PSA) policy that enforces the 'restricted' profile in the 'dev' namespace, but only for Pods that are not exempt. Which TWO steps are required? (Select TWO)

Accepted Answer

Set the label 'pod-security.kubernetes.io/enforce=restricted' on the namespace. Option A is correct because setting the label 'pod-security.kubernetes.io/enforce=restricted' on the namespace instructs the Pod Security Admission controller to reject any Pod that does not meet the restricted profile, unless the Pod is exempt (e.g., system-critical Pods or those with specific exemptions). This label directly enforces the policy at admission time, ensuring only compliant Pods are created in the 'dev' namespace.

Answer

Add a 'securityContext' field to the Pod template with 'runAsUser: 1000'

Answer

Set the label 'pod-security.kubernetes.io/enforce=baseline' on the namespace

Answer

Set the label 'pod-security.kubernetes.io/warn=restricted' on the namespace

Question 9

A container image requires a seccomp profile that is not the default. The cluster supports the RuntimeDefault seccomp profile. Which Pod securityContext field should be configured to use the RuntimeDefault seccomp profile?

Accepted Answer

seccompProfile:
  type: RuntimeDefault. Option A is correct because the `seccompProfile` field under the Pod's `securityContext` is the proper way to specify a seccomp profile in Kubernetes. Setting `type: RuntimeDefault` tells the container runtime (e.g., containerd or CRI-O) to use the default seccomp profile provided by the runtime, which is a secure baseline that blocks around 44 system calls while allowing common ones like `read`, `write`, and `exit`. This field was introduced in Kubernetes 1.19 (GA in 1.22) and is the standard approach for configuring seccomp at the Pod or container level.

Answer

seccomp:
  type: RuntimeDefault

Answer

capabilities:
  add: [SECCOMP]

Answer

securityContext:
  seccomp:
    type: Unconfined

Question 10

A namespace 'dev' has a ResourceQuota that sets 'requests.cpu: 4' and 'limits.cpu: 8'. A pod is created with a container that has 'resources.requests.cpu: 1' and 'resources.limits.cpu: 3'. However, the pod remains in Pending state. The output of 'kubectl describe quota -n dev' shows 'used requests.cpu: 3.5' and 'used limits.cpu: 7'. What is the most likely reason the pod is pending?

Accepted Answer

The pod's CPU limit exceeds the remaining quota.. The ResourceQuota in namespace 'dev' has a limit of 8 CPUs for limits.cpu, with 7 already used, leaving only 1 CPU remaining. The pod's container requests a limit of 3 CPUs, which exceeds the available 1 CPU, causing the scheduler to reject the pod and leave it in Pending state. ResourceQuota enforcement occurs at admission time, and the scheduler will not schedule a pod that would cause the namespace to exceed its quota limits.

Answer

The pod's CPU request exceeds the remaining quota.

Answer

The pod's memory request is not set.

Answer

The namespace does not have a LimitRange set.

Question 11

You want to enforce a Pod Security Standard of 'restricted' in a namespace. Which command applies the correct label?

Accepted Answer

kubectl label namespace my-ns pod-security.kubernetes.io/enforce=restricted. Option B is correct because Pod Security Standards are enforced by applying a label with the key `pod-security.kubernetes.io/enforce` to a namespace. The value `restricted` sets the most restrictive Pod Security Standard, which prevents pods from running with privileged access or insecure capabilities. This label is part of the built-in Pod Security Admission (PSA) controller, which replaced PodSecurityPolicy in Kubernetes v1.23+.

Answer

kubectl label namespace my-ns psp=restricted

Answer

kubectl annotate namespace my-ns pod-security.kubernetes.io/enforce=restricted

Answer

kubectl label namespace my-ns pod-security.kubernetes.io/audit=restricted

Question 12

You need to create a Pod that runs with a specific non-root user (UID 1000), prevents privilege escalation, and mounts the container's filesystem as read-only. Which securityContext field is NOT required to achieve these requirements?

Accepted Answer

runAsGroup: 1000. Option B (runAsGroup: 1000) is not required because the requirement only specifies a non-root user (UID 1000) and does not mandate a specific group ID. The runAsGroup field sets the primary group for the container's processes, but it is optional; without it, the container will use the default group associated with the user or the container's default group. The other options are necessary: runAsUser: 1000 sets the user, readOnlyRootFilesystem: true makes the filesystem read-only, and allowPrivilegeEscalation: false prevents privilege escalation.

Answer

runAsUser: 1000

Answer

readOnlyRootFilesystem: true

Answer

allowPrivilegeEscalation: false

Question 13

A Pod is configured with automountServiceAccountToken: false. The application inside the pod needs to access the Kubernetes API. What should be done?

Accepted Answer

Mount the service account token manually by adding a volume and volumeMount. Setting automountServiceAccountToken: false prevents automatic mounting of the service account token. To still access the Kubernetes API, you must manually mount the token by adding a volume of type projected (or secret) containing the service account token, and a corresponding volumeMount in the container. This allows the application to authenticate with the API server using the mounted token.

Answer

Create a new Secret of type kubernetes.io/dockerconfigjson

Answer

The application cannot access the API; the setting is final

Answer

Add a ConfigMap with the token

Question 14

A pod in a namespace with a ResourceQuota that sets 'requests.cpu: 2' is failing to schedule. The pod manifest specifies 'resources: { requests: { cpu: "500m" } }'. What is the likely cause?

Accepted Answer

The namespace has already used all its CPU request quota.. The ResourceQuota sets a hard limit of 2 CPU cores for total requests across all pods in the namespace. If the sum of CPU requests from all pods already reaches or exceeds 2, a new pod with a 500m CPU request cannot be scheduled because it would exceed the quota. The pod's request (500m) is well within the quota limit, so the issue is that the namespace has exhausted its CPU request budget.

Answer

The ResourceQuota applies to limits, not requests.

Answer

The pod does not specify a CPU limit.

Answer

The pod's CPU request exceeds the ResourceQuota limit.

Question 15

A pod is failing to start with error 'container has runAsNonRoot and image will run as root'. The container image runs as root. Which change allows the pod to run?

Accepted Answer

Set runAsUser to a non-zero UID, e.g., 1000. Option B is correct: set runAsUser to a non-zero ID to run as non-root, satisfying runAsNonRoot. Option A removes the check but may be insecure. Option C does not change user. Option D is not valid.

Answer

Remove runAsNonRoot: true from securityContext

Answer

Add fsGroup: 1000

Answer

Set allowPrivilegeEscalation: false

Question 16

A container image requires running as UID 0 but you need to comply with a 'restricted' Pod Security Admission policy. Which SecurityContext setting allows this while still passing the policy?

Accepted Answer

No SecurityContext setting allows running as UID 0 under the restricted policy.. The 'restricted' Pod Security Admission policy requires that containers run as non-root (runAsNonRoot: true) and prohibits setting runAsUser to 0. Since the image requires UID 0, no SecurityContext setting can override this policy constraint; the only way to comply is to modify the image to run as a non-root user. Therefore, option B is correct.

Answer

Set securityContext: { allowPrivilegeEscalation: true }

Answer

Set securityContext: { runAsNonRoot: true, capabilities: { add: ['SYS_ADMIN'] } }

Answer

Set runAsUser: 0 and runAsNonRoot: false

Question 17

You need to configure a liveness probe that checks if the container port 8080 is open. Which probe type should you use?

Accepted Answer

tcpSocket. A tcpSocket probe is the correct choice when you need to verify that a container is listening on a specific TCP port, such as port 8080. It works by attempting to open a TCP connection to the specified port; if the connection succeeds, the probe is considered successful. This is ideal for checking basic network-level readiness or liveness without requiring an HTTP endpoint or a custom command.

Answer

grpc

Answer

exec

Answer

httpGet

Question 18

You have a Deployment with 3 replicas. The pods have a readiness probe that checks an HTTP endpoint /ready. One pod's readiness probe is failing. What will happen?

Accepted Answer

The pod will be removed from the Service endpoints. If a pod fails its readiness probe, it is removed from the Service endpoints. The pod remains running and is not restarted. Option B is correct. Option A is wrong because liveness probes cause restarts. Option C is incorrect because readiness failure does not decrease replicas. Option D is wrong.

Answer

The pod will be restarted by the kubelet

Answer

The Deployment will create a new pod to maintain 3 replicas

Answer

The pod will be terminated gracefully

Question 19

You have a Deployment with a liveness probe using an exec command. The probe currently runs 'cat /tmp/healthy' and fails after 3 failures. You notice the pod is being restarted even though the application is healthy. What is the most likely cause?

Accepted Answer

The file /tmp/healthy does not exist or is not being updated by the application. Option C is correct because the liveness probe executes 'cat /tmp/healthy' and fails after 3 consecutive failures. If the file /tmp/healthy does not exist or is not being updated by the application, the command returns a non-zero exit code, causing the probe to fail and Kubernetes to restart the container even though the application process itself is running and healthy.

Answer

The readiness probe is misconfigured and is shutting down the pod

Answer

The liveness probe is using the wrong HTTP endpoint

Answer

The probe timeoutSeconds is set too low, causing the probe to fail before the command completes

Question 20

You want to configure a pod so that it receives a SIGTERM signal and has 60 seconds to shut down gracefully before being forcefully killed. Which field should you set?

Accepted Answer

terminationGracePeriodSeconds: 60. The 'terminationGracePeriodSeconds' field sets the time between SIGTERM and SIGKILL. Setting it to 60 gives 60 seconds for graceful shutdown. Option A is correct. Option B is for preStop hook, not the grace period. Option C is for probes. Option D is for resource limits.

Answer

lifecycle.preStop.exec.command with sleep 60

Answer

livenessProbe.initialDelaySeconds: 60

Answer

resources.limits.cpu