CloudWatch alarms in AWS - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ service_behavior

intermediate

Understanding CloudWatch Alarm States

What is the state of a CloudWatch alarm immediately after it is created but before any metric data is received?

A INSUFFICIENT_DATA

B OK

C ALARM

D DISABLED

💡 Hint

Think about what happens when there is no data to evaluate the alarm.

When a CloudWatch alarm is first created, it has no data to evaluate. Therefore, its state is INSUFFICIENT_DATA until metric data arrives and the alarm can evaluate its condition.

❓ Configuration

intermediate

Alarm Configuration for CPU Utilization

You want to create a CloudWatch alarm that triggers when the average CPU utilization of an EC2 instance exceeds 70% for 5 consecutive minutes. Which configuration below correctly sets the evaluation period and threshold?

A EvaluationPeriods=1, Threshold=70, Statistic=Average, Period=300

B EvaluationPeriods=1, Threshold=70, Statistic=Maximum, Period=300

C EvaluationPeriods=5, Threshold=70, Statistic=Sum, Period=60

D EvaluationPeriods=5, Threshold=70, Statistic=Average, Period=60

💡 Hint

Remember that the period is in seconds and evaluation periods count how many periods must breach the threshold.

To check if CPU utilization exceeds 70% for 5 consecutive minutes, set Period to 300 seconds (5 minutes) and EvaluationPeriods to 1. Statistic should be Average to measure average CPU usage.

❓ security

advanced

IAM Permissions for CloudWatch Alarm Actions

Which IAM permission is required to allow a user to create and manage CloudWatch alarms that send notifications to an SNS topic?

A cloudwatch:CreateAlarm and sns:Subscribe

B cloudwatch:PutMetricAlarm and sns:Publish

C cloudwatch:PutAlarm and sns:SendMessage

D cloudwatch:CreateMetricAlarm and sns:Notify

💡 Hint

Check the exact IAM actions for CloudWatch alarms and SNS publishing.

To create or update alarms, the user needs cloudwatch:PutMetricAlarm permission. To send notifications to SNS, sns:Publish permission is required.

❓ Architecture

advanced

Designing a Multi-Region Alarm System

You want to monitor an application deployed in two AWS regions and trigger a single alarm if the error rate exceeds 5% in either region. Which architecture best achieves this?

A Create CloudWatch alarms in each region and configure each to send notifications to separate SNS topics without aggregation.

B Create a single CloudWatch alarm in one region monitoring metrics from both regions directly.

C Create separate CloudWatch alarms in each region and use an SNS topic subscribed by a Lambda function that aggregates and triggers a global alarm.

D Use CloudWatch cross-region dashboards to view both regions but create alarms only in the primary region.

💡 Hint

Consider how CloudWatch alarms work regionally and how to aggregate alerts.

CloudWatch alarms are regional and cannot monitor metrics from other regions directly. Creating alarms in each region and aggregating notifications via SNS and Lambda allows triggering a single global alarm.

✅ Best Practice

expert

Optimizing CloudWatch Alarm Costs and Accuracy

You have many CloudWatch alarms monitoring various metrics. To reduce costs without losing critical alert accuracy, which approach is best?

A Increase the alarm evaluation period and number of evaluation periods to reduce alarm state changes and API calls.

B Set all alarms to use the Maximum statistic and a short period to catch spikes quickly.

C Delete alarms for low-priority metrics and rely on manual monitoring for those.

D Use composite alarms to combine multiple alarms and reduce the number of notifications.

💡 Hint

Think about combining alarms to reduce noise and cost.

Composite alarms combine multiple alarms into one, reducing the number of notifications and API calls, which lowers costs while maintaining alert accuracy.

Practice

1. What is the primary purpose of an AWS CloudWatch alarm?

easy

A. To store large amounts of log data

B. To monitor a specific metric and notify when it crosses a threshold

C. To create virtual servers in the cloud

D. To manage user permissions and roles

Solution

1. Step 1: Understand CloudWatch alarm function

   CloudWatch alarms watch metrics like CPU usage or disk space and alert you when values cross set limits.

2. Step 2: Identify the correct purpose

   Only To monitor a specific metric and notify when it crosses a threshold describes monitoring a metric and notifying on threshold crossing, which is the alarm's job.

3. Final Answer:

   To monitor a specific metric and notify when it crosses a threshold -> Option B

4. Quick Check:

   Alarm = Monitor + Notify [OK]

Hint: Alarms watch metrics and alert on changes [OK]

Common Mistakes:

• Confusing alarms with log storage
• Thinking alarms create servers
• Mixing alarms with user management

2. Which of the following is the correct way to specify a CloudWatch alarm threshold for CPU utilization above 80%?

easy

A. "Threshold": "<=80"

B. "Threshold": 80, "ComparisonOperator": "LessThanThreshold"

C. "Threshold": 80, "ComparisonOperator": "LessThanOrEqualToThreshold"

D. "Threshold": 80, "ComparisonOperator": "GreaterThanThreshold"

Solution

1. Step 1: Understand threshold syntax

   CloudWatch alarms use a numeric Threshold value and a separate ComparisonOperator like GreaterThanThreshold, LessThanThreshold.

2. Step 2: Choose operator for above 80%

   To alert when CPU is above 80%, use "Threshold": 80, "ComparisonOperator": "GreaterThanThreshold".

3. Final Answer:

   "Threshold": 80, "ComparisonOperator": "GreaterThanThreshold" -> Option D

4. Quick Check:

   Above 80% = GreaterThanThreshold(80) [OK]

Hint: Use GreaterThanThreshold for above threshold [OK]

Common Mistakes:

• Using < instead of > for above threshold
• Using = which triggers only at exact value
• Confusing <= with above threshold

3. Given this CloudWatch alarm configuration snippet:

{"MetricName": "CPUUtilization", "Namespace": "AWS/EC2", "Threshold": 70, "ComparisonOperator": "GreaterThanThreshold", "EvaluationPeriods": 3}

What happens if CPU utilization is 75% for 2 consecutive periods and then 65% for the third period?

medium

A. The alarm does not trigger because CPU was not above 70% for all 3 periods

B. The alarm triggers only if CPU is above 70% for 4 periods

C. The alarm triggers immediately when CPU hits 75% the first time

D. The alarm triggers because CPU was above 70% twice

Solution

1. Step 1: Understand EvaluationPeriods meaning

   The alarm triggers only if the metric breaches the threshold for the specified number of consecutive periods (3 here).

2. Step 2: Analyze given CPU values

   CPU was above 70% for 2 periods, then dropped below on the 3rd, so the alarm does not trigger.

3. Final Answer:

   The alarm does not trigger because CPU was not above 70% for all 3 periods -> Option A

4. Quick Check:

   3 periods breach needed, only 2 met [OK]

Hint: Alarm needs all evaluation periods breached [OK]

Common Mistakes:

• Thinking alarm triggers after any single breach
• Ignoring EvaluationPeriods count
• Assuming alarm triggers immediately

4. You created a CloudWatch alarm but it never enters ALARM state even when the metric crosses the threshold. What is a likely cause?

medium

A. The alarm's EvaluationPeriods is set higher than the number of metric data points

B. The alarm threshold is set too low

C. The alarm is configured to notify but not to monitor metrics

D. The SNS topic ARN configured in alarm actions is invalid

Solution

1. Step 1: Check EvaluationPeriods vs data points

   If EvaluationPeriods is more than available metric data points, alarm cannot evaluate properly.

2. Step 2: Confirm impact on alarm state

   Without enough data points, alarm never sees enough breaches to enter ALARM state.

3. Final Answer:

   The alarm's EvaluationPeriods is set higher than the number of metric data points -> Option A

4. Quick Check:

   EvaluationPeriods > data points = no alarm [OK]

Hint: Ensure enough data points for EvaluationPeriods [OK]

Common Mistakes:

• Assuming threshold too low prevents alarm
• Confusing notification with monitoring
• Thinking invalid SNS prevents alarm state

5. You want to create a CloudWatch alarm that triggers an auto-scaling action when average CPU utilization exceeds 60% for 5 minutes, but only if this happens during business hours (9 AM to 5 PM). Which approach best achieves this?

hard

A. Create a CloudWatch alarm with threshold 60% and EvaluationPeriods 1, then use EventBridge to trigger scaling only during business hours

B. Set the alarm threshold to 60% and EvaluationPeriods to 5, and configure the alarm to be active only during business hours

C. Create a CloudWatch alarm with threshold 60% and EvaluationPeriods 5, then use a Lambda function triggered by the alarm to check time and trigger scaling

D. Set the alarm threshold to 60% and EvaluationPeriods 5, and configure auto-scaling to ignore alarms outside business hours

Solution

1. Step 1: Understand alarm and time condition needs

   CloudWatch alarms alone cannot restrict triggering by time; external logic is needed.

2. Step 2: Evaluate options for time-based control

   Using a Lambda triggered by the alarm to check current time and decide on scaling is flexible and precise.

3. Step 3: Assess other options

   EventBridge can schedule events but not filter alarm triggers by time; auto-scaling ignores alarms is not a feature.

4. Final Answer:

   Create a CloudWatch alarm with threshold 60% and EvaluationPeriods 5, then use a Lambda function triggered by the alarm to check time and trigger scaling -> Option C

5. Quick Check:

   Alarm + Lambda time check = controlled scaling [OK]

Hint: Use Lambda to add time logic after alarm triggers [OK]

Common Mistakes:

• Expecting alarm to handle time filtering alone
• Assuming auto-scaling ignores alarms by time
• Using EventBridge without alarm integration