Suitable Scenarios for Creating CloudWatch Alarms Based on Existing Metrics

Correct Answer - A, C.

The key for this question is that it requires existing CloudWatch Metrics, which means that customized Metrics are not allowed.

Other services such as CloudWatch Events or CloudWatch Logs should not be selected as well.

Option A is CORRECT: Because ELB has provided an Average Latency Metrics that can be used to set up a CloudWatch alarm:

Option B is incorrect: Because this should be a use case for CloudWatch Events rather than CloudWatch Alarms:

Option C is CORRECT: Because DynamoDB table has supported the CloudWatch Metrics of throttled read/write events or requests.

Option D is incorrect: Because EC2 instance memory usage is a customized metric that is not natively provided by CloudWatch.

Option E is incorrect: Because CloudWatch EC2 Metrics do not trace detailed application status such as Tomcat error.

This is a use case for customized CloudWatch Logs and an alarm can be created via a Logs Metric Filter.

The two scenarios that are suitable for creating CloudWatch alarms based on existing CloudWatch metrics are:

A. When the latency of ELB exceeds 10 seconds over two minutes, trigger an alarm and send an email notification to your team.

This scenario is suitable for creating a CloudWatch alarm based on an existing CloudWatch metric because it is monitoring a key AWS resource, the ELB (Elastic Load Balancer), and it is using an existing metric, the latency metric. This alarm will trigger when the latency of the ELB exceeds a specified threshold, which indicates that there may be issues with the performance of the ELB. Sending an email notification to the team will ensure that they are aware of the issue and can take appropriate action to address it.

C. Notify the team when excessive throttling occurs for a DynamoDB table that stores users' subscription data.

This scenario is also suitable for creating a CloudWatch alarm based on an existing CloudWatch metric because it is monitoring a key AWS resource, a DynamoDB table, and it is using an existing metric, the throttled requests metric. This alarm will trigger when the number of throttled requests for the DynamoDB table exceeds a specified threshold, which indicates that the table is being overloaded and may be impacting users' subscription data. Notifying the team will ensure that they can take appropriate action to address the issue and prevent any potential data loss.

The other scenarios are not suitable for creating CloudWatch alarms based on existing CloudWatch metrics because:

B. When someone in the development team has provided comments on commit or pull requests in AWS CodeCommit service, notify relevant team members.

This scenario is not suitable for creating a CloudWatch alarm based on an existing CloudWatch metric because it is not monitoring a key AWS resource, and there is no existing CloudWatch metric that can be used to trigger an alarm.

D. When the average EC2 instance memory usage exceeds 95 percent for five minutes, trigger an alarm and launch another EC2 instance.

This scenario is not suitable for creating a CloudWatch alarm based on an existing CloudWatch metric because it is monitoring a key AWS resource, an EC2 instance, but it is not using an existing metric. The metric for EC2 instance memory usage is available in CloudWatch, but this scenario requires monitoring the average memory usage over a five-minute period, which is not an existing CloudWatch metric.

E. When there are some critical Tomcat errors happening in EC2 instances, immediately send an SMS to the on-call support.

This scenario is not suitable for creating a CloudWatch alarm based on an existing CloudWatch metric because it is monitoring a key AWS resource, an EC2 instance, but it is not using an existing metric. There is no existing CloudWatch metric for monitoring Tomcat errors in EC2 instances, so a custom metric would need to be created for this scenario.