SOA-C02 Monitoring, Logging, and Remediation Practice Question

A SysOps administrator is troubleshooting an issue where an Amazon RDS DB instance's storage space is running out. The administrator has enabled CloudWatch alarms for FreeStorageSpace, but the alarm did not trigger before the storage was exhausted. What is the most likely reason?

⚠ Common exam trap

Candidates often assume CloudWatch alarms trigger instantly when a metric crosses a threshold, but in reality, alarms require multiple data points over the evaluation period to change state, which can delay detection if storage fills rapidly.

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's evaluation period was too long and the storage filled up faster than the alarm could trigger.

CloudWatch alarms evaluate metrics based on a specified evaluation period (e.g., 5 minutes). If the storage fills up faster than the alarm's evaluation period, the alarm may not have enough data points to trigger before the storage is exhausted. This is a common issue when the rate of storage consumption exceeds the alarm's evaluation frequency.

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 FreeStorageSpace metric is not available for the selected DB instance class.
Why it's wrong here
The FreeStorageSpace metric is a standard RDS CloudWatch metric that is emitted for every DB instance class, from db.t3.micro to db.r5.24xlarge, across all storage types (gp2, gp3, provisioned IOPS). A lack of disk space alarms cannot be caused by the instance class omitting this metric; if the metric were unavailable, the alarm would stay in INSUFFICIENT_DATA, not fail to trigger when storage actually filled.
✗
The alarm was configured to use a static threshold but the metric is not emitted during storage operations.
Why it's wrong here
CloudWatch alarms evaluate the latest available metric points against a threshold regardless of whether a static or anomaly-detection threshold is used. FreeStorageSpace is published continuously (typically every 60 seconds for RDS), including during storage operations, so the metric cannot be 'not emitted' during writes or other I/O. The alarm's threshold type and metric emission schedule are unrelated to the delayed trigger.
✓
The alarm's evaluation period was too long and the storage filled up faster than the alarm could trigger.
Why this is correct
An evaluation period (the number of consecutive 60-second periods the metric must breach the threshold before the alarm enters ALARM state) lengthens the required detection time. If the database's storage fills up completely within, say, 15 minutes, an alarm configured with 10 evaluation periods at 5-minute periods would need 50 minutes of data and thus never fire before the instance goes read-only. Shortening the evaluation period and using a threshold well above zero (e.g., 10% free space) avoids this pitfall.
✗
The alarm was monitoring the wrong metric, such as 'Storage' instead of 'FreeStorageSpace'.
Why it's wrong here
Amazon RDS exposes a FreeStorageSpace metric measured in bytes, but it does not expose a standard metric simply named 'Storage'. If you mistakenly monitored a custom or non-existent metric, the alarm would never receive data points and would remain in INSUFFICIENT_DATA instead of entering ALARM. Since the described issue is an alarm that failed to trigger on an existing storage problem, the correct fix is to use FreeStorageSpace with a suitable threshold, not to point at a nonexistent 'Storage' metric.

Go deeper

SOA-C02 Monitoring, Logging, and Remediation Practice Question

Why each option matters

Option-by-option breakdown

Related to this question