SOA-C02 CloudWatch Events (Amazon EventBridge) Practice Question
A SysOps administrator manages a fleet of EC2 instances that run a batch processing job. The job runs every hour and takes about 45 minutes to complete. The administrator wants to be notified if any job takes longer than 1 hour. Currently, the administrator uses CloudWatch Logs to capture job start and end times from application logs. The job writes a log message at start with 'JOB_START' and at end with 'JOB_END'. The administrator wants to create a metric filter that counts jobs that exceed 1 hour. However, the administrator is unsure how to achieve this with CloudWatch Logs. What should the administrator do?
⚠ Common exam trap
Candidates often think metric filters can compute duration by extracting timestamps from JOB_START and JOB_END, but metric filters operate on individual log events and cannot correlate two events for the same job. The correct solution uses CloudWatch Events with Lambda for stateful computation.
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 Events to capture the log events and trigger a Lambda function to compute duration.
CloudWatch Events (now part of Amazon EventBridge) can capture log events in real-time and trigger a Lambda function. The Lambda function can then compute job duration by correlating JOB_START and JOB_END events (e.g., using a DynamoDB table to store start times) and publish a custom metric or trigger an alarm if duration exceeds 1 hour. This approach handles the per-job correlation that metric filters cannot achieve.
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 CloudWatch Logs Insights to run a query every hour and check the duration.
Why it's wrong here
CloudWatch Logs Insights is an interactive query engine for exploring historical log data; it does not provide continuous, real-time monitoring or native actions to trigger alarms. Running a query every hour would add up to an hour of latency, and you would still need separate automation to evaluate the result and respond. This polling approach is unsuitable for detecting job failures or durations that require near-immediate alerting.
- ✓
Use CloudWatch Events to capture the log events and trigger a Lambda function to compute duration.
Why this is correct
CloudWatch Events (EventBridge) can deliver CloudWatch Log events to a Lambda function in near real-time via a subscription filter, enabling event-driven processing. The Lambda function can parse the JOB_START and JOB_END entries, correlate them by job ID, calculate the duration, and publish a custom metric or trigger an alarm. This serverless architecture avoids polling and reacts immediately to each logged job, making it the recommended pattern.
- ✗
Create a metric filter that extracts the timestamp of JOB_START and JOB_END and computes the duration in a custom metric.
Why it's wrong here
CloudWatch Logs metric filters evaluate each log event independently and extract a single numeric value from that event; they cannot correlate multiple events to compute a duration. Extracting the JOB_START timestamp and the JOB_END timestamp would produce two separate metrics without any join key, so you cannot derive per-job duration or trigger an alert based on the elapsed time. A stateful processor like Lambda is required to pair the events and calculate the difference.
- ✗
Create a Lambda function that is triggered by S3 to process the logs and publish a custom metric.
Why it's wrong here
An S3 trigger only fires when objects are created or modified in an S3 bucket, but this scenario's log events live in CloudWatch Logs, not in S3. To get logs into S3 you would have to export them, which is a batched process that can delay processing by minutes. The Lambda would then process stale data, and publishing a custom metric from there adds unnecessary complexity without improving real-time detection.
Quick reference
Cloud Service Model Comparison
| Model | You Manage | Provider Manages | Examples |
|---|---|---|---|
| IaaS | OS, runtime, apps, data | Hardware, hypervisor, networking | EC2, Azure VMs, GCP Compute Engine |
| PaaS | Apps and data | OS, runtime, middleware, hardware | Elastic Beanstalk, Azure App Service |
| SaaS | Data and settings only | Everything else | Microsoft 365, Salesforce, Workday |
| FaaS / Serverless | Function code only | Infra, scaling, runtime | Lambda, Azure Functions, Cloud Run |
| CaaS | Containers and apps | Kubernetes, OS, hardware | EKS, AKS, GKE |
Go deeper
Related to this question
About these practice questions
This SOA-C02 question is part of Courseiva's 247-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. 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.