How Do You Alert on Lambda Runtime Over 10 Seconds via SNS?
A company uses an AWS Lambda function to process user uploads to an Amazon S3 bucket. The Lambda function runs in response to Amazon S3 PutObject events. A CloudOps engineer needs to set up monitoring for the Lambda function. The CloudOps engineer wants to receive a notification through an Amazon SNS topic if the function takes more than 10 seconds to process an event. Which solution will meet this requirement?
Community Insight
The test is whether you know Lambda already emits invocation Duration as a native CloudWatch metric — the trap is assuming you must build a metric filter or Logs Insights query to obtain runtime data.
Lambda automatically publishes a Duration metric to Amazon CloudWatch for every invocation, so the fastest way to alert on a 10-second threshold is a CloudWatch alarm on that metric with an SNS action. This page confirms option B as the correct answer and explains why log-based metric filters and Logs Insights queries are unnecessary here.
The most common wrong pick is option D: learners assume a CloudWatch Logs Insights query can back a CloudWatch alarm, but alarms are driven by CloudWatch metrics (or metric filters), not by ad hoc Logs Insights query results.
Community Discussion (1 comments)
Comments & Corrections
No comments yet — spotted an error or have a note? Share it below.
Expert Analysis
Why the Answer Is Correct
Lambda natively reports theDuration metric to the AWS/Lambda namespace in Amazon CloudWatch for every invocation, dimensioned by FunctionName, Resource, and ExecutedVersion. The engineer therefore does not need to parse logs at all: create a CloudWatch alarm on the Lambda Duration metric with a static threshold of 10,000 milliseconds (Duration is published in milliseconds) using a Maximum or Average statistic over an appropriate period, and attach the existing SNS topic as the alarm action. When any invocation's runtime exceeds 10 seconds, the alarm transitions to ALARM and SNS delivers the notification to the CloudOps engineer. Option B is exactly this pattern, and it is also the least-effort, most operationally sound design because it reuses an existing managed metric.Why the Other Options Are Wrong
Option A builds a metric filter onPostRuntimeExtensionsDuration, which measures time spent in Lambda extension shutdown code, not total function runtime — and Duration is already a first-class metric, so a filter is redundant. Option C misreads the requirement: setting the function timeout to 10 seconds converts a slow invocation into a hard failure rather than a notification, and metric filters cannot simply "capture the runtime" as a numeric value without a defined log format. Option D is the most seductive distractor, but CloudWatch alarms cannot be based on Logs Insights query output; Logs Insights is an interactive query tool, and only metric filters or Contributor Insights rules can turn log data into alarmable metrics.Community Comment Notes
Community input on this item is thin — Bad_Mat simply states "The correct answer is B" and restates the CloudWatch metrics plus alarm plus SNS pattern, which matches the vendor-documented approach for Lambda duration alerting. There is no dissent in the comments, and no learner argues for the Logs Insights or timeout-based alternatives, so the voting signal and the technical analysis agree here. Treat the agreement as a sanity check rather than proof, and anchor your own recall on the fact thatDuration is a built-in Lambda metric. Official Reference
Exam Strategy
When a scenario asks to alert on a Lambda runtime or latency threshold, default to a CloudWatch alarm on the native Duration metric before considering any log-parsing design. Remember Duration is in milliseconds, so a 10-second threshold is 10,000 ms, and that alarms require a metric — not a Logs Insights query.
Frequently Asked Questions
Why is setting the Lambda timeout to 10 seconds not a valid monitoring solution?
A timeout ends the invocation with an error instead of sending a threshold notification, so you would break processing rather than observe slowness. You also need an alarm on the Duration metric to trigger SNS.
Can a CloudWatch alarm be based on a Logs Insights query like option D suggests?
No. CloudWatch alarms evaluate metrics, so log data must first be converted with a metric filter or Contributor Insights rule. Logs Insights query results cannot serve as an alarm source.
Related Analysis
Practice All SOA-C03 Questions
Access 100 questions with complete answers and detailed explanations.
View Full SOA-C03 Practice Test →