CKAD Application Observability and Maintenance 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.

• ✓

  Run 'kubectl rollout restart deployment/deployment-name'

  Why this is correct

  kubectl rollout restart deployment/deployment-name performs a rolling restart by adding a temporary annotation to the pod template, which forces the Deployment controller to create a new ReplicaSet and progressively swap old pods for new ones. This ensures zero downtime, as new pods are fully ready before old ones are terminated, and crucially, the new pods will read the updated ConfigMap from the API server at container startup. It is the cleanest, most declarative way to push a ConfigMap change to an existing Deployment.

• ✗

  Delete the pods manually and let the ReplicaSet recreate them

  Why it's wrong here

  Manually deleting the pods with kubectl delete pod is risky because if you delete all replicas at once, the ReplicaSet will recreate them, but there is a temporary period where zero pods serve traffic, causing downtime. Even if you delete them one-by-one, this is an ad-hoc, error-prone process that lacks the orchestrator's rolling update logic, which checks readiness before proceeding. Manual deletion also offers no rollback safety, unlike a rollout restart that leaves the previous ReplicaSet intact for a quick revert.

• ✗

  Delete the ConfigMap and recreate it with the same name

  Why it's wrong here

  Deleting the ConfigMap before updating it is dangerous because any running pods that mount it via a volume may encounter errors if the file disappears, and any new pods spun up by the ReplicaSet will fail to mount the volume entirely. Kubernetes resolves ConfigMap references at pod creation, so the pod template will be rendered with a missing ConfigMap, placing the deployment in an unhealthy state. The correct sequence is to update the ConfigMap with kubectl edit or apply first (in-place), then trigger a rollout to pick up the new data—never delete it.

• ✗

  Edit the Deployment to add an annotation, triggering a rollout

  Why it's wrong here

  Editing the Deployment to add an annotation does technically trigger a rolling update because any change to the pod template qualifies as a spec change, but this is an indirect workaround that introduces an arbitrary annotation with no functional purpose. It works, but it clutters the Deployment's metadata and is less discoverable than kubectl rollout restart, which is a dedicated, self-explanatory command for this exact scenario. Additionally, if the annotation is placed in the wrong location (e.g., on the Deployment itself rather than the pod template), no rollout will occur at all.

Go deeper

Related to this question