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.

• ✗

  Enable S3 event notifications on the CloudTrail bucket to trigger a Lambda function that parses logs and sends an alert.

  Why it's wrong here

  S3 event notifications are delivered asynchronously and can have noticeable delays, especially when CloudTrail delivers log files in batches, so they are not suitable for near-real-time security monitoring. Additionally, triggering a Lambda function for every CloudTrail log object would require parsing all logs to find the rare CreateAccessKey event, which is inefficient and may incur significant cost and processing time. A direct metric filter in CloudWatch Logs avoids both the delay and the need to parse irrelevant data.

• ✗

  Use AWS Config rules to detect changes to IAM access keys and trigger an SNS notification.

  Why it's wrong here

  AWS Config evaluates resources periodically and on configuration changes, but it is not a real-time security event service; its evaluations can lag significantly, so you would not receive an alert immediately when a new access key is created. Moreover, IAM access keys are not a native AWS Config resource type with out-of-the-box rules, so you would need to create a custom rule using a Lambda function, which still introduces periodic delays and complexity. For time-sensitive alerts on CloudTrail events, a metric filter and alarm are the standard solution.

• ✓

  Configure CloudTrail to send logs to CloudWatch Logs. Create a metric filter for the IAM event 'CreateAccessKey' and set a CloudWatch alarm that sends an SNS notification.

  Why this is correct

  CloudTrail can be configured to deliver all management events to a CloudWatch Logs log group in near-real-time, allowing you to analyze them with metric filters. By creating a metric filter that matches the event name "CreateAccessKey" and setting a CloudWatch alarm on the resulting metric, you get an SNS notification as soon as the event occurs, with minimal latency and no need for custom code or compute resources. This is the serverless best practice for security event monitoring on AWS.

• ✗

  Run a script on an EC2 instance that polls CloudTrail API for new events every minute and sends alerts.

  Why it's wrong here

  Polling the CloudTrail LookupEvents API every minute from a custom EC2 script introduces up to 60 seconds of latency and is subject to API throttling, which can cause missed events if many calls are made. It also requires you to manage and pay for an always-on EC2 instance, including operating system patches and high availability, making it less reliable and more operationally complex than a fully managed, serverless solution. CloudTrail's LookupEvents API retrieves events asynchronously and may not reflect the event within the same minute, further delaying alerts.

Go deeper

Related to this question