A fintech payments platform must page on-call engineers within two minutes when API error rates spike, notify support by email for warnings, and run an automated runbook to restart the service for critical faults. Alerts must avoid noise during deployments. Which alerting solution best meets these detection and response requirements?

The correct design succeeds because CloudWatch metric alarms evaluate API error rates on short periods for two-minute paging, SNS topics fan out to a paging integration for spikes and email for warnings, and an EventBridge rule on the critical alarm state change starts a Systems Manager Automation runbook to restart the service without human delay, and composite alarms combine deployment health with error state to suppress noise during releases, covering speed, routing, automation, and quiet deployments in one managed path. The design using metric alarms with paging, email, and runbooks but no composite logic handles detection and response well but fails deployment suppression, so routine releases that temporarily raise errors would still trigger pages and restarts. The design using composite alarms for paging and email without automation meets speed, routing, and suppression but fails automated remediation, leaving critical restart as manual work and violating hands-off recovery. The design using composite alarms with runbooks and email for every severity meets suppression and automation but fails urgent notification, because email lacks guaranteed rapid acknowledgement and collapses warnings and critical spikes into the same channel. On exams, focus on severity-specific delivery and suppression wording, as sound designs often differ by only one missing capability. Practically, confirm period plus evaluation windows stay under two minutes, test paging and email subscriptions separately, and simulate a deployment to prove suppression blocks noise without hiding real faults.