SOA-C02 Amazon CloudWatch Events (EventBridge) 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.

• ✓

  Create an Amazon CloudWatch Events rule that matches the 'RDS DB Instance Event' for 'failover' and sends the event to an Amazon SNS topic for notification and logging.

  Why this is correct

  Amazon CloudWatch Events (now part of Amazon EventBridge) natively integrates with RDS event notifications, emitting a structured event whenever a DB instance experiences a failover. By creating a rule that matches the 'RDS DB Instance Event' source and the specific detail type for failover, you can route that event to an SNS topic in near-real time, enabling automated alerting, logging, and downstream remediation. This is the intended, low-overhead approach because RDS already publishes these lifecycle events, and no polling or custom detection logic is required.

• ✗

  Enable detailed monitoring on the RDS instance and stream the logs to Amazon CloudWatch Logs where a metric filter can detect failover patterns.

  Why it's wrong here

  Detailed monitoring increases the frequency of CloudWatch metric collection (from 60-second to 5-second intervals) for CPU, memory, and I/O, but it does not emit any event or log entry specific to a failover. Streaming RDS logs (like error/general/slow query logs) to CloudWatch Logs with a metric filter can detect application-visible errors (e.g., connection resets), but it cannot reliably detect the internal failover event itself, and a metric filter pattern would have to guess at symptoms rather than directly observe the event, making this approach brittle and indirect.

• ✗

  Configure AWS CloudTrail to log all RDS API calls and analyze the logs for the 'Failover' event type.

  Why it's wrong here

  CloudTrail logs API calls made to the RDS service (e.g., modifying a DB instance). The internal failover process is not an API call initiated by the user; it is an automated action and is not recorded in CloudTrail.

• ✗

  Use AWS Config to create a config rule that evaluates whether the 'DBInstanceStatus' changes to 'failover' and then trigger a remediation action.

  Why it's wrong here

  AWS Config is designed to track resource configuration changes and evaluate compliance over time, but a DB instance's configuration (instance class, storage, VPC settings, etc.) does not change during a failover. The 'DBInstanceStatus' metric is not a configuration item that AWS Config captures; Config lacks visibility into transient operational states like a failover, and a config rule would have no reliable trigger because no configuration change occurs. Even if you attempted remediation, Config rules are asynchronous and not intended for real-time event-driven alerts.

Go deeper

Related to this question