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 detailed CloudWatch Logs and search for 'timeout' strings.

  Why it's wrong here

  Enabling detailed CloudWatch Logs and searching for 'timeout' strings would only confirm that a timeout occurred, not which code path caused it. Lambda's native logging captures stdout/stderr and platform-generated START/END/REPORT messages, but these provide aggregate duration (e.g., 'Duration: 1500.23 ms') rather than per-line timings. A timeout search might reveal the final error, but it cannot break down execution time across individual API calls or computational steps inside the function. This approach lacks the subsegment-level detail that X-Ray's trace data provides.

• ✓

  Use AWS X-Ray to trace the Lambda function and view segment details.

  Why this is correct

  AWS X-Ray is the correct choice because it provides end-to-end distributed tracing for Lambda invocations, capturing a segment for the entire execution and subsegments for each downstream operation, such as DynamoDB queries, HTTP calls, or custom code blocks. When the X-Ray SDK is installed and the function is instrumented with wrappers or decorators, you can view segment details to see the exact duration of each subsegment, pinpointing which line or API call is slow. Even without custom instrumentation, X-Ray shows the overall execution time and any downstream service traces, but adding subsegments yields the precise line-level breakdown needed for this troubleshooting.

• ✗

  Set a CloudWatch Metric Filter for 'Duration' and create an alarm.

  Why it's wrong here

  Setting a CloudWatch Metric Filter for 'Duration' and creating an alarm gives you only aggregate performance statistics, such as average or percentile durations across all invocations. A metric filter would parse the 'Duration' value from Lambda's REPORT log lines, but that represents total function time, not the time spent on individual code statements or SDK calls. The alarm can notify you that a problem exists (e.g., p95 duration exceeded), but it cannot localize the slowness to a specific line or external service. For that, you need per-request trace data like X-Ray's segments, which break down execution into measurable subcomponents.

• ✗

  Enable AWS CloudTrail data events for the Lambda function.

  Why it's wrong here

  AWS CloudTrail data events for Lambda record management and invoke API actions made against the Lambda service, such as 'Invoke' or 'UpdateFunctionCode', but they do not inspect the internal execution of your function. Even if you enable data events for the specific function, you will see that an invocation occurred and from which principal, but you will not get any timing breakdown of the code that ran inside the container. CloudTrail's logs are designed for auditing API activity and security analysis, not for profiling application performance. X-Ray, by contrast, runs inside the execution environment and can capture the duration of every code block and downstream interaction.

Go deeper

Related to this question