DOP-C02 Incident and Event Response 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.

• ✓

  The cooldown period is set too high.

  Why this is correct

  The cooldown period is a deliberate delay after a scaling activity before the group can launch or terminate additional instances. If set too high, it suppresses subsequent scaling actions for an extended time, so the group cannot keep pace with rapidly increasing demand. For a dynamic scaling policy, this directly prevents the Auto Scaling group from adding instances promptly, making scaling appear slow. Thus, an excessively high cooldown is a valid cause of the described problem.

• ✗

  The health check grace period is set too low.

  Why it's wrong here

  The health check grace period is the time Auto Scaling waits after an instance enters service before performing health checks, so it only affects the detection and replacement of unhealthy instances. Setting it too low can cause instances to be prematurely marked unhealthy and terminated, leading to churn, but it does not directly slow down scaling activities. In fact, this parameter is unrelated to the timing of launch or terminate actions triggered by dynamic scaling policies, making it an incorrect explanation for slow scaling.

• ✗

  The minimum group size is set too low.

  Why it's wrong here

  The minimum group size only sets the lower bound on the number of instances in the Auto Scaling group; it does not govern how quickly instances are launched. Scaling speed is determined by the scaling policy type (e.g., step or target tracking), cooldown periods, instance warm-up settings, and the time required for new instances to become healthy. A low minimum might even allow the group to be smaller than desired, but it does not delay or slow the launch process itself, so it is not a cause of sluggish scaling.

• ✗

  The launch template has a long warm-up time.

  Why it's wrong here

  AWS Auto Scaling does not support a 'warm-up time' parameter on a launch template; launch templates define the instance configuration (AMI, instance type, user data, etc.) and have no bearing on scaling timing. The concept of warm-up in Auto Scaling applies to scaling policies (e.g., target tracking policy warm-up) and the group-level default instance warm-up, not to the launch template itself. Therefore, this option is incorrect because it references a non-existent parameter that could not slow scaling activity.

Go deeper

Related to this question