SCS-C02 Security Logging and Monitoring Practice Question

Exhibit

Refer to the exhibit.

CloudWatch Logs Insights query:
fields @timestamp, @message
| filter @message like /ERROR|WARN/
| sort @timestamp desc
| limit 20

Refer to the exhibit. A security engineer runs this CloudWatch Logs Insights query on a log group. What is the purpose of this query?

⚠ Common exam trap

The trap here is that candidates may overlook the regex alternation `(ERROR|WARN)` and assume the query only filters for 'ERROR', or they may misinterpret the `limit` and `sort` as performing a count or grouping operation.

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

✓

Retrieve the 20 most recent log events that contain 'ERROR' or 'WARN'.

The CloudWatch Logs Insights query uses `filter @message like /(?i)(ERROR|WARN)/` to match log events containing either 'ERROR' or 'WARN' (case-insensitive), then `sort @timestamp desc` orders them by most recent first, and `limit 20` restricts the output to the top 20 results. This retrieves the 20 most recent log events that contain either term, making option B correct.

Answer analysis

Option-by-option breakdown

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

✗
Retrieve the 20 most recent log events that contain only 'ERROR'.
Why it's wrong here
Retrieving only 'ERROR' is incorrect because the query's filter pattern includes 'WARN' as an alternative. If the filter were restricted to /ERROR/ alone, the resulting 20 events would omit all WARN entries, so the result set would no longer represent both severity levels. The sort and limit mechanics would still function, but the filter would be too narrow for the intended requirement.
✓
Retrieve the 20 most recent log events that contain 'ERROR' or 'WARN'.
Why this is correct
This is correct because the CloudWatch Logs Insights query uses `filter @message like /ERROR|WARN/` to match any log event containing either substring, and then `sort @timestamp desc | limit 20` orders by timestamp descending and returns the 20 newest matching events. That combination of a regex-style filter and a descending sort with a limit accomplishes exactly the stated goal, making it the only option that describes what the exhibited query does.
✗
Display all log events grouped by log level.
Why it's wrong here
Displaying grouped log levels would require a `stats` command with a `by` clause, such as `stats count(*) by level`. The exhibited query contains no aggregation, no `stats`, and no grouping operation; it simply filters raw log events and limits the output to 20 records. Without a `group by` or a histogram function, CloudWatch Logs Insights cannot return a summary of log levels, so this option mischaracterizes the query's behavior.
✗
Count the number of ERROR and WARN events in the last hour.
Why it's wrong here
Counting events over the last hour would require both an aggregation function like `stats count(*)` and a time-based boundary, often defined with `filter @timestamp` or a `bin` command. The exhibited query has neither an aggregation nor an explicit time range filter; it only uses content filtering, sorting, and a limit. Therefore, it returns raw log records rather than a count of events, so this option is not what the query performs.

Go deeper

SCS-C02 Security Logging and Monitoring Practice Question

Exhibit

Why each option matters

Option-by-option breakdown

Related to this question