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 the CloudTrail trail to deliver logs directly to an SNS topic.

  Why it's wrong here

  CloudTrail trails can only deliver log files to an Amazon S3 bucket or to Amazon CloudWatch Logs; SNS is not a supported direct destination. If you attempted to configure SNS as a delivery target, CloudTrail would reject it because the service lacks an integration for pushing events straight to a topic. Even if delivery were possible, a raw SNS notification would not provide the filtering, aggregation, or numeric threshold evaluation needed to set a meaningful alarm. The correct architecture uses CloudWatch Logs as the delivery point, then a subscription filter and Lambda to process events.

• ✓

  Configure the Lambda function to publish a custom metric to CloudWatch.

  Why this is correct

  The Lambda function that receives the CloudWatch Logs subscription filter must parse the base64 gzip-compressed log data, extract only the CreateAccessKey events, and call PutMetricData to publish a custom CloudWatch metric (e.g., IAMAccessKeyCreatedCount) in a custom namespace. Publishing a custom metric is essential because CloudTrail log entries are not natively represented as CloudWatch metrics, so you need this transformation to enable threshold-based alarm evaluation. The metric count can be incremented for each matching event, allowing the later CloudWatch alarm to compare against a threshold. Without this step, there is no numeric time-series data on which to set an alarm.

• ✓

  Set a CloudWatch alarm on the custom metric to send an Amazon SNS notification when the metric exceeds a threshold.

  Why this is correct

  Once the Lambda publishes the custom metric to CloudWatch, you configure an alarm that monitors that metric, typically with a statistic such as Sum or SampleCount over a 1- or 5-minute period. When the metric value exceeds the threshold (for example, greater than 0, indicating at least one CreateAccessKey event), the alarm transitions to ALARM state and automatically publishes to an SNS topic. This SNS notification is what actually alerts the security team via email, SMS, or other subscribed endpoints. This step closes the alerting loop and directly meets the requirement to "notify the security team."

• ✓

  Create a CloudWatch Logs subscription filter that sends matching log events to an AWS Lambda function.

  Why this is correct

  To route CloudTrail log events from CloudWatch Logs to AWS Lambda, you must establish a subscription filter using a pattern that matches the specific API activity. A filter pattern like { ($.eventName = "CreateAccessKey") } ensures only relevant log events are sent to the Lambda function in real time, avoiding processing of all CloudTrail entries. This is the required ingestion mechanism when your source is CloudWatch Logs; without it, Lambda would never see the events to publish metrics. The filter invokes the chosen Lambda function with the matched log events, enabling the metric generation for the subsequent alarm.

• ✗

  Create an Amazon EventBridge rule that matches the CreateAccessKey event and triggers an SNS notification.

  Why it's wrong here

  An EventBridge rule that matches the CreateAccessKey event and directly triggers an SNS topic is a perfectly valid and often simpler alternative architecture—it does not require CloudWatch Logs, Lambda, or custom metrics. However, the question specifically asks for the three steps to implement when using CloudTrail logs delivered to CloudWatch Logs, which mandates a subscription filter and a Lambda function. If you chose this option, you would be implementing a separate event-driven pipeline rather than the CloudWatch Logs-based design described in the stem. Therefore, it is incorrect because it is not one of the three required steps in that particular architecture.

Go deeper

Related to this question