Application Deployment →hardMultiple Choice

CKAD Application Deployment Practice Question

You have a HorizontalPodAutoscaler (HPA) that targets CPU utilization at 50%. The current average CPU utilization is 80%. The HPA has a stabilization window of 300 seconds and a scale-down policy with a periodSeconds of 60. CPU utilization drops to 40%. How long will it take for the HPA to begin scaling down?

⚠ Common exam trap

CKAD often tests the distinction between stabilization windows and scaling policies — candidates confuse periodSeconds (policy evaluation frequency) with the stabilization window (look-back period) and incorrectly add them together.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

After 300 seconds

The HPA will begin scaling down after 300 seconds because the stabilization window for scale-down is set to 300 seconds. During this window, the HPA evaluates all recommended replica counts and selects the highest one, effectively delaying any scale-down action until the window expires. Even though CPU dropped to 40% (below the 50% target), the stabilization window prevents premature scale-down.

Answer analysis

Option-by-option breakdown

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

✓
After 300 seconds
Why this is correct
The correct scale-down timing is 300 seconds because the HorizontalPodAutoscaler always applies the scale-down stabilization window before reducing replicas. This window, defaulting to 300 seconds, prevents the controller from reacting to short-lived CPU drops that might be transient, ensuring that the number of pods is only decreased after the low utilization is consistently observed. Once the stabilization window has passed, the HPA reevaluates the desired replica count and performs the scale-down.
✗
Immediately
Why it's wrong here
Scaling down immediately is prevented by the HPA's stabilization window, which exists to avoid the thundering herd problem and oscillation. CPU utilization often fluctuates momentarily due to load spikes, garbage collection, or pod startup; without a delay, the HPA would shed replicas too hastily, causing performance degradation as new load arrives. The controller deliberately withholds any scale-down behavior until the stabilization window (300 seconds) has elapsed, even if the current metric is far below the target.
✗
After 60 seconds
Why it's wrong here
The 60-second mark is not the correct time for the first scale-down because 60 seconds refers to the `periodSeconds` in the HPA's scale-down policy, not the delay before scaling. The stabilization window (300 seconds) takes precedence and dictates when scale-down may begin, while the `periodSeconds` controls how many replicas can be removed per interval after the window has passed. Therefore, a scale-down action taken at 60 seconds would violate the stabilization window and be rejected by the controller.
✗
After 360 seconds
Why it's wrong here
360 seconds is longer than the stabilization window and would unnecessarily delay the scale-down action. The stabilization window is fixed at 300 seconds, after which the HPA is allowed to start removing replicas; the `periodSeconds` value (60 seconds) is not an additional waiting period but rather a rate limiter that determines the maximum number of pods that can be scaled down in a single oscillation. Thus, the action occurs at 300 seconds, not 360 seconds.

Go deeper

CKAD Application Deployment Practice Question

Why each option matters

Option-by-option breakdown

Related to this question