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.

• ✗

  Configure a CloudWatch alarm on DatabaseConnections that triggers an Amazon CloudWatch Events rule, which directly modifies the DB instance class using a CloudFormation custom resource.

  Why it's wrong here

  Amazon CloudWatch Events (now EventBridge) does not have a direct target that can modify an RDS instance class; its targets are services like Lambda, SNS, and Systems Manager, not CloudFormation. A CloudFormation custom resource would require a separate trigger-handling Lambda or SNS function to perform the RDS ModifyDBInstance call, adding needless complexity and latency. This approach is not a supported pattern for real-time metric-driven scaling, and the custom resource lifecycle is designed for provisioning resources, not for making ad-hoc modifications to existing DB instances.

• ✗

  Use an AWS Config rule to monitor DatabaseConnections and invoke an AWS Lambda function to scale the RDS instance when the threshold is breached.

  Why it's wrong here

  AWS Config rules are designed to evaluate resource configuration attributes (such as tags, encryption, or backup settings) against compliance policies, not to process near-real-time CloudWatch metrics like DatabaseConnections. The DatabaseConnections value is emitted as a metric and is not a configuration property of the RDS instance, so a Config rule cannot directly observe it. Even a custom AWS Config rule would rely on configuration changes or a periodic schedule, making it unsuitable for responding immediately to connection-count threshold breaches.

• ✓

  Set up an Amazon CloudWatch alarm on the DatabaseConnections metric that triggers an AWS Lambda function to modify the DB instance class via the RDS API.

  Why this is correct

  Correct: you create a CloudWatch alarm on DatabaseConnections with a threshold (e.g., high connections for 5 minutes); when it enters ALARM, it sends a notification to an SNS topic that triggers a Lambda function, or uses an alarm action to invoke Lambda directly. The Lambda function calls the RDS ModifyDBInstance API with the desired DBInstanceClass and the DBInstanceIdentifier, and RDS performs the scaling. This is an event-driven, low-latency pattern that requires no polling and is a supported, commonly used approach for automated RDS instance-class scaling.

• ✗

  Use an AWS Systems Manager Automation runbook to periodically check the DatabaseConnections metric and adjust the RDS instance class if needed.

  Why it's wrong here

  Systems Manager Automation runbooks require a trigger, such as a schedule or manual execution, and cannot continuously monitor a metric in real time; a periodic check means the scaling action will lag by the polling interval. You would have to create a custom runbook that first reads GetMetricData and then calls ModifyDBInstance, which is unnecessarily complex and still not event-driven. CloudWatch alarms provide immediate notification-based scaling, so relying on SSM Automation adds latency and complexity without any benefit for this use case.