SOA-C02 Monitoring, Logging, and Remediation 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.

• ✓

  Check the scaling activity history in the Auto Scaling group for any errors or cooldown periods.

  Why this is correct

  Scaling activity history is the authoritative log of every scaling action the Auto Scaling group attempted or skipped. It records events such as policy executions, cooldown period blocks, and failures (e.g., insufficient instance capacity or unhealthy instances). If no scaling action was logged despite high CPU, that directly reveals whether the alarm-to-policy path was broken or a cooldown suppressed the action, making it the correct first place to diagnose why the group did not scale out.

• ✗

  Ensure that the EC2 instances are passing the ELB health checks.

  Why it's wrong here

  ELB health checks determine whether registered EC2 instances are considered healthy and receive traffic; if an instance fails them, Auto Scaling may replace it, but this process is entirely independent of CloudWatch alarm-based dynamic scaling. CPUUtilization-based scaling policies rely solely on EC2 metric data from CloudWatch, not on ELB health status. Ensuring instances pass ELB health checks might keep the fleet at desired capacity, but it cannot explain why the scaling policy failed to trigger during a CPU spike.

• ✓

  Review the scaling policy's cooldown period and threshold settings.

  Why this is correct

  The scaling policy's cooldown period (default 300 seconds) prevents additional scaling actions from being taken until the cooldown expires, so a recent scaling event can suppress an otherwise valid scale-out action. Additionally, the policy's thresholds—how much the metric must exceed and for how long—determine whether the alarm condition is met. If the cooldown is too long or thresholds are set higher than the actual workload ever reaches, the policy will never fire, making this review essential for diagnosing the lack of scaling.

• ✓

  Verify that the CloudWatch alarm associated with the scaling policy is in ALARM state when CPU is high.

  Why this is correct

  For a dynamic scaling policy to act, the associated CloudWatch alarm must first transition to ALARM state, which then invokes the policy via an SNS topic or direct integration. Without an alarm in ALARM state, the Auto Scaling group has no trigger to execute the scaling policy, regardless of CPU levels. You should inspect the alarm's state, period, evaluation periods, and its association with the scaling policy, plus confirm the underlying CPU metric is being emitted without delays or missing data points.

• ✗

  Manually increase the desired capacity to see if the scaling policy takes effect.

  Why it's wrong here

  Manually adjusting desired capacity directly changes the size of the Auto Scaling group, bypassing the CloudWatch alarm and scaling policy entirely, so it does not test whether the policy would activate on its own. In fact, manual changes can reset cooldown timers and mask the underlying issue because the desired capacity change creates a scaling activity that looks successful. The correct approach is to examine alarm history and scaling activity to understand why the automatic policy did not fire, rather than overriding the system.

Go deeper

Related to this question