Composite alarms determine their states by monitoring the states of other alarms. You can **use composite alarms to reduce alarm noise**. For example, you can create a composite alarm where the underlying metric alarms go into ALARM when they meet specific conditions. You then can set up your composite alarm to go into ALARM and send you notifications when the underlying metric alarms go into ALARM by configuring the underlying metric alarms never to take actions. Currently, composite alarms can take the following actions: https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Create_Composite_Alarm.html

By creating composite alarms in CloudWatch, the solutions architect can combine multiple metrics, such as CPU utilization and read IOPS, into a single alarm. This allows the company to take action only when both conditions are met, reducing false alarms and focusing on meaningful alerts. B can help in monitoring the overall health and performance of the application. However, it does not directly address the specific requirement of triggering an action when CPU utilization and read IOPS exceed certain thresholds simultaneously. C. Creating CloudWatch Synthetics canaries is useful for actively monitoring the application's behavior and availability. However, it does not directly address the specific requirement of monitoring CPU utilization and read IOPS to trigger an action. D. Creating single CloudWatch metric alarms with multiple metric thresholds where possible can be an option, but it does not address the requirement of triggering an action only when both CPU utilization and read IOPS exceed their respective thresholds simultaneously.

composite alarms are suited for scenarios where we have to combine the alarms for different metrics or dimensions, rather than for multiple threshold of the same metric. It contradict with option A.

Composite for multiple conditions like AND/OR combinations B: This option just made me laugh. Lol, will someone just sit and look at this dashboard? C: CW Synthetics canaries if for API D: Single won't monitor multiple metrics

A: Composite alarms determine their states by monitoring the states of other alarms. You can use composite alarms to reduce alarm noise. For example, you can create a composite alarm where the underlying metric alarms go into ALARM when they meet specific conditions.

Composite alarms was designed to handle this scenario.

The key reasons are: Composite alarms allow defining alarms with multiple metrics and conditions, like high CPU AND high read IOPS in this case. Composite alarms can avoid false positives triggered by a single metric spike. Dashboards help visualize but won't take automated action. Synthetics tests application availability but doesn't address the metrics. Single metric alarms with multiple thresholds can't correlate across metrics and may still trigger false positives. Composite alarms allow acting quickly when both CPU and IOPS are high, per the stated need.

The composite alarm goes into ALARM state only if all conditions of the rule are met.

Option A, creating Amazon CloudWatch composite alarms, is correct because it allows the solutions architect to create an alarm that is triggered only when both CPU utilization is above 50% and read IOPS on the disk are high at the same time. This meets the requirement to act as soon as possible if both conditions are met, while also reducing the number of false alarms by ensuring that the alarm is triggered only when both conditions are met.

A is correct answer

Option A

The AWS::CloudWatch::CompositeAlarm type creates or updates a composite alarm. When you create a composite alarm, you specify a rule expression for the alarm that takes into account the alarm states of other alarms that you have created. The composite alarm goes into ALARM state only if all conditions of the rule are met. The alarms specified in a composite alarm's rule expression can include metric alarms and other composite alarms.Using composite alarms can reduce alarm noise.

A is correct