CKAD Application Design and Build 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.

• ✓

  1. Define the Deployment in YAML, 2. Apply the YAML using kubectl apply, 3. Modify the YAML for the update, 4. Re-apply the modified YAML using kubectl apply

  Why this is correct

  This is the correct sequence for a declarative Kubernetes workflow. You first author a valid Deployment manifest that captures the desired state, then use `kubectl apply` to create the resource in the cluster. When you need to update, you edit the same YAML and re-apply it; `kubectl apply` computes a diff and submits a new Deployment revision, which causes the Deployment controller to perform a rolling update by gradually replacing Pods from the old ReplicaSet with the new one. No manual Pod deletion or extra commands are needed.

• ✗

  1. Define the Deployment in YAML, 2. Modify the YAML for the update, 3. Apply the YAML using kubectl apply

  Why it's wrong here

  This order skips the initial apply, so the Deployment is never created before the update step. Without a pre-existing Deployment, `kubectl apply` on the modified YAML would simply create a Deployment from scratch with the updated spec, not perform a controlled rolling update from a previous version. In a real rollout workflow you must establish the original manifest as the baseline by applying it first; otherwise the deployment history and the ability to roll back to the previous revision are lost.

• ✗

  1. Define the Deployment in YAML, 2. Apply the YAML using kubectl apply, 3. Delete the existing Pods manually, 4. Re-apply the modified YAML using kubectl apply

  Why it's wrong here

  Manually deleting Pods in this sequence is redundant and harmful because the Deployment controller continuously reconciles the actual state to the desired state. If you delete Pods before re-applying the modified YAML, the ReplicaSet will immediately recreate Pods using the old template, causing unnecessary churn and potential downtime. Once you re-apply the modified Deployment YAML, Kubernetes automatically triggers a rolling update that replaces Pods in a controlled manner with zero manual intervention.

• ✗

  1. Apply an empty or placeholder YAML, 2. Define the Deployment in YAML, 3. Modify the YAML for the update, 4. Re-apply the YAML using kubectl apply

  Why it's wrong here

  Applying an empty or placeholder YAML before defining the actual Deployment is invalid and will not result in a usable resource. `kubectl apply` requires a complete manifest containing `apiVersion`, `kind`, `metadata`, and a valid spec; an empty file fails validation, while a placeholder with a resource kind but no meaningful spec would create an incomplete object or be rejected by the API server. The proper sequence must begin with writing the fully defined Deployment YAML, and then applying it; you cannot apply a resource that you have not yet specified.

Go deeper

Related to this question