SOA-C02 Monitoring, Logging, and Remediation Practice Question

A SysOps administrator is setting up monitoring for an RDS MySQL database. The administrator needs to be notified when the database connection count exceeds 100. Which steps should be taken to achieve this? (Choose TWO.)

⚠ Common exam trap

Watch out — candidates often confuse Enhanced Monitoring (which provides OS-level metrics) with CloudWatch metrics (which provide database-level metrics like connection counts), leading them to incorrectly select Enhanced Monitoring as a solution for connection-based alarms.

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

✓

Configure the CloudWatch alarm to send a notification to an SNS topic.

Amazon CloudWatch alarms can send notifications to an Amazon SNS topic when the alarm state changes. This allows the SysOps administrator to receive alerts (e.g., via email, SMS, or HTTP) when the database connection count exceeds the threshold. Option B is correct because the 'DatabaseConnections' metric is a standard CloudWatch metric for RDS MySQL that tracks the number of current connections to the database instance. Creating an alarm on this metric with a threshold of 100 will trigger when the connection count exceeds that value.

Answer analysis

Option-by-option breakdown

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

✓
Configure the CloudWatch alarm to send a notification to an SNS topic.
Why this is correct
A CloudWatch alarm alone does nothing until you attach an action; publishing to an SNS topic is the standard action that enables out-of-band notification. When the alarm enters ALARM state, it sends a message to the SNS topic, which then delivers via email, SMS, or Lambda. This is the notification layer of the solution, not the metric collection itself.
✓
Create a CloudWatch alarm on the 'DatabaseConnections' metric.
Why this is correct
The DatabaseConnections metric is published by RDS to CloudWatch as a per-instance value representing the current number of client network connections. Creating a CloudWatch alarm on this metric allows you to set a threshold and evaluation period, so the alarm state changes when connection count breaches that threshold. This is the actual monitoring mechanism that detects the condition you care about.
✗
Enable Enhanced Monitoring for RDS.
Why it's wrong here
Enhanced Monitoring streams OS-level metrics such as CPU, memory, and disk I/O to CloudWatch Logs using a separate agent on the RDS instance, but it does not report DatabaseConnections. The metric you need for connection count is only available in the standard RDS CloudWatch namespace, not from the Enhanced Monitoring console. Therefore, enabling it would give you deep OS insight but no visibility into connection count.
✗
Enable CloudTrail to log RDS API calls.
Why it's wrong here
CloudTrail records management API calls made to RDS, such as CreateDBInstance or DeleteDBInstance, and is used for security auditing and governance. It operates at the control plane, so it never captures runtime data-plane metrics like the number of open database connections. Thus, enabling CloudTrail would provide an audit trail of administrative actions, not connection monitoring.
✗
Create an Amazon EventBridge rule that triggers on RDS events.
Why it's wrong here
EventBridge rules can react to RDS service events emitted on a status change (for example, failover or backup completion), but they cannot evaluate CloudWatch metric thresholds directly. Metric evaluation is a CloudWatch alarms feature; EventBridge lacks the logic to compare the DatabaseConnections value against a threshold. So a rule on RDS events would not trigger a notification for a connection spike.

Go deeper

SOA-C02 Monitoring, Logging, and Remediation Practice Question

Why each option matters

Option-by-option breakdown

Related to this question