SOA-C02 Monitoring, Logging, and Remediation Practice Question

A company uses Amazon RDS for MySQL with Multi-AZ deployment. The SysOps administrator notices that the DB instance's CPU utilization spikes to 100% every few minutes. CloudWatch alarms have been set to trigger when CPU exceeds 90% for 5 minutes, but no alarm state changes are observed. The administrator checks the CloudWatch metrics and sees that the CPU utilization metric shows periodic spikes but they last only 2-3 minutes each. What is the most likely cause and what should the administrator do to receive notifications?

⚠ Common exam trap

Test-takers frequently assume the alarm should trigger because the metric exceeds the threshold, but they overlook the requirement that the breach must persist for the entire evaluation period, not just momentarily.

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

✓

Set the alarm to evaluate over 1 minute instead of 5 minutes.

The CPU utilization spikes last only 2-3 minutes, which is shorter than the alarm's evaluation period of 5 consecutive minutes. Since the alarm requires the metric to exceed the 90% threshold for 5 minutes before triggering, these brief spikes never satisfy the alarm's duration condition. Setting the alarm to evaluate over 1 minute will match the spike duration and allow the alarm to trigger on these short-lived bursts.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✓
Set the alarm to evaluate over 1 minute instead of 5 minutes.
Why this is correct
A CloudWatch alarm with a 5-minute period averages all CPUUtilization samples in that window, so a brief spike in utilization can be smoothed out and never crosses the threshold. Changing the period to 1 minute, which matches the standard metric publishing interval for RDS, ensures the short spike is evaluated as a discrete data point. That is the correct fix for detecting short-duration CPU spikes.
✗
The Multi-AZ failover is causing the spikes; disable Multi-AZ.
Why it's wrong here
Multi-AZ failover does not happen periodically while the primary instance is healthy; failover is a one-time event driven by the console, maintenance, or an infrastructure failure. During failover you would see a brief connection drop and a noticeable outage, not recurring CPUUtilization spikes. Even if failover were somehow correlated, disabling Multi-AZ would eliminate the synchronous standby and automatic failover protection, which is the wrong remediation for a metric-alarm tuning question.
✗
The DB instance is not publishing CPU metrics at a high enough resolution.
Why it's wrong here
Amazon RDS for MySQL publishes CPUUtilization to CloudWatch every 60 seconds as standard-resolution data, so the metric is available at 1-minute granularity. The actual issue is that the alarm's 5-minute period collapses those samples into an average, hiding the spike; the metric stream itself is not under-resolved. You can confirm this in the console by switching the monitor graph to 1-minute statistics and seeing the spikes plainly.
✗
The CPU metric is not accurate; use the CPU credit metric instead.
Why it's wrong here
CPUUtilization is an accurate metric produced by the DB instance, and the graph shows real CPU consumption caused by the workload. CPU credit metrics like CPUCreditBalance and CPUCreditUsage are published only for burstable instance types (for example, db.t3 or db.t4g) and indicate credit usage, not instantaneous CPU percentage. Substituting those metrics would not reveal short-duration CPU spikes; the underlying problem is the alarm evaluation period.

Go deeper

SOA-C02 Monitoring, Logging, and Remediation Practice Question

Why each option matters

Option-by-option breakdown

Related to this question