SOA-C02 Monitoring, Logging, and Remediation Practice Question

A SysOps administrator needs to create a custom Amazon CloudWatch metric to track the number of active user sessions from application logs. The administrator wants to publish this metric to CloudWatch and set an alarm when the count exceeds a threshold. Which solution should be used?

⚠ Common exam trap

Candidates often confuse CloudWatch Contributor Insights (which analyzes log data for top contributors) with a simple metric filter, or assume Embedded Metric Format is required. A CloudWatch Logs Metric Filter is the standard, cost-effective way to create a custom metric from log events without requiring application changes.

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 a CloudWatch Logs Metric Filter on the log group.

CloudWatch Logs Metric Filters allow you to define a filter pattern that matches specific log events (e.g., 'User session started') and convert them into a custom metric. The metric is automatically published to CloudWatch, where you can set an alarm on the count of matching log entries. This is the standard, cost-effective approach for extracting metrics from application logs without modifying the application code.

Answer analysis

Option-by-option breakdown

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

✓
Use a CloudWatch Logs Metric Filter on the log group.
Why this is correct
A metric filter scans log entries for a pattern and increments a metric each time the pattern appears. The resulting metric can be used to trigger an alarm. This is the correct and straightforward approach.
✗
Use CloudWatch Contributor Insights to extract the metric from logs.
Why it's wrong here
Contributor Insights analyzes high contributors (e.g., top IPs) and generates time series, but it does not create a simple count metric that can be alarmed on like a metric filter. It is meant for different use cases.
✗
Use CloudWatch Synthetics Canary to simulate user sessions and publish metrics.
Why it's wrong here
CloudWatch Synthetics Canaries are designed for proactive, end-to-end verification of web applications by running scheduled Node.js or Python scripts that simulate user journeys (e.g., login, checkout) and emit metrics about request success, latency, and UI stability. They do not parse or analyze existing application log data; instead, they generate their own synthetic traffic and metrics, which means they cannot convert historical or current log entries into a custom count metric. Using a canary would create a separate, simulated workload—not an alarm on actual errors appearing in the monitored application's logs—and would also incur additional execution costs and require writing and maintaining a canary script.
✗
Use CloudWatch Embedded Metric Format to have the application publish metrics directly.
Why it's wrong here
The CloudWatch Embedded Metric Format (EMF) enables applications to emit structured JSON log lines that CloudWatch automatically extracts into metrics, but it requires modifying the application's code to produce these special log events in the specified schema. This is far more invasive than deploying a metric filter, because you must instrument each log-producing code path and ensure the JSON includes the metric name, value, and namespace. Additionally, EMF is intended for emitting new metrics from ongoing application telemetry; it cannot inspect or transform legacy or existing unstructured log data, so it would not satisfy a requirement to derive a count metric from logs that are already being generated without code changes.

Go deeper

SOA-C02 Monitoring, Logging, and Remediation Practice Question

Why each option matters

Option-by-option breakdown

Related to this question