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.

• ✗

  Create a CloudWatch Logs metric filter on the CloudTrail log group for CreateAccessKey events and set an alarm.

  Why it's wrong here

  This approach is functional but indirect. You would need to ensure CloudTrail delivers logs to CloudWatch Logs, then create a metric filter that parses the log stream for 'CreateAccessKey' events, and finally define a CloudWatch alarm on the resulting metric. This adds setup overhead and latency because the alarm depends on log ingestion and metric processing, whereas CloudWatch Events can react to the API call directly and trigger an SNS notification in near real time.

• ✗

  Use AWS Trusted Advisor to check for excessive access keys.

  Why it's wrong here

  Trusted Advisor is designed to provide best-practice recommendations for cost, performance, security, and fault tolerance, but it does not monitor ongoing API activity. Its IAM access key checks focus on the age and number of keys, not on the creation event itself. It also operates on a periodic review cadence, so it cannot deliver real-time security alerts when a new access key is created.

• ✓

  Create a CloudWatch Events rule that matches the CreateAccessKey API call and triggers an SNS notification.

  Why this is correct

  CloudWatch Events (now Amazon EventBridge) directly intercepts the CloudTrail API event as soon as it occurs. By defining a rule with an event pattern that filters the 'CreateAccessKey' API call and linking it to an SNS topic, the architecture provides a real-time, serverless notification pipeline. This is the simplest and most efficient way to alert on security-sensitive IAM actions because it consumes the event stream directly without requiring log parsing or polling.

• ✗

  Use AWS Config to monitor the 'iam-user' resource type for changes to access keys.

  Why it's wrong here

  AWS Config records configuration changes for supported IAM resources, but it is not oriented toward event-driven alerting on API calls. While it can capture IAM user configuration changes, including access key metadata, it does so as part of a periodic recording cycle and is primarily used for compliance evaluation and configuration history, not real-time incident response. Moreover, monitoring a resource type like 'iam-user' would catch only the user configuration change and not directly flag the API call itself with the same precision as an EventBridge rule.

Go deeper

Related to this question