SOA-C02 Monitoring, Logging, and Remediation Practice Question

Answer analysis

Option-by-option breakdown

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

• ✗

  Metric: DBConnections; Threshold: 80

  Why it's wrong here

  The value "DBConnections" is not a published CloudWatch metric for any Amazon RDS engine. The actual metric is named `DatabaseConnections` with a capital "D" and "Connections", and CloudWatch metric names are case-sensitive, so an alarm referencing `DBConnections` will fail validation or never find real data. Even if the name were corrected, the fixed threshold of 80 would not account for the instance's `max_connections` configuration, making it inappropriate for detecting near-limit connection usage.

• ✗

  Metric: DatabaseConnections; Threshold: 80

  Why it's wrong here

  `DatabaseConnections` is the correct metric name, but using a literal threshold of 80 is misleading because `max_connections` is dynamic: it depends on the DB instance class and the DB parameter group settings (e.g., a small db.t3.micro might allow only about 66 connections while a large db.r5 instance allows thousands). As a result, a fixed absolute value like 80 can generate false alarms on smaller instances or never alarm on larger ones. The threshold must be relative to the actual `max_connections` parameter for that specific instance, not a constant.

• ✗

  Metric: FreeableMemory; Threshold: 20%

  Why it's wrong here

  `FreeableMemory` reports the amount of available RAM on the RDS host, not the number of active client connections, so it cannot indicate whether the connection limit is being approached. Furthermore, CloudWatch alarms compare thresholds against the metric's numeric value, and a "20%" value would need to be converted to an absolute byte count or wrapped in a metric math expression — but even then it measures memory pressure, which can be caused by buffer pools, cache usage, or queries, not just connection saturation. This option mistakes a possible side effect of resource exhaustion for the direct connection metric.

• ✓

  Metric: DatabaseConnections; Threshold: 0.8 * max_connections (using a math expression)

  Why this is correct

  The correct alarm should use the `DatabaseConnections` metric in a metric math expression that compares current connections to 80% of the `max_connections` value. Because `max_connections` is not emitted as a standard RDS CloudWatch metric, you can publish it as a custom metric (updated by a script that reads the DB parameter group) and create an expression like `m1 > 0.8 * m2` to compute the threshold dynamically. This approach self-adjusts if the instance class or parameter group is changed, avoiding the false positives and negatives that come with hard-coded thresholds while targeting the exact `DatabaseConnections` metric that tracks session count.

Go deeper

Related to this question