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.

• ✗

  Use AWS Auto Scaling to scale the ECS service based on the custom metric.

  Why it's wrong here

  AWS Auto Scaling is a distinct service used for unified scaling of resources such as EC2 Auto Scaling groups, DynamoDB tables, and Aurora replicas. ECS service scaling, however, is implemented through Application Auto Scaling, which is the service that owns scaling policies for ECS services. Referencing AWS Auto Scaling by name is misleading because it is not the direct API or service that manages ECS service scaling.

• ✗

  Create a CloudWatch dashboard to visualize the metric and manually adjust the service count.

  Why it's wrong here

  A CloudWatch dashboard is purely a visualization tool that displays metric graphs and does not have the ability to change the ECS service desired count. Manually adjusting the desired count based on the dashboard requires human intervention, which is neither automated nor reliable under fluctuating load. Proper scaling requires a policy-based approach that reacts automatically, such as a target tracking policy in Application Auto Scaling.

• ✓

  Publish the custom metric to Amazon CloudWatch, then create a target tracking scaling policy in Application Auto Scaling for the ECS service.

  Why this is correct

  The recommended approach is to first publish the custom application metric to Amazon CloudWatch using the PutMetricData API, ensuring it has the appropriate ECS service dimensions. Then, in Application Auto Scaling, create a target tracking scaling policy that references that custom metric; the policy automatically calculates the required desired count to maintain the target value, and adjusts the ECS service accordingly. This provides native, automated scaling with built-in cooldowns and no additional compute, making it the most operationally efficient solution.

• ✗

  Use an AWS Lambda function to directly update the desired count of the ECS service based on the metric.

  Why it's wrong here

  An AWS Lambda function could be scheduled or triggered by a CloudWatch alarm to directly call UpdateService and change the desired count, but this is a custom, non-native solution. It adds complexity because you must implement cooldown logic, handle race conditions, manage IAM permissions, and monitor execution; Application Auto Scaling already provides these features natively for ECS services. Therefore, while possible, it is not a best practice and is inferior to using a target tracking scaling policy.

Go deeper

Related to this question