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.

• ✗

  Amazon CloudWatch alarm with an Auto Scaling policy.

  Why it's wrong here

  Auto Scaling policies are tightly coupled to EC2 Auto Scaling groups; they adjust the desired, minimum, or maximum instance counts of those groups. RDS DB instances are managed database servers rendered through the RDS service, not members of an Auto Scaling group, so an Auto Scaling policy cannot reference an RDS instance ID nor execute a reboot action against it. RDS offers its own scaling features (e.g., storage auto-scaling, read replica auto-scaling) that are not surfaced as CloudWatch alarm actions.

• ✗

  Amazon CloudWatch alarm with an Amazon Simple Notification Service (SNS) topic that triggers an AWS Lambda function to restart the instance.

  Why it's wrong here

  This approach works in principle but forces you to author, test, and operate a custom AWS Lambda function that calls the rds.reboot_db_instance API, along with associated IAM roles and error-handling logic. The Lambda path also requires a separate CloudWatch alarm-to-SNS subscription and a reliable SNS-to-Lambda trigger, adding latency and more moving parts to a simple remediation. Because the correct managed alternative exists, the additional code and maintenance are unnecessary operational overhead for a routine restart operation.

• ✓

  Amazon CloudWatch alarm with an AWS Systems Manager Automation action.

  Why this is correct

  CloudWatch alarms support a native 'Systems Manager Automation' action that directly invokes an SSM automation runbook, such as the pre-built AWS-RestartRDSInstance runbook, when the alarm enters an alarm state. This runbook encapsulates the RDS reboot API call and includes appropriate wait/verify steps, all without requiring you to write or maintain any custom code. The integration is purpose-built for metric-driven remediation and is the minimal-effort, fully managed way to automatically restart an RDS DB instance.

• ✗

  Amazon RDS event subscription that triggers an AWS Lambda function.

  Why it's wrong here

  RDS event subscriptions are designed to notify you of database lifecycle events (e.g., failover started, maintenance completed, patching) rather than to react to CloudWatch metric thresholds such as DatabaseConnections. The DatabaseConnections metric is a CloudWatch metric, not an RDS event, so an event subscription would never trigger under the described condition unless you separately configured a CloudWatch alarm and published those states as events, which is not what an RDS event subscription does. Lambda-based handling here would still require extra custom logic and does not directly address the metric-based trigger this scenario requires.