SOA-C02 Monitoring, Logging, and Remediation 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.

• ✗

  Define a CloudWatch metric filter to count errors and view the metric.

  Why it's wrong here

  A CloudWatch Logs metric filter is designed only to match log events against a pattern and increment a numeric metric; it does not index or retain the individual log messages themselves. When you view the resulting metric, you see counts or rates over time, but you cannot inspect the specific error strings, timestamps, or surrounding context that caused the counts. To actually search logs for a pattern, you need a query tool that returns raw log events, not an aggregated statistic.

• ✓

  Use CloudWatch Logs Insights to run a query across the log groups.

  Why this is correct

  CloudWatch Logs Insights is purpose-built for interactive analysis of log data stored in CloudWatch Logs, and it can query multiple log groups at once using a que CWL query language with parse, filter, stats, and sort commands. It is the fastest native option for a one-time search because it runs directly over the already-retained log events, returning the matching event details and summaries without requiring any additional infrastructure. For ad hoc troubleshooting, this avoids the setup time and operational overhead of forwarding or exporting logs to other services.

• ✗

  Create a subscription filter to stream logs to Amazon ES and use Kibana.

  Why it's wrong here

  A subscription filter streams new log events in real time to Amazon OpenSearch Service (formerly Elasticsearch), where Kibana can be used for dashboards and deep exploratory analysis. However, this option requires provisioning and managing an OpenSearch cluster, configuring a subscription destination, and setting up IAM permissions, which is far more effort than a quick searching need. Additionally, the subscription only starts delivering log events from the time it is created, so it will not retroactively index the existing log data that the user wants to search, making it ineffective for the stated one-time lookup.

• ✗

  Export the logs to Amazon S3 and use S3 Select to search.

  Why it's wrong here

  Exporting log groups to Amazon S3 with an export task is a batch, asynchronous operation that can take a significant amount of time before the data is available in the bucket. Even after the export completes, S3 Select is limited to querying a single object at a time with SQL, so searching across multiple exported objects or multiple log groups requires iterating over many files and stitching results yourself. This approach also incurs storage and request costs and adds substantial latency compared to the native, end-to-end query capability of CloudWatch Logs Insights, making it an inefficient choice for a quick one-off search.

Go deeper

Related to this question