SOA-C02 Monitoring, Logging, and Remediation Practice Question
An application logs user authentication attempts to Amazon CloudWatch Logs. The SysOps administrator needs to create a custom metric that counts the number of failed authentication attempts every 5 minutes and trigger an alarm when the count exceeds 5. Which combination of actions should the administrator take?
⚠ Common exam trap
Test-takers frequently confuse CloudTrail (which logs AWS API calls) with application-level logging, leading them to choose Option C, or they assume the application must be modified to publish metrics (Option A), missing the serverless metric filter approach.
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
✓
Create a metric filter on the log group for the string 'FAILED_AUTH', set the metric value to 1, then create an alarm on the resulting metric.
CloudWatch Logs metric filters allow you to extract a numeric value from log events and publish it as a custom metric. By creating a filter that matches the string 'FAILED_AUTH' and setting the metric value to 1, each failed attempt increments the metric. You can then set the metric's period to 5 minutes and create an alarm that triggers when the sum exceeds 5, meeting the requirement 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 the PutMetricData API in the application to publish the number of failed attempts as a custom metric, then create an alarm.
Why it's wrong here
Publishing a custom metric from the application requires modifying authentication code to call PutMetricData, adding SDK dependencies and IAM permissions for CloudWatch access. This approach duplicates effort because the authentication outcome is already written to CloudWatch Logs, and it introduces a risk of the application failing to emit metrics if the API call fails. A metric filter on the existing log group achieves the same result with zero code changes and lower operational overhead.
- ✓
Create a metric filter on the log group for the string 'FAILED_AUTH', set the metric value to 1, then create an alarm on the resulting metric.
Why this is correct
A CloudWatch Logs metric filter applies a pattern match to incoming log events, such as the string 'FAILED_AUTH', and increments a specified metric value (e.g., 1) for every matching event. The resulting metric is automatically published to CloudWatch, and an alarm can be configured to trigger when the count exceeds a threshold over a period, such as the sum in 5 minutes. Because this operates directly on the existing log stream, it requires no application changes and provides near-real-time monitoring.
- ✗
Use AWS CloudTrail to track authentication events and create a metric filter on the CloudTrail log group.
Why it's wrong here
CloudTrail records AWS API calls made by users, roles, or services against your AWS account, including actions like EC2 RunInstances or IAM CreateUser. Application authentication failures are runtime events inside your code, not AWS API calls, so they never appear in CloudTrail logs. Creating a metric filter on a CloudTrail log group would therefore search an unrelated dataset and cannot detect the 'FAILED_AUTH' pattern from your application logs.
- ✗
Use Amazon Athena to query the logs every 5 minutes and publish results to a CloudWatch metric.
Why it's wrong here
Amazon Athena is a serverless query service for running SQL directly on data in Amazon S3, but using it for alarm generation requires first exporting CloudWatch Logs to S3 and then scheduling periodic queries—via EventBridge and Lambda, for example—to publish results as metrics. This adds significant latency, as the alarm response would be delayed by both the export frequency and the query interval, and it is far more complex than a native metric filter. Athena is intended for ad hoc analytics, not real-time operational alerting.
Go deeper
Related to this question
About these practice questions
One of 1,169 original SOA-C02 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This SOA-C02 practice question is part of Courseiva's free Amazon Web Services certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the SOA-C02 exam.