DOP-C02 Monitoring and Logging Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✓

  Configure the CloudWatch agent to emit custom metrics to CloudWatch.

  Why this is correct

  The CloudWatch agent is the correct mechanism for collecting custom metrics from an EKS cluster and emitting them to CloudWatch. By configuring the agent with a metrics collection interval and a custom namespace, you can send application and cluster-level metrics (e.g., pod CPU, memory, or custom application counters) via the PutMetricData API. This is the foundational step that makes those metrics available for dashboards, alarms, and further analysis within CloudWatch, so it is a required part of a CloudWatch-centric monitoring solution.

• ✗

  Use CloudWatch Logs Insights to analyze the custom metrics.

  Why it's wrong here

  CloudWatch Logs Insights is a query engine designed specifically for searching and analyzing log data stored in CloudWatch Logs, using a purpose-built query language (e.g., fields, stats, filter). It has no capability to read or analyze metric data points; metrics are time-series numeric values, not log events. Attempting to use Logs Insights for custom metrics would fail because there is no automated path to ingest metrics into a log group, and the tool only interprets timestamped log messages, not numeric metric samples.

• ✓

  Create a CloudWatch dashboard to visualize the collected metrics.

  Why this is correct

  A CloudWatch dashboard is a visualization layer that pulls together metric graphs, text, and alarm status into a single view. After the CloudWatch agent has emitted custom metrics, those metrics can be added to a dashboard via widgets, giving operations teams real-time visibility into cluster health and application performance. This step is correct because it fulfills the monitoring goal of aggregating and presenting the collected data, but it assumes the metrics already exist in CloudWatch from the agent emission.

• ✓

  Install the CloudWatch agent on the EKS cluster using a DaemonSet.

  Why this is correct

  The CloudWatch agent must be deployed on an EKS cluster as a DaemonSet to ensure it runs on every worker node and collects node-level and pod-level metrics. Using a DaemonSet guarantees that as nodes are added or scaled out, the agent is automatically scheduled to the new nodes, providing comprehensive coverage without manual intervention. The agent also requires an IAM role (e.g., via IRSA or a service account) with permissions like cloudwatch:PutMetricData to successfully forward the collected metrics to CloudWatch.

• ✗

  Use Amazon Managed Service for Prometheus to scrape the metrics.

  Why it's wrong here

  Amazon Managed Service for Prometheus (AMP) is a fully managed, Prometheus-compatible monitoring service that scrapes metrics from Kubernetes endpoints, and it does support querying and alerting via PromQL. However, it is a separate monitoring stack with its own data store and console, and it is not directly integrated with CloudWatch dashboards or CloudWatch alarms unless you set up additional exporters or remote write configurations. In a solution explicitly focused on using CloudWatch for visualization and alerting, choosing AMP would introduce unnecessary complexity and diverge from the question's requirement to emit metrics directly to CloudWatch.

Go deeper

Related to this question