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 logs to S3 and querying with Athena is suitable for historical analysis but not for real-time or ad-hoc search. It adds latency and cost.
✗
Use CloudWatch Contributor Insights to identify the top error sources.
Why it's wrong here
CloudWatch Contributor Insights analyzes top contributors to metrics, not for searching arbitrary error patterns in log data.
✗
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 is the most efficient way to query across multiple log groups with a single query, enabling centralized search without additional infrastructure.

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