CKAD Timed Practice Test 2 — 10 Questions

Question 1

A developer wants to mount a ConfigMap as a volume in a Pod so that updates to the ConfigMap are reflected in the Pod without restarting. Which two statements are correct? (Choose two.)

Accepted Answer

Using subPath in the volume mount prevents automatic updates.. Option C is correct because when a ConfigMap is mounted using `subPath`, Kubernetes treats the mount as a single file rather than a directory of symlinks. This means the atomic update mechanism (which uses symlinks to swap the directory contents) is bypassed, and updates to the ConfigMap are not reflected in the Pod without a restart or remount.

Answer

Using envFrom to inject ConfigMap data as environment variables will update automatically.

Answer

ConfigMap updates are reflected immediately in the volume mount.

Answer

The Pod must be restarted for any ConfigMap change to take effect.

Question 2

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 3

Which THREE of the following are benefits of using a ResourceQuota in a namespace? (Select THREE)

Accepted Answer

It can enforce that every Pod has resource limits set. Option B is correct because a ResourceQuota can enforce that every Pod in the namespace has resource limits set by specifying the `limits.cpu` and `limits.memory` fields in the quota's `hard` spec. If a Pod is created without those limits, the API server will reject it, ensuring no Pod runs unbounded. This is distinct from setting default values, which is done by a LimitRange, not a ResourceQuota.

Answer

It sets default resource requests and limits for Pods that don't specify them

Answer

It restricts which users can create Pods in the namespace

Question 4

Which of the following is the correct way to set a CPU request of 250 millicores and a memory limit of 512 Mi in a container?

Accepted Answer

resources:
  requests:
    cpu: 250m
  limits:
    memory: 512Mi. Option D is correct because in Kubernetes, CPU requests are specified in millicores (e.g., 250m) and memory limits use binary units like Mi (Mebibytes). The value '250m' equals 0.25 CPU cores, and '512Mi' is 512 Mebibytes (512 * 1024^2 bytes), which is the standard unit for memory limits.

Answer

resources:
  requests:
    cpu: 250
  limits:
    memory: 512M

Answer

resources:
  requests:
    cpu: 250
  limits:
    memory: 512MB

Answer

resources:
  requests:
    cpu: 0.25
  limits:
    memory: 512MB

Question 5

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 6

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 7

A developer wants to ensure that a pod runs with a non-root user and cannot gain root privileges. Which SecurityContext settings should be used?

Accepted Answer

securityContext:
  runAsNonRoot: true
  allowPrivilegeEscalation: false. Option C is correct because setting `runAsNonRoot: true` enforces that the container's user ID is non-zero (non-root), and `allowPrivilegeEscalation: false` prevents the container from gaining additional privileges beyond its initial set, such as through setuid binaries or kernel capabilities. Together, they ensure the pod runs as a non-root user and cannot escalate to root, satisfying the developer's requirement.

Answer

securityContext:
  allowPrivilegeEscalation: false

Answer

securityContext:
  runAsNonRoot: true

Answer

securityContext:
  runAsNonRoot: true
  allowPrivilegeEscalation: true

Question 8

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 9

A pod has 'automountServiceAccountToken: false' in its spec. What is the effect?

Accepted Answer

The pod will not have the service account token mounted.. Setting `automountServiceAccountToken: false` in a Pod spec prevents the automatic injection and mounting of the service account token into the Pod's containers. By default, Kubernetes mounts a token at `/var/run/secrets/kubernetes.io/serviceaccount/token` for API authentication; disabling this option means the token is not mounted, but the Pod can still use a service account if the token is explicitly mounted via a volume or if the Pod does not need API access.

Answer

The pod cannot use any service account.

Answer

The pod will use a different service account.

Answer

The pod will be unable to start.

Question 10

A pod with the following security context is in CrashLoopBackOff. The container image runs as user 1000.

securityContext:
  runAsUser: 2000
  runAsGroup: 3000
  fsGroup: 4000

What is the most likely cause?

Accepted Answer

runAsUser is set to 2000, but the container expects to run as user 1000. The container image is built to run as user 1000, but the Pod's securityContext overrides this with runAsUser: 2000. When the container starts, it attempts to access files or resources that require user 1000 permissions, causing it to fail and enter CrashLoopBackOff. The mismatch between the image's default user and the securityContext's runAsUser is the most direct cause of the crash.

Answer

runAsGroup is set to 3000, but the container expects group 1000

Answer

The pod does not have enough CPU resources

Answer

fsGroup is set to 4000, causing volume mount permission issues