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.

• ✗

  Stream the logs to Amazon Kinesis Data Firehose, which then triggers a Lambda function to check for errors.

  Why it's wrong here

  Amazon Kinesis Data Firehose is a managed streaming delivery service intended to load data into Amazon S3, Redshift, OpenSearch, or Splunk, not to trigger functions per event. While Firehose can invoke a Lambda function as a data transformer, that occurs within the delivery pipeline and adds provisioning, buffering, and cost overhead that is unnecessary for real-time log alerting. A direct CloudWatch Logs subscription to Lambda processes events immediately and is the simpler, more accurate pattern.

• ✗

  Create a CloudWatch metric filter on the log group and set an alarm that triggers an SNS notification.

  Why it's wrong here

  CloudWatch metric filters use a fixed pattern syntax that can match a literal string or a JSON field, but they only increment a metric count—they cannot run application logic to evaluate complex conditional error scenarios or parse multi-line stack traces. Alarms then evaluate the metric over a period (e.g., one minute) and require a threshold to be crossed, which introduces aggregation delay and can miss a single critical error far more slowly. Lambda, in contrast, inspects each log event as it arrives, making it the better choice for bespoke pattern matching and immediate SNS notification.

• ✓

  Create a Lambda function subscribed to the CloudWatch Logs log group, which checks for the error pattern and publishes to an SNS topic.

  Why this is correct

  When you configure a subscription filter on a CloudWatch Logs group, CloudWatch Logs asynchronously invokes a Lambda function as log events are ingested, delivering a gzip-compressed batch of data that you can decode and search for error signatures. The Lambda function can be written in Python, Node.js, or another supported runtime, applying arbitrary regexes, aggregating events, and then directly publishing to an SNS topic for immediate fan-out to email, SMS, or Chatbot. This pattern provides real-time, event-driven alerting with minimal latency and no extra infrastructure, which is why it is the recommended approach for this requirement.

• ✗

  Use CloudWatch Logs Insights to run a query every minute and send results via SNS.

  Why it's wrong here

  CloudWatch Logs Insights is an interactive query engine meant for tactical, on-demand exploration of logs, not a recurring scheduler—there is no built-in 'run every minute' trigger, and automating it would require an extra Lambda/EventBridge orchestrator to call the StartQuery API and then poll for results. Even then, the query would be scanning data that may be partially unindexed until the logs are ready, and Insights queries return up to 10,000 rows only, so it is unsuitable for real-time alerting. Lambda subscriptions, by contrast, operate on log events in flight, giving you immediate detection without polling.

Go deeper

Related to this question