DOP-C02 Monitoring and Logging 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.

• ✗

  Create a CloudWatch Logs metric filter for each log group to count ERROR entries, and then create a CloudWatch dashboard

  Why it's wrong here

  Creating a CloudWatch Logs metric filter requires a separate filter per log group, and although it can count ERROR entries on ingestion, the resulting custom metrics are scattered across multiple namespaces so you would need to build a combined metric math expression or manually sum each group's metric in the dashboard. This approach is operationally heavy and does not natively scale to many log groups, especially when log groups are created dynamically. For a simple cross-group ERROR count, CloudWatch Logs Insights' ability to query multiple log groups directly is far less maintenance and provides immediate results.

• ✓

  Use CloudWatch Logs Insights to run a query that counts ERROR entries across all log groups and add the query to a CloudWatch dashboard

  Why this is correct

  CloudWatch Logs Insights runs a query like `fields @timestamp, @logGroup | filter @message like /ERROR/ | stats count(*) by @logGroup` across all specified log groups in the selected time range, and the exact same query can be added as a dashboard widget using the 'Add to dashboard' option. This gives real-time results without any per-group configuration, and the dashboard automatically reflects the current set of log groups as long as they are included in the query scope. It is the intended native mechanism for interactive multi-group log analysis, making it the correct choice for this scenario.

• ✗

  Export logs to Amazon S3 and use Amazon Athena to query and visualize in Amazon QuickSight

  Why it's wrong here

  Exporting logs to Amazon S3 via the CreateExportTask operation is asynchronous and can take up to 12 hours to make current data available, so it does not satisfy near-real-time visibility. Athena adds latency and requires a table schema, partitioning strategy, and data freshness management, while QuickSight requires either SPICE dataset refresh or a direct query setup, further complicating the pipeline. This architecture is designed for large-scale historical analytics, not for quickly counting ERROR lines across a few log groups; an Insights query in the dashboard is far simpler and more immediate.

• ✗

  Create a Kinesis Data Firehose delivery stream to stream logs to Amazon OpenSearch Service and build a dashboard in OpenSearch Dashboards

  Why it's wrong here

  Streaming logs via Kinesis Data Firehose to Amazon OpenSearch Service for dashboarding is an over-engineered solution for simply counting ERROR-level log entries. CloudWatch Logs natively supports creating Metric Filters to extract specific patterns, like "ERROR", and publish them as custom metrics, which can then be directly visualised in CloudWatch Dashboards. This option is tempting as OpenSearch Service excels at complex log analytics, full-text search, and advanced visualisations over large datasets, making it suitable for comprehensive log management beyond simple metric aggregation.

Go deeper

Related to this question