SOA-C02 CloudWatch Logs Insights query syntax Practice Question

Exhibit

Consider the following CloudWatch Logs Insights query:
fields @timestamp, @message
| filter @message like /ERROR/
| stats count() by bin(5m)
| sort @timestamp desc

Refer to the exhibit. A SysOps administrator runs this CloudWatch Logs Insights query against an application log group. The query returns no results, even though the administrator knows that errors occurred in the last hour. What is the most likely cause?

⚠ Common exam trap

Candidates often assume a query returning no results is due to a syntax error. However, CloudWatch Logs Insights queries can time out on very large log groups, and a timeout may produce no results; `bin(5m)` is valid syntax.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

The log group contains too many log events, causing the query to time out.

In CloudWatch Logs Insights, `stats count() by bin(5m)` is valid syntax; `bin()` does not require a preceding field. Therefore option A is not the cause. The most likely cause among the options is that the log group contains too many log events, causing the query to time out before results are returned. Retention policy does not affect events from the last hour, and `@message` is a valid field.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✗
The 'stats' command requires a 'by' clause with a field name, but 'bin(5m)' is invalid.
Why it's wrong here
The stats command in CloudWatch Logs Insights does not always require a by clause; for example, stats count() alone is valid. The bin(5m) function is a recognized time-window expression that can be used within the by clause to group results into five-minute intervals. The syntax is legitimate, so the issue is not an invalid command but likely a query execution problem.
✓
The log group contains too many log events, causing the query to time out.
Why this is correct
CloudWatch Logs Insights queries have a maximum execution time of 60 seconds, and when a log group contains a very high volume of log events within the queried time range, the query engine may exceed that limit. A timeout causes the query to return no results, even though the data exists. This matches the symptom described in the question, making it the correct explanation.
✗
The @message field is not a valid field in CloudWatch Logs Insights.
Why it's wrong here
The @message field is a built-in, automatically populating field in CloudWatch Logs Insights that contains the full text of the log event as it was ingested. It is frequently used in queries for pattern matching and parsing, so it is absolutely a valid field. Therefore, the premise that @message is invalid is false and cannot be the reason the query failed.
✗
The log group's retention policy is set to 1 day and the data is older than the retention period.
Why it's wrong here
The retention policy controls how long log events are stored before they are deleted, but it does not affect query execution unless the data has already been purged. Since the errors occurred in the last hour, they are well within a 1-day retention window and therefore still available for querying. The retention setting is irrelevant to the timeout issue, so this option is incorrect.

Go deeper

SOA-C02 CloudWatch Logs Insights query syntax Practice Question

Exhibit

Why each option matters

Option-by-option breakdown

Related to this question