Least Overhead for Custom EC2 Metrics

Configure the collection, aggregation, and storage of logs and metrics.

Answer Correct answer: A — Install the Amazon CloudWatch agent on the instances and configure it to collect the custom metrics.

A company is developing a web application that runs on Amazon EC2 Linux instances. The application requires monitoring of custom performance metrics. The company must collect metrics for API response times and database query latency across multiple instances. Which solution will generate the custom metrics with the LEAST operational overhead?

Install the Amazon CloudWatch agent on the instances. Configure the agent to collect the custom metrics. Instrument the application to send the metrics to the agent. Correct Answer
Use Amazon Managed Service for Prometheus to scrape the custom metrics from the application. Use the Amazon CloudWatch agent to forward the metrics to CloudWatch.
Create a custom AWS Lambda function that polls the application endpoints and database at regular intervals. Program the Lambda function to calculate the custom metrics and to send the metrics to Amazon CloudWatch by using PutMetricData API calls.
Implement custom logging in the application code to record the custom metrics. Use Amazon CloudWatch Logs Insights to extract and analyze the metrics.

Community Insight

Tests knowledge of native metric collection tools versus manual instrumentation or log parsing, highlighting that agent-based collection reduces code maintenance compared to Lambda or Logs Insights.

Determines the optimal method for collecting custom performance metrics from Amazon EC2 instances with minimal operational overhead using the CloudWatch Agent.

Candidates often select Option D (CloudWatch Logs Insights) because it requires no agent installation, but this incurs higher operational overhead due to complex log parsing and query management.

Community Discussion (2 comments)

meng 👍 1 Selected: A

https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Install-CloudWatch-Agent.html https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/install-CloudWatch-Agent-on-EC2-Instance.html

emupsx1 👍 2 Selected: A

Option A is the best choice because the CloudWatch Agent provides native support for protocols like StatsD, allowing the collection of internal application metrics (such as latency) with minimal configuration. In contrast, Options C and D require additional development maintenance (Lambda) or higher-cost log analysis overhead.

Comments & Corrections

No comments yet — spotted an error or have a note? Share it below.

Expert Analysis

Why the Answer Is Correct

Option A is correct because the Amazon CloudWatch Agent is specifically designed to collect custom application metrics directly from the instance OS and application environment. By configuring the agent to accept metrics (e.g., via StatsD or TCP/UDP), the application can push data without complex polling logic, and the agent handles transmission to CloudWatch, representing the least operational overhead for infrastructure-level monitoring.

Why the Other Options Are Wrong

Option B introduces unnecessary complexity by combining Managed Service for Prometheus with an agent, which is overkill for simple EC2 metrics. Option C requires maintaining a Lambda function that polls endpoints, adding significant development and operational burden. Option D relies on log parsing, which is less efficient for structured metrics and requires managing log groups and queries rather than direct metric ingestion.

Community Comment Notes

Community consensus supports Option A, noting that the CloudWatch Agent provides native support for protocols like StatsD, allowing collection of internal application metrics with minimal configuration. As one user noted, "Options C and D require additional development maintenance," reinforcing that agent-based collection is superior for operational simplicity.

Official Reference

https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Install-CloudWatch-Agent.html

Exam Strategy

When asked for 'least operational overhead' in monitoring, prioritize managed agents or native services over custom code (Lambda) or log parsing. Avoid solutions that require you to write and maintain polling scripts if a standard agent exists.

Frequently Asked Questions

Why is CloudWatch Logs Insights not the best choice?

Logs Insights parses text logs, which is inefficient for structured metrics and requires managing log schemas and queries, increasing operational overhead.

Does the CloudWatch Agent add significant overhead?

No, it is a lightweight daemon installed once on the instance that handles metric aggregation and transmission, reducing application-side coding effort.

More DOP-C02 FAQ →

Related Analysis

Practice All DOP-C02 Questions

Access 85 questions with complete answers and detailed explanations.

View Full DOP-C02 Practice Test →

← Back to DOP-C02 Study Guide