AWS Certified DevOps Engineer – Professional (DOP-C02) — Question 328

A DevOps engineer manages a Java-based application that runs in an Amazon Elastic Container Service (Amazon ECS) cluster on AWS Fargate. Auto scaling has not been configured for the application.

The DevOps engineer has determined that the Java Virtual Machine (JVM) thread count is a good indicator of when to scale the application. The application serves customer traffic on port 8080 and makes JVM metrics available on port 9404.

Application use has recently increased. The DevOps engineer needs to configure auto scaling for the application.

Which solution will meet these requirements with the LEAST operational overhead? (Choose two.)

Answer options

• A. Deploy the Amazon CloudWatch agent as a container sidecar. Configure the CloudWatch agent to retrieve JVM metrics from port 9404. Create CloudWatch alarms on the JVM thread count metric to scale the application. Add a step scaling policy in Fargate to scale up and scale down based on the CloudWatch alarms.
• B. Deploy the Amazon CloudWatch agent as a container sidecar. Configure a metric filter for the JVM thread count metric on the CloudWatch log group for the CloudWatch agent. Add a target tracking policy in Fargate. Select the metric from the metric filter as a scale target.
• C. Create an Amazon Managed Service for Prometheus workspace. Deploy AWS Distro for OpenTelemetry as a container sidecar to publish the JVM metrics from port 9404 to the Prometheus workspace. Configure rules for the workspace to use the JVM thread count metric to scale the application. Add a step scaling policy in Fargate. Select the Prometheus rules to scale up and scaling down.
• D. Create an Amazon Managed Service for Prometheus workspace. Deploy AWS Distro for OpenTelemetry as a container sidecar to retrieve JVM metrics from port 9404 to publish the JVM metrics from port 9404 to the Prometheus workspace. Add a target tracking policy in Fargate. Select the Prometheus metric as a scale target.

Correct answer: A, D

Explanation

Option A is correct because deploying the CloudWatch agent as a sidecar to collect Prometheus metrics on port 9404 and using step scaling based on CloudWatch alarms is a standard, low-overhead way to scale ECS. Option D is correct because using AWS Distro for OpenTelemetry (ADOT) as a sidecar to send metrics to Amazon Managed Service for Prometheus allows target tracking scaling using the Prometheus metrics. Options B and C are incorrect because they introduce unnecessary overhead or describe unsupported scaling mechanisms directly from Prometheus rules.