Give the node instance profile CloudWatchAgentServerPolicy and run the CloudWatch agent, then query pod memory by Service
A company recently migrated its application to an Amazon Elastic Kubernetes Service (Amazon EKS) cluster that uses Amazon EC2 instances. The company configured the application to automatically scale based on CPU utilization. The application produces memory errors when it experiences heavy loads. The application also does not scale out enough to handle the increased load. The company needs to collect and analyze memory metrics for the application over time. Which combination of steps will meet these requirements? (Choose three.)
Community Votes
100% of anonymous learners picked answer ACE. Votes are pick records left by other test-takers — they are not the verified answer.
Community Insight
The CloudWatch agent runs as a process on each EC2 node, so its permissions belong on the node's IAM instance profile, not on a Kubernetes service account role (A rather than B); a service account role is the correct pattern for IRSA-based agents that make AWS API calls from within pods, not for a node-level agent. Deploying the agent on existing nodes and adding it to the AMI for new nodes covers the whole autoscaling fleet (C). Querying pod_memory_utilization by the Service dimension yields per-service memory over time, which is what identifies the leaking workload (E).
Memory errors under heavy load require collecting memory metrics over time from the EKS cluster's EC2 worker nodes. The unified Amazon CloudWatch agent is deployed as a DaemonSet-style deployment on the existing nodes and baked into the AMI for future nodes, and it needs permission to publish metrics, which comes from attaching the CloudWatchAgentServerPolicy managed policy to the IAM instance profile the cluster already uses. Analysis is then done on the pod_memory_utilization metric in the ContainerInsights namespace using the Service dimension, which attributes memory usage to the Kubernetes service consuming it.
Attaching CloudWatchAgentServerPolicy to a Kubernetes service account role (B) — the CloudWatch agent in this design runs on the EC2 worker nodes, so it authenticates with the node instance profile; a service account role would not grant the agent the permissions it needs to publish metrics. Deploying the AWS Distro for OpenTelemetry collector as a DaemonSet (D) — that is a valid alternative agent, but the requirement here is the unified CloudWatch agent that produces the ContainerInsights pod metrics, so the Distro for OpenTelemetry choice is not the one that feeds the metric being analyzed.
Community Discussion (5 comments)
Comments & Corrections
No comments yet — spotted an error or have a note? Share it below.
Expert Analysis
Why the Answer Is Correct
The unified Amazon CloudWatch agent must be present on every worker node so it can collect memory metrics, and because nodes come and go with the Auto Scaling group it must be deployed both as a DaemonSet-style deployment on the existing EC2 instances and added to the AMI so newly launched nodes have it automatically (C). The agent publishes metrics through the credentials of the node it runs on, so the CloudWatchAgentServerPolicy managed policy must be attached to the IAM instance profile the cluster uses (A), which grants it permission to push metrics to CloudWatch. With metrics flowing, analyzing the pod_memory_utilization metric in the ContainerInsights namespace using the Service dimension (E) shows memory consumption per Kubernetes service over time, which is what surfaces the workload causing the memory errors and the insufficient scale-out.Why the Other Options Are Wrong
B attaches CloudWatchAgentServerPolicy to a Kubernetes service account role. A service account role is the correct mechanism when a component makes AWS API calls from inside a pod using IAM roles for service accounts; the node-level CloudWatch agent in this design runs on the EC2 instance itself and uses the node's instance profile, so granting the policy to a service account role would not give the agent the access it needs. D deploys the AWS Distro for OpenTelemetry collector as a DaemonSet, which is a legitimate agent technology but is not the unified CloudWatch agent that produces the ContainerInsights metrics being analyzed, so it does not satisfy the stated metric-collection path. A, C, and E are the correct combination.Community Comment Notes
Community voted A,C,E (84), with B,C,E variants in the minority. trungtd and jamesf identified that CloudWatchAgentServerPolicy belongs at the EC2 instance level because that is where the agent runs, and that the CloudWatch agent collects the memory metrics. The minority commenters preferred a service account role, but that applies to agents calling AWS APIs from within pods rather than a node-level agent.Official Reference
Related Analysis
Practice All DOP-C02 Questions
Access 85 questions with complete answers and detailed explanations.
View Full DOP-C02 Practice Test →