CKAD Services and Networking Practice Question

Answer analysis

Option-by-option breakdown

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

• ✓

  Define Pod YAML with container specs and emptyDir volume, mount volume in each container, apply with kubectl, then test.

  Why this is correct

  The Pod manifest must declare the emptyDir volume at the pod level under `spec.volumes` and reference that volume from each container's `volumeMounts` before submission. Applying the complete manifest atomically creates the pod with the shared volume already wired, and only then can you exec in or curl to verify containers write and read the same files. Because emptyDir is ephemeral and tied to the pod's lifecycle, you must define it in the initial apply—there is no runtime step that can retroactively create it.

• ✗

  Define Pod YAML with container specs and volume mounts (but no volume definition), apply, then add emptyDir volume definition and re-apply.

  Why it's wrong here

  Submitting a Pod manifest whose `volumeMounts` reference a volume name not declared under `spec.volumes` causes the API server to reject the apply with a validation error, so the plan stalls before any pod exists. Reapplying after patching in the volume definition does not retroactively fix the original submission; you must replace the whole manifest and re-apply. This also wastes a cycle and would fail in a scripted pipeline because the first kubectl apply exits nonzero.

• ✗

  Define Pod YAML with container specs and emptyDir volume, apply, then edit the running Pod to mount the volume in each container.

  Why it's wrong here

  `kubectl edit` on a running Pod can change container images or env vars, but volume mounts are immutable once the pod is created; the API server rejects modifications to `spec.containers[*].volumeMounts` (and also `spec.volumes`) on live pods. To add a mount you must delete the pod and recreate it from a fully specified YAML, and any short-lived container files would be lost. This option's ordering misunderstands that pod spec is partially immutable after scheduler placement.

• ✗

  Define Pod YAML with container specs, mount volume in each container, then add emptyDir volume definition, then apply.

  Why it's wrong here

  The order here attempts to add the volume definition after the mounts in the YAML, but YAML is interpreted as one document; the API server resolves both `volumeMounts` and `volumes` together from the same manifest, not sequentially. A mount that references a non-existent volume triggers a validation error at submit time regardless of the textual order of keys. So the option is functionally identical to a missing volume definition—the volume must exist in the same manifest, not be "added" after the mount keys.

Go deeper

Related to this question