DOP-C02 Configuration Management and IaC 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.

• ✗

  Create a CloudWatch alarm that triggers a scaling policy.

  Why it's wrong here

  While it is true that Elastic Beanstalk scaling triggers use CloudWatch alarms, you do not manually create a separate CloudWatch alarm to trigger a scaling policy. The alarm is generated automatically when you define the scaling trigger in the Elastic Beanstalk configuration, along with the metric, threshold, and breach duration. Manually creating a CloudWatch alarm outside of the trigger configuration is redundant and not a required step in setting up autoscaling.

• ✓

  Set the minimum and maximum number of instances for the auto scaling group.

  Why this is correct

  Setting the minimum and maximum number of instances for the Auto Scaling group is an absolute prerequisite for any elastic scaling in Elastic Beanstalk. These values define the allowed capacity range that the Auto Scaling group can scale within, and without them the Auto Scaling group cannot adjust its size. Every scaling activity, whether scale-out or scale-in, must respect these boundaries, making this a mandatory configuration element.

• ✗

  Configure the load balancer health check interval.

  Why it's wrong here

  The load balancer health check interval is an Elastic Load Balancing (ELB) setting that controls how often the load balancer checks the health of registered instances. It influences traffic routing and instance replacement for failed health checks, but it is not used by the Auto Scaling group's scaling policy. The scaling trigger is based on CloudWatch metrics like average CPU utilization, not on the load balancer health check cadence.

• ✓

  Set the scale-up and scale-down cooldown periods.

  Why this is correct

  Setting scale-up and scale-down cooldown periods is a critical part of an Elastic Beanstalk autoscaling configuration because it controls how long the Auto Scaling group waits after a scaling activity before applying another one. These cooldown times prevent rapid and unnecessary fluctuations by allowing newly launched instances to start serving traffic or terminated instances to finish draining before metrics are reevaluated. Proper cooldown values ensure stability and cost efficiency, and they are required to define a fully functional scaling policy.

• ✓

  Define a scaling trigger based on average CPU utilization.

  Why this is correct

  Defining a scaling trigger based on average CPU utilization establishes the actual condition that initiates scaling. You specify the metric, the threshold (e.g., CPUUtilization > 75% for 5 minutes), and the breach duration, which together determine when the Auto Scaling group adds or removes instances. This trigger is what converts the min/max capacity settings into an active scaling policy, so it is explicitly required when you want to scale dynamically based on CPU load.

Go deeper

Related to this question