DOP-C02 Monitoring and Logging Practice Question
A DevOps engineer needs to monitor the number of messages in an Amazon SQS queue and trigger an auto scaling action when the queue depth exceeds a threshold. Which combination of services should be used?
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
✓
Amazon CloudWatch and Amazon EC2 Auto Scaling
Amazon CloudWatch monitors the ApproximateNumberOfMessagesVisible metric from SQS, and a CloudWatch alarm can trigger an Amazon EC2 Auto Scaling scaling policy when the queue depth exceeds a threshold. Option A is incorrect because CloudWatch Logs does not directly provide a metric for queue depth. Option C is incorrect because while EventBridge can capture SQS events, the standard method to trigger auto scaling based on queue depth is via CloudWatch alarms. Option D is incorrect because SQS and Lambda are used for processing messages, not for triggering auto scaling directly.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Amazon CloudWatch Logs and Amazon EC2 Auto Scaling
Why it's wrong here
Amazon CloudWatch Logs is designed to ingest, store, and search application log data, not to expose real-time operational metrics such as the number of messages in an SQS queue. While CloudWatch Logs can generate custom metrics via metric filters, that is not the natural or standard way to monitor SQS queue depth, and CloudWatch Logs itself never triggers an Auto Scaling policy. Instead, scaling relies on CloudWatch alarm state changes from actual numeric metrics.
- ✓
Amazon CloudWatch and Amazon EC2 Auto Scaling
Why this is correct
Amazon CloudWatch natively ingests the `ApproximateNumberOfMessagesVisible` metric that SQS publishes every minute, making queue depth directly measurable. A CloudWatch alarm that transitions to ALARM state based on this metric can be attached to a scaling policy in EC2 Auto Scaling (for step or simple scaling), or you can use a target tracking policy with a custom metric. This is the standard, supported mechanism for scaling compute resources based on queue backlog.
- ✗
Amazon EventBridge and Amazon EC2 Auto Scaling
Why it's wrong here
Amazon EventBridge is an event bus that routes discrete events to targets; it does not continuously evaluate numeric thresholds over time as CloudWatch alarms do. To use EventBridge for scaling, you would need to capture SQS metric-change events, invoke AWS Lambda, and programmatically call Auto Scaling APIs, which introduces extra components and latency. EC2 Auto Scaling policies are explicitly designed to be triggered by CloudWatch alarms, so EventBridge is not the correct service.
- ✗
Amazon SQS and AWS Lambda
Why it's wrong here
AWS Lambda can be used to consume messages in an SQS queue, but it is a compute service, not a monitoring service. It does not have built-in visibility into queue depth unless you explicitly call SQS APIs from your function, nor does it directly trigger EC2 Auto Scaling. To scale with Lambda you'd need to write custom code to query the queue and then adjust the Auto Scaling group, which is complex, error-prone, and not the intended pattern. The proper approach is monitoring via CloudWatch metrics and alarms.
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
Courseiva writes every DOP-C02 question from scratch — 1,013 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
Same concept, more angles
1 more way this is tested on DOP-C02
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. A DevOps engineer needs to monitor the number of messages in an Amazon SQS queue and trigger an Auto Scaling policy to add more EC2 instances when the queue depth exceeds a threshold. Which CloudWatch metric should the alarm use?
easy- A.NumberOfMessagesSent
- B.ApproximateNumberOfMessagesNotVisible
- ✓ C.ApproximateNumberOfMessagesVisible
- D.SentMessageSize
Why C: (ApproximateNumberOfMessagesVisible) is the correct metric because it represents the number of messages available to be retrieved from the queue. When this number exceeds a threshold, it indicates that consumer EC2 instances are not keeping up, so an Auto Scaling policy can add more instances to handle the load. Option A (NumberOfMessagesSent) is a count of messages sent, not the current queue depth. Option B (ApproximateNumberOfMessagesNotVisible) represents messages that are in flight (being processed) and not available for retrieval. Option D (SentMessageSize) is the size of messages sent, not the count. Therefore, C is correct.
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This DOP-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 DOP-C02 exam.