DOP-C02 - Monitoring and Logging (15% of the exam) - Section 4.1

Configure the collection, aggregation and storage of logs and metrics with Amazon CloudWatch, the CloudWatch agent, Amazon CloudWatch Logs and metric filters.

Configure the CloudWatch agent to collect operating system and application metrics from Amazon EC2 instances, and route structured log output to Amazon CloudWatch Logs log groups. Define metric filters to extract numeric signals from log data and publish them as custom CloudWatch metrics.

Amazon CloudWatchCloudWatch agentAmazon CloudWatch LogsMetric filters

Practice question for this objective

Free sampleMonitoring and Loggingmedium

A DevOps team runs a fleet of Amazon EC2 instances behind an Auto Scaling group and needs to alarm when an instance is short of available memory or when its root disk passes 85 percent used. The default Amazon EC2 metrics that Amazon CloudWatch publishes do not expose either value, and the team wants these metrics in CloudWatch with the least ongoing maintenance so existing CloudWatch alarms can act on them. Which approach should they implement?

AWrite a cron job on each instance that reads memory and disk usage from the operating system and calls the CloudWatch PutMetricData API with custom metric values on a fixed schedule for every host.
BInstall the Amazon CloudWatch agent on the instances and bake a unified agent configuration into the launch template so memory and disk metrics are published to CloudWatch as the group scales. Correct
CEnable detailed monitoring on the Auto Scaling group so Amazon CloudWatch collects memory and disk metrics from each instance at one-minute resolution without any additional software on the hosts.
DEnable AWS Compute Optimizer on the account so it analyses the Auto Scaling group and publishes the memory and disk utilisation of each instance into Amazon CloudWatch for alarming.

Use the Amazon CloudWatch agent to collect guest-level memory and disk metrics that default EC2 metrics never expose. Default Amazon CloudWatch metrics for EC2 come from the hypervisor, which cannot see inside the guest operating system, so memory and disk-usage figures require an in-guest collector. The CloudWatch agent is the managed collector for this, and embedding its configuration in the launch template makes each new instance publish the metrics automatically without bespoke scripts to maintain.

Why A is wrong: A hand-rolled cron and PutMetricData script does surface the values, but it is bespoke code the team must patch, secure, and maintain on every host, which is the high-maintenance path the requirement explicitly rules out.

Why B is correct: The CloudWatch agent is the managed way to collect guest-level memory and disk metrics, and shipping its configuration in the launch template means every scaled instance self-configures with no per-host code to maintain.

Why C is wrong: Detailed monitoring only raises the publishing frequency of the existing hypervisor-level EC2 metrics to one minute; it never adds guest memory or disk-usage metrics, which the hypervisor cannot observe.

Why D is wrong: Compute Optimizer produces right-sizing recommendations from historical data and does not stream live memory or disk metrics into CloudWatch, so no CloudWatch alarm could fire from its output.

See more DOP-C02 practice questions, answers explained.

Exam traps in Monitoring and Logging

Answers that look right on this material and are not. Each one is a distractor from a different question in the DOP-C02 bank for this domain.

Stream the log group to Amazon OpenSearch Service through a subscription filter, then schedule an OpenSearch alert that counts "AuthFailure" documents over five minutes and publishes to the Amazon SNS topic.
Why it is wrong: Streaming to OpenSearch and running an alerting query works, but it stands up and maintains a separate search cluster and pipeline, which is more operational overhead than the in-place CloudWatch capability the requirement points to.
Deploy Amazon Kinesis Agent to every server, point it at the application log files, and rely on instance metadata to forward host metrics into Amazon CloudWatch alongside the log data.
Why it is wrong: Kinesis Agent only tails files into Kinesis services and does not collect host system metrics, so it cannot be the single tool covering both logs and metrics that the requirement describes.
Build an AWS Lambda function that calls the FilterLogEvents API against each log group in turn and merges the responses, then expose it behind an internal endpoint the on-call engineers can invoke during incidents.
Why it is wrong: A Lambda that iterates over log groups and merges results is exactly the custom aggregation pipeline the team wants to avoid, adding maintenance and latency compared with a native multi-group Logs Insights query.

Examworthy is not affiliated with or endorsed by Amazon Web Services. Original, blueprint-aligned practice material only.