CKAD Practice Question: Application Environment, Configuration and Security

Answer analysis

Option-by-option breakdown

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

• ✓

  Step 1: Create ConfigMap from file, Step 2: Define Pod YAML with volume and volumeMount, Step 3: Apply the Pod manifest, Step 4: Verify the ConfigMap mount in the Pod

  Why this is correct

  The correct sequence begins with `kubectl create configmap` (e.g., `--from-file`) so that the ConfigMap object actually exists in the namespace before any Pod references it. Next, the Pod YAML defines a `configMap` volume and a corresponding `volumeMount` pointing at a directory; `mountPath` receives the data keys as files. Applying the manifest (Step 3) is what causes the API server to create the Pod and resolve the volume reference, and only after the Pod is Running can you verify the mount with commands like `kubectl exec` or inspecting `/etc/config`.

• ✗

  Step 1: Define Pod YAML with volume and volumeMount, Step 2: Create ConfigMap from file, Step 3: Apply the Pod manifest, Step 4: Verify the ConfigMap mount in the Pod

  Why it's wrong here

  Because the Pod's volume definition references the ConfigMap by name, the ConfigMap must already be present in the cluster for the volume to resolve; authoring the YAML first forces you to reference an object that may not exist yet, and if you apply at that point the Pod is rejected. Even if you later create the ConfigMap before applying, this order is fragile: any key names used in the volumeMount must match data that already exists, so the safer, correct practice is to create the ConfigMap first to establish the file names and keys. The exam sequence expects the dependency to be satisfied before the manifest is written, not after.

• ✗

  Step 1: Create ConfigMap from file, Step 2: Apply the Pod manifest, Step 3: Define Pod YAML with volume and volumeMount, Step 4: Verify the ConfigMap mount in the Pod

  Why it's wrong here

  This order is impossible to execute as written: `kubectl apply -f pod.yaml` (Step 2) requires the YAML file to already exist on disk, but Step 3 defines the manifest after the apply command has already run. You cannot submit a manifest that hasn't been authored yet, because kubectl reads the file or stdin at apply time and sends it to the API server; with no file present the command errors immediately. Defining the Pod YAML after the apply step inverts the logical dependency—the manifest is the input to the apply command, so it must be written first.

• ✗

  Step 1: Verify the ConfigMap mount in the Pod, Step 2: Create ConfigMap from file, Step 3: Define Pod YAML with volume and volumeMount, Step 4: Apply the Pod manifest

  Why it's wrong here

  Verification is an observation step that can only be performed after the ConfigMap and the Pod both exist; at the point Step 1 runs, there is no ConfigMap and no Pod, so `kubectl get`/`describe`/`exec` would report NotFound and the mount path would not exist. The container with the `volumeMount` hasn't been scheduled or started, so there is no filesystem to inspect. Correct validation happens only after apply: you can exec into the container, run `ls` on the mountPath, or `kubectl describe pod` to confirm the volume is mounted, all of which are impossible before resource creation.