CKAD Exam Simulation — 100 Questions

Question 1

Match each Kubernetes concept to its definition.

Question 2

Arrange the steps to create a multi-container Pod with a shared volume.

Question 3

A pod has been scheduled on a node but is stuck in 'ContainerCreating' state. The team suspects a missing storage class. Which command would best confirm this?

Accepted Answer

kubectl describe pod . Option D is correct because `kubectl describe pod ` provides detailed event logs and status conditions for the pod, including specific error messages like 'failed to provision volume with StorageClass' or 'storageclass.storage.k8s.io "" not found'. This directly confirms whether a missing storage class is the root cause of the 'ContainerCreating' state, as the pod's events will surface the exact provisioning failure.

Answer

kubectl describe node

Answer

kubectl get pvc

Answer

kubectl get storageclass

Question 4

A developer is creating a Deployment with 4 replicas. The application requires a rolling update with zero downtime. Which TWO strategies ensure zero downtime during an update?

Accepted Answer

Set maxSurge=1. Option A is correct because setting maxSurge=1 allows Kubernetes to spin up one new Pod before terminating any old Pod during a rolling update. This ensures that the total number of available Pods never drops below the desired replica count, maintaining service capacity and achieving zero downtime.

Answer

Set maxUnavailable=1

Answer

Use Recreate strategy

Answer

Set maxSurge=0

Question 5

A developer creates a Deployment with 3 replicas that uses a ConfigMap mounted as a volume. After updating the ConfigMap, the developer expects the pods to pick up the new configuration immediately, but the old configuration is still in use. What is the most likely reason?

Accepted Answer

The kubelet sync interval delays the propagation of ConfigMap changes to pods.. When a ConfigMap is mounted as a volume, updates to the ConfigMap are eventually propagated to the pods, but not instantly. The kubelet periodically syncs mounted ConfigMaps (default interval is 60 seconds), so there is a delay before pods see the new configuration. This is the most likely reason the old configuration is still in use.

Answer

ConfigMap updates are not propagated to mounted volumes.

Answer

The pods must be recreated after a ConfigMap update to see the changes.

Answer

ConfigMaps are immutable and cannot be updated.

Question 6

Which TWO statements about Kustomize are true?

Accepted Answer

Kustomize supports overlays that allow different configurations for different environments.. Kustomize supports overlays, which are layered patches applied on top of a base configuration. This allows you to define a common base set of Kubernetes resources and then use different overlay directories (e.g., dev, staging, prod) to customize settings like replicas, image tags, or namespaces for each environment without duplicating the entire manifest.

Answer

Kustomize can be used to perform canary deployments.

Answer

Kustomize requires Helm to manage dependencies.

Answer

Kustomize can only be used with kubectl apply -k.

Question 7

A developer creates a Secret using the command: 'kubectl create secret generic db-secret --from-literal=password=myPass'. Which way to consume this Secret in a pod is CORRECT?

Accepted Answer

env:
  - name: DB_PASSWORD
    valueFrom:
      secretKeyRef:
        name: db-secret
        key: password. Option A is correct because `secretKeyRef` under `valueFrom` in an `env` entry is the proper way to inject a single key from a Kubernetes Secret into a container environment variable. The Secret was created with key `password` and value `myPass`, so `secretKeyRef` with `name: db-secret` and `key: password` correctly references that key.

Answer

volumes:
  - name: secret-vol
    secret:
      secretName: db-secret
  containers:
    - volumeMounts:
        - name: secret-vol
          mountPath: /etc/secret

Answer

envFrom:
  - secretRef:
      name: db-secret

Answer

env:
  - name: DB_PASSWORD
    valueFrom:
      configMapKeyRef:
        name: db-secret
        key: password

Question 8

A namespace 'team-a' has a ResourceQuota that sets 'requests.cpu: 4' and 'limits.cpu: 8'. A developer tries to create a pod with 'resources.requests.cpu: 2' and 'resources.limits.cpu: 10'. What happens?

Accepted Answer

The pod is rejected because the limit (10) exceeds the quota's allowed limit. The pod is rejected because the ResourceQuota in namespace 'team-a' sets a hard limit of 8 CPUs for limits.cpu across all pods. The developer's pod specifies a limit of 10 CPUs, which exceeds this quota. Kubernetes enforces ResourceQuota at admission time, so any resource request or limit that violates the quota's constraints will cause the pod creation to be denied.

Answer

The pod is created because the request (2) is within the quota

Answer

The pod is created but its limit is automatically reduced to 8

Answer

The pod is created, but it will be evicted immediately

Question 9

A pod uses a ServiceAccount with automountServiceAccountToken set to false. The pod still needs to access the Kubernetes API. How can you mount the service account token in this pod?

Accepted Answer

Set automountServiceAccountToken: true in the pod spec. Option A is correct because setting `automountServiceAccountToken: true` in the pod spec overrides the ServiceAccount-level setting of `false`. This allows the pod to mount the service account token automatically, enabling it to authenticate to the Kubernetes API without manual intervention.

Answer

Create a secret with the token and mount it manually

Answer

Use a ConfigMap to store the token

Answer

Set serviceAccountName: default and automountServiceAccountToken: true in the pod spec

Question 10

You create a ConfigMap named 'app-config' with the command 'kubectl create configmap app-config --from-literal=key1=value1'. Which of the following correctly mounts this ConfigMap as environment variables in a pod?

Accepted Answer

envFrom:
  - configMapRef:
      name: app-config. Option D is correct because `envFrom` with `configMapRef` is the Kubernetes mechanism to expose all key-value pairs from a ConfigMap as environment variables in a pod. This directly mounts the ConfigMap created with `--from-literal=key1=value1` so that `key1` becomes an environment variable with value `value1`.

Answer

env:
  - name: key1
    valueFrom:
      configMapKeyRef:
        name: app-config
        key: key1

Answer

volumes:
  - name: config-volume
    configMap:
      name: app-config
volumeMounts:
  - name: config-volume
    mountPath: /etc/config

Answer

env:
  - name: key1
    valueFrom:
      configMapRef:
        name: app-config

Question 11

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 12

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 13

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 14

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 15

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 16

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 17

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 18

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 19

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 20

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