AWS Certified Solutions Architect Professional SAP-C02 Practice Question
Your operations team supports 20 independent microservices that run in a single AWS account. Each microservice is fronted by its own Application Load Balancer (ALB) and already has an Amazon CloudWatch metric alarm that enters the ALARM state when the percentage of HTTP 5XX responses exceeds 1 % for two evaluation periods. During a recent upstream outage, all 20 alarms fired and the on-call engineer was paged 20 times in rapid succession. The team wants to:
Receive only one high-severity notification when any existing service alarm transitions to ALARM and suppress further notifications until the issue is resolved.
Automatically create a Systems Manager Incident Manager incident that runs an SSM Automation runbook to collect diagnostics.
Re-use the existing per-service alarms with minimal additional maintenance.
Which approach satisfies these requirements?
Enable AWS Config and deploy a custom rule that evaluates the ALB HTTPCode_ELB_5XX_Count metric every minute; configure the rule to invoke the Incident Manager response plan when the resource is NON_COMPLIANT.
Modify each existing service alarm so that its state-change notification is sent to an SNS topic; add an EventBridge rule that starts the Incident Manager response plan when the topic receives a message.
Create an Amazon CloudWatch composite alarm in the same account that references the 20 existing service alarms with an OR-based AlarmRule, and configure the composite alarm action to Start incident with a Systems Manager Incident Manager response plan that includes the Automation runbook.
Create a CloudWatch metric math expression that sums the HTTP 5XX error counts for all ALBs, build a new metric alarm on that expression, and configure the alarm to publish to an SNS topic; subscribe the topic to the on-call pager and to a Lambda function that runs the Automation runbook.
Using a CloudWatch composite alarm meets every stated goal. A composite alarm can monitor the state of multiple underlying alarms and evaluate a Boolean rule such as an OR across all 20 service alarms. When the first underlying alarm enters the ALARM state, the composite alarm also enters ALARM, triggers its configured action once, and then suppresses additional notifications while it remains in that state, thereby eliminating alert storms. Composite alarm actions can directly Start incident on a predefined Incident Manager response plan, which in turn can invoke an SSM Automation runbook. No changes are required to the existing per-service metric alarms-they only need to be referenced by the composite alarm.
The metric-math solution would require creating and maintaining a separate expression that must be updated whenever services are added or removed, and it still relies on SNS plus Lambda to start the incident rather than a single built-in action. Publishing every alarm to an SNS topic or using an AWS Config custom rule would still generate one notification per service alarm (or would evaluate too slowly) and therefore would not suppress duplicate pages or meet the 1-minute reaction time expected from CloudWatch alarms.
Ask Bash
Bash is our AI bot, trained to help you pass your exam. AI Generated Content may display inaccurate information, always double-check anything important.
What is a CloudWatch composite alarm, and how does it work?
Open an interactive chat with Bash
How does Systems Manager Incident Manager integrate with CloudWatch composite alarms?
Open an interactive chat with Bash
Why is a composite alarm preferred over metric math or custom AWS Config rules in this scenario?
Open an interactive chat with Bash
AWS Certified Solutions Architect Professional SAP-C02
Continuous Improvement for Existing Solutions
Your Score:
Report Issue
Bash, the Crucial Exams Chat Bot
AI Bot
Loading...
Loading...
Loading...
IT & Cybersecurity Package Join Premium for Full Access