Monitoring and Logging — AWS Certified DevOps Engineer DOP-C02 practice questions

Which is the BEST observability stack for AWS applications?

1. It only functions when all resources are in a single AZ zone
2. CloudWatch Logs/Metrics/Logs Insights/Alarms + X-Ray distributed
3. It writes findings to S3 only and cannot notify EventBridge for th
4. It runs exclusively on Fargate and cannot target EC2 fleets for th

Answer: B — CloudWatch Logs/Metrics/Logs Insights/Alarms + X-Ray distributed

AWS observability: CloudWatch (logs, metrics, alarms, dashboards, Logs Insights for queries), X-Ray (traces), Container Insights (EKS/ECS), Application Insights (SQL/.NET). OpenTelemetry integration. SLA monitoring via CloudWatch Synthetics canaries.

A CloudWatch composite alarm should fire only if BOTH 'high error rate' AND 'low traffic' alarms are active. Which BEST describes composite alarm behavior?

1. It only functions when all resources are in a single AZ zone
2. It writes findings to S3 only and cannot notify EventBridge
3. Composite alarms evaluate boolean expressions over child alarm
4. It runs exclusively on Fargate and cannot target EC2 fleets

Answer: C — Composite alarms evaluate boolean expressions over child alarm

Composite supports AND/OR/NOT over child alarm states. B/C/D wrong.

X-Ray sampling rules: which statement is CORRECT?

1. Default sampling is 1 request per second + 5% of additional requests
2. It only functions when all resources are in a single AZ zone
3. It writes findings to S3 only and cannot notify EventBridge
4. It runs exclusively on Fargate and cannot target EC2 fleets

Answer: A — Default sampling is 1 request per second + 5% of additional requests

Default is 1/sec reservoir + 5% rate. Custom rules target by URL path/host/service. B/C/D wrong.

CLOUDWATCH SYNTHETICS (Canaries):

1. It only functions when all resources are in a single AZ zone
2. Configurable SCRIPTS that monitor APIs + URLs by performing
3. It writes findings to S3 only and cannot notify EventBridge
4. It runs exclusively on Fargate and cannot target EC2 fleets

Answer: B — Configurable SCRIPTS that monitor APIs + URLs by performing

Synthetics: proactive monitoring. Pre-built blueprints (broken link checker, API canary, etc.) or custom scripts. Headless Chrome for browser interaction. Detect issues BEFORE users. Integrate with X-Ray + CloudWatch Alarms. DOP observability + SRE.

A CloudWatch alarm should fire when error rate exceeds 1% over a 5-minute period, but the metric has gaps (no data points) during low traffic. The alarm is currently noisy at night. Which BEST behavior should be configured?

1. Treat missing data as notBreaching so quiet periods don't fire
2. It only functions when all resources are in a single AZ zone
3. It writes findings to S3 only and cannot notify EventBridge
4. It runs exclusively on Fargate and cannot target EC2 fleets

Answer: A — Treat missing data as notBreaching so quiet periods don't fire

Missing data treatment is the right control. B falsifies the metric. C makes noise worse. D loses coverage.

Which is the BEST way to monitor LAMBDA functions in production?

1. Enabling only VPC Flow Logs, which capture network traffic but not function execution
2. Relying on CloudTrail alone, which logs the Invoke API call but not function-level metrics or logs
3. CloudWatch Logs (via /aws/lambda/<name>), built-in Lambda metrics, X-Ray tracing, and Lambda Insights for enhanced observability
4. Polling the Lambda console manually for error counts

Answer: C — CloudWatch Logs (via /aws/lambda/<name>), built-in Lambda metrics, X-Ray tracing, and Lambda Insights for enhanced observability

Lambda observability: CloudWatch Logs (always), built-in metrics, X-Ray (with @captureAWS), Lambda Insights (enhanced metrics). DLQ on async invocations. Alarms on errors/duration spikes. Insights into cold starts via Init Duration metric.

A team wants real-time streaming of CloudWatch metrics to a third-party SIEM with minimal latency. Which feature is BEST?

1. CloudWatch Metric Streams to Kinesis Data Firehose, then deliver to the third-party SIEM's HTTP endpoint or S3 bucket
2. Poll the CloudWatch GetMetricData API on a cron schedule every few minutes
3. Export metrics to S3 nightly and have the SIEM ingest the batch file
4. Use CloudTrail data events, which capture API calls, not metric values

Answer: A — CloudWatch Metric Streams to Kinesis Data Firehose, then deliver to the third-party SIEM's HTTP endpoint or S3 bucket

Metric Streams is purpose-built for low-latency metric egress. B is high latency and limited. C/D don't carry metrics.

An EKS cluster runs hundreds of pods. The team wants per-namespace CPU/memory in CloudWatch with low operational overhead. Which feature is BEST?

1. It only functions when all resources are in a single AZ zone
2. It writes findings to S3 only and cannot notify EventBridge
3. Enable Container Insights on the EKS cluster (CloudWatch agent
4. It runs exclusively on Fargate and cannot target EC2 fleets

Answer: C — Enable Container Insights on the EKS cluster (CloudWatch agent

Container Insights is the AWS-managed solution for ECS/EKS observability. B is OK but more ops. C/D miss the goal.

CloudWatch Logs subscription filters?

Stream logs to Lambda, Kinesis, Firehose for processing.

X-Ray sampling rules?

Control trace volume. Reservoir + fixed rate. Custom rules per service.

Container Insights?

CloudWatch metrics for ECS/EKS. CPU, memory, network at task level.

CloudWatch Application Signals?

Auto-monitor application performance. SLOs and dashboards.