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: Check current state of the Deployment and existing Pods. Step 2: Scale the Deployment to 5 replicas using 'kubectl scale'. Step 3: Watch the Pods being created using 'kubectl get pods --watch'. Step 4: Confirm the number of replicas is 5 using 'kubectl get deployment'. Step 5: Inspect events for any errors using 'kubectl describe deployment' or 'kubectl get events'.

  Why this is correct

  Establishing a baseline with kubectl get deployment and kubectl get pods before scaling lets you see pre-existing conditions and know the starting replica count, so any issues you later see in events can be correctly attributed to the scale operation. The kubectl scale command updates the deployment's .spec.replicas field, and kubectl get pods --watch captures pod creation events in real time as the ReplicaSet controller responds. Verifying with kubectl get deployment confirms the DESIRED column shows 5, while kubectl describe deployment or kubectl get events surfaces any scheduling, image-pull, or resource errors that occurred during rollout. This order moves from inspection to action to observation to verification to troubleshooting, which is the logically sound sequence.

• ✗

  Step 1: Scale the Deployment to 5 replicas. Step 2: Watch the Pods being created. Step 3: Confirm the number of replicas is 5. Step 4: Inspect events for any errors. (Omit checking current state.)

  Why it's wrong here

  Omitting the initial check of the deployment's current state means you have no baseline, so you cannot tell whether a crash-looping or pending pod was already present before you scaled or was caused by scaling. If the deployment already had 5 replicas, scaling to 5 is a no-op that wastes time, and without that baseline you might assume the command caused a change that never happened. Worse, if there were pre-existing errors, you would see them after scaling and wrongly blame your action. A proper workflow always starts with observation of the starting state before applying any change.

• ✗

  Step 1: Check current state. Step 2: Immediately confirm the number of replicas (without scaling). Step 3: Scale the Deployment. Step 4: Watch Pods. Step 5: Inspect events.

  Why it's wrong here

  Confirming the replica count before scaling is premature because it will simply show the old count, giving you no useful information since you haven't yet changed anything. After that you scale, then watch, then confirm—but you've already wasted a step and, more importantly, skipped the meaningful baseline check that should happen before scaling. The correct order is to check current state first (to establish the baseline), then scale, then watch the rollout, then verify the new count, then inspect events for errors. Placing the confirmation before the scale action breaks the cause-and-effect logic of monitoring the change.

• ✗

  Step 1: Watch Pods continuously. Step 2: Scale the Deployment. Step 3: Check current state. Step 4: Confirm the number of replicas. Step 5: Inspect events.

  Why it's wrong here

  Watching pods before running kubectl scale is pointless because no new pods will appear, so you'll be idly watching a static list and might even miss the exact moment the scale command triggers new creations if you're not paying attention. Checking the current state after scaling is backwards: the state has already been changed by the scale operation, so you cannot determine what was present before or whether any observed issues are pre-existing or introduced by scaling. The baseline check must happen first, and the watch must start after the scale command is issued to catch the rollout event stream. This sequence conflates the observation and verification steps, making it impossible to accurately monitor the effect of your action.

Go deeper

Related to this question