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 the Elastic Beanstalk management console to manually check the health status twice a day.

  Why it's wrong here

  Manual checks require a human to log in to the Elastic Beanstalk console, navigate to the environment's Health page, and visually assess the status. This approach is not automated, so it cannot trigger immediate notifications when a deployment fails or the application becomes unhealthy. Scheduled manual checks twice a day also miss transient failures that resolve before the next login, and the process is error-prone and does not scale across multiple environments.

• ✓

  Create a CloudWatch alarm on the 'EnvironmentHealth' metric published by the Elastic Beanstalk environment.

  Why this is correct

  Elastic Beanstalk with enhanced health reporting publishes the 'EnvironmentHealth' metric to CloudWatch, and creating an alarm on this metric allows you to react automatically when the environment transitions to states such as severe or degraded. The alarm can publish to an SNS topic to email or page the team, enabling real-time incident response without any custom code. This approach is the native, supported integration between Elastic Beanstalk health and CloudWatch observability.

• ✗

  Write a custom script that polls the Elastic Beanstalk DescribeEnvironmentHealth API and sends an email using Amazon SES.

  Why it's wrong here

  A custom script polling the `DescribeEnvironmentHealth` API introduces unnecessary latency and operational overhead, whereas Elastic Beanstalk natively emits health state transitions as Amazon CloudWatch Events that can directly trigger an SNS notification. This approach is tempting because it offers fine-grained control over polling intervals and custom logic, and would be correct if the team needed to aggregate health data across multiple environments or apply custom transformation before alerting.

• ✗

  Configure an AWS CloudTrail trail to monitor Elastic Beanstalk API calls and create a CloudWatch alarm on the trail.

  Why it's wrong here

  CloudTrail records API calls made by or on behalf of the Elastic Beanstalk environment, such as CreateEnvironment, UpdateEnvironment, or TerminateEnvironment, for auditing and security investigation. It does not ingest the environment's health state, because health metrics like EnvironmentHealth are not API events and therefore never appear as CloudTrail events. Even if you create a CloudWatch alarm based on a filter on CloudTrail logs, it would only capture administrative actions, not whether the application is responding or a deployment has degraded the service.

Go deeper

Related to this question