Courseiva

SOA-C02 Monitoring, Logging, and Remediation Practice Question

A SysOps administrator notices that an EC2 instance's CPU utilization is consistently above 90% during business hours. The instance is part of an Auto Scaling group with a scaling policy based on average CPU utilization. Despite high utilization, no scaling events are triggered. What is the most likely cause?

⚠ Common exam trap

Candidates often assume a scaling policy will always trigger when the CloudWatch alarm is in ALARM state, overlooking the cooldown period as a deliberate throttling mechanism that can prevent scaling activities from being initiated.

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

✓

The scaling policy has a cooldown period that is too long, preventing new scaling activities.

The most likely cause is that the scaling policy has a cooldown period that is too long. After a scaling activity completes, the Auto Scaling group enters a cooldown period that prevents additional scaling activities from being triggered until the cooldown expires. If the cooldown period is set too long (e.g., 600 seconds or more), the group will not launch new instances even if the CloudWatch alarm remains in ALARM state with high CPU utilization, because the scaling policy is blocked from executing.

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 scaling policy has a cooldown period that is too long, preventing new scaling activities.

    Why this is correct

    The scaling policy's cooldown period intentionally suppresses scaling actions for a set duration after the previous activity. If that cooldown is excessively long, it overrides the high CPU metric by preventing new scaling operations until the cooldown expires, so the Auto Scaling group cannot add instances even though the alarm remains in ALARM. This directly explains why no new instances launch despite sustained high utilization.

  • ✗

    The instance type is not supported by the Auto Scaling group's launch configuration.

    Why it's wrong here

    An unsupported or unavailable instance type in the launch configuration would cause instance launch failures or errors, not a failure to trigger the scaling policy. The CloudWatch alarm for CPU utilization would still fire and invoke the scaling policy, but the subsequent launch request would fail. Since the symptom is no scaling activity at all, this does not account for the absence of a policy execution based on the CPU metric.

  • ✗

    The CloudWatch alarm is in the ALARM state but the Auto Scaling group has a suspended process for Add instances.

    Why it's wrong here

    If the Add instances process is suspended, the Auto Scaling group will ignore any scaling-out actions, regardless of the alarm state. However, a suspended process is a deliberate administrative action that would appear in the group's status, and the question implies the policy itself is not firing. Moreover, the alarm reaching ALARM is a direct result of high CPU, not a cause that would prevent scaling, so this option misattributes the alarm's role.

  • ✗

    The Auto Scaling group's health check type is set to ELB, causing the instance to be marked unhealthy.

    Why it's wrong here

    The ELB health check type determines how the Auto Scaling group evaluates instance health for replacement or deregistration, but it has no bearing on the CloudWatch alarm that monitors CPU utilization. An instance marked unhealthy would be terminated and replaced, yet that does not stop the scaling policy from adding capacity when the CPU threshold is breached. Therefore, this setting cannot prevent new scaling activities triggered by high CPU; it only affects lifecycle management.

About these practice questions

This SOA-C02 question is part of Courseiva's 1,169-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →

How Courseiva writes practice questions · Editorial policy

JA

Written by Johnson Ajibi, MSc IT Security

Senior Network & Security Engineer · founder of Courseiva

This SOA-C02 practice question is part of Courseiva's free Amazon Web Services certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the SOA-C02 exam.