SOA-C02 Monitoring, Logging, and Remediation Practice Question

Exhibit

Refer to the exhibit.

# CloudFormation snippet
Resources:
  MyInstance:
    Type: AWS::EC2::Instance
    Properties:
      ImageId: ami-0abcdef1234567890
      InstanceType: t2.micro
      Monitoring: true
      UserData:
        Fn::Base64: !Sub |
          #!/bin/bash
          yum install -y httpd
          systemctl start httpd
          systemctl enable httpd
  MyAlarm:
    Type: AWS::CloudWatch::Alarm
    Properties:
      AlarmDescription: CPU alarm
      Namespace: AWS/EC2
      MetricName: CPUUtilization
      Statistic: Average
      Period: 300
      EvaluationPeriods: 1
      Threshold: 80
      ComparisonOperator: GreaterThanThreshold
      Dimensions:
        - Name: InstanceId
          Value: !Ref MyInstance
      AlarmActions:
        - !Ref MySNSTopic

Refer to the exhibit. A SysOps administrator deploys this CloudFormation stack. The EC2 instance launches and the web server starts. However, the CloudWatch alarm does not trigger even when CPU utilization exceeds 80%. What is the MOST likely reason?

⚠ Common exam trap

A common mix-up: candidates assume any CPU utilization above the threshold will trigger an alarm, overlooking how the chosen statistic (Average vs. Maximum) and evaluation period affect whether a spike is detected.

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 alarm statistic should be 'Maximum' instead of 'Average' to catch CPU spikes that may not sustain the average above 80% for 5 minutes.

The alarm is configured with the 'Average' statistic, which smooths out CPU utilization over the 5-minute period. If CPU utilization spikes above 80% but does not sustain an average above that threshold for the entire duration, the alarm will not trigger. Using the 'Maximum' statistic would catch any single data point exceeding 80% within the period, making it appropriate for detecting short-lived spikes.

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 alarm action is missing a valid SNS topic ARN.
Why it's wrong here
The alarm action uses `!Ref MySNSTopic`, which is a CloudFormation intrinsic function that resolves to the ARN of the SNS topic resource defined in the template. As long as the topic is defined and in the same stack, the reference is valid. The alarm can publish to the topic even if the instance's user data script fails, because the alarm is based on the CPUUtilization metric which is always reported by EC2. Additionally, the alarm is properly configured with an action, so the ARN is not missing.
✓
The alarm statistic should be 'Maximum' instead of 'Average' to catch CPU spikes that may not sustain the average above 80% for 5 minutes.
Why this is correct
With a 5-minute period and the Average statistic, short-lived CPU spikes can be averaged out, so the metric may remain below 80% even though the instance is repeatedly spiking above the threshold. The Maximum statistic samples the highest value during each period, so any sustained spike in a 5-minute window will breach the threshold. For autoscaling or alerting on CPU exhaustion, Maximum is recommended to catch transient spikes that would otherwise be smoothed by averaging.
✗
The alarm dimension is incorrect; it should use the instance's private IP.
Why it's wrong here
The CloudWatch metric `AWS/EC2` `CPUUtilization` uses the `InstanceId` dimension, not the private IP. The dimension uniquely identifies the instance for that metric. Using a private IP would cause the alarmed metric to be empty or invalid, so the alarm would not evaluate correctly. The `InstanceId` is already correctly specified via `!Ref WebServerInstance` in the template.
✗
The user data script fails to start the web server, causing the instance to be unhealthy.
Why it's wrong here
The user data script failing to start the web server would affect HTTP health checks or application status, but it has no bearing on the CPUUtilization CloudWatch metric. The CPU metric is always published by the EC2 hypervisor regardless of installed services. Even if the web server is down, the instance can continue to report CPU usage, so the alarm condition is independent of the web server status.

Go deeper

SOA-C02 Monitoring, Logging, and Remediation Practice Question

Exhibit

Why each option matters

Option-by-option breakdown

Related to this question