SAP-C02 CloudWatch Logs Insights Practice Question

A company has a microservices architecture running on Amazon ECS with Fargate. Each service writes logs to CloudWatch Logs. The operations team needs to search across all logs for a specific error pattern. Currently, they manually query each log group, which is time-consuming. What is the MOST efficient way to enable centralized log search?

⚠ Common exam trap

Candidates may think that sending logs to a central storage like S3 or Kinesis is necessary, but CloudWatch Logs Insights already provides cross-log-group querying.

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

✓

Use CloudWatch Logs Insights to query all log groups from a single query.

CloudWatch Logs Insights enables querying multiple log groups in a single query using a query language, allowing centralized search across all services. Option A is wrong because exporting to S3 and using Athena is for analyzing historical data, not real-time search. Option B is wrong because CloudWatch Contributor Insights identifies top contributors and is not for arbitrary pattern search. Option C is wrong because subscription filters to Kinesis Data Firehose can centralize logs but require additional infrastructure and do not provide a built-in query interface like Logs Insights.

Answer analysis

Option-by-option breakdown

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

✗
Export logs to Amazon S3 and use Amazon Athena to query them.
Why it's wrong here
Exporting to S3 and querying with Athena introduces batch latency and duplicate storage, so logs are not searchable in near real time across groups. Athena suits ad hoc SQL analysis over historical data already resident in S3, not live operational troubleshooting.
✗
Use CloudWatch Contributor Insights to identify the top error sources.
Why it's wrong here
Contributor Insights aggregates and ranks top contributors against metric rules; it does not let operators search raw log events for an arbitrary error pattern. It suits identifying which dimensions dominate a metric, such as noisiest IP addresses, rather than pattern matching.
✗
Create a subscription filter for each log group that sends logs to a Kinesis Data Firehose delivery stream.
Why it's wrong here
Subscription filters sending logs to Kinesis Data Firehose do not directly enable centralised log search because Firehose is a data ingestion and delivery service, not a searchable log repository. It centralises log *delivery* but lacks the query capabilities the operations team requires. This option is tempting as Firehose efficiently streams data to various destinations like Amazon S3 or OpenSearch Service. It is a vital component for building a comprehensive centralised logging solution when paired with a suitable search backend.
✓
Use CloudWatch Logs Insights to query all log groups from a single query.
Why this is correct
CloudWatch Logs Insights queries multiple log groups in one statement, aggregating results centrally. This removes the manual per-group querying that made cross-service error searches slow, directly meeting the centralised search requirement across all Fargate services.

Quick reference

AWS S3 Storage Class Comparison

Storage Class	Min Duration	Retrieval	Use Case
S3 Standard	None	Immediate	Frequently accessed data
S3 Standard-IA	30 days	Immediate	Infrequent access, rapid retrieval
S3 One Zone-IA	30 days	Immediate	Non-critical infrequent data
S3 Intelligent-Tiering	None	Immediate–hours	Unknown or changing access patterns
S3 Glacier Instant	90 days	Milliseconds	Archive with instant retrieval
S3 Glacier Flexible	90 days	Minutes–hours	Archive, flexible retrieval
S3 Glacier Deep Archive	180 days	Hours	Long-term compliance archive

Go deeper

SAP-C02 CloudWatch Logs Insights Practice Question

Why each option matters

Option-by-option breakdown

AWS S3 Storage Class Comparison

Related to this question