A SaaS company runs 200 EC2 instances with mission-critical API latency. Operations needs instant paging on high CPU and failed status checks, plus automated restart runbooks with audit trail. Which alerting design delivers real-time notifications and automated remediation with governance?

The correct design works because CloudWatch alarms continuously evaluate CPU and system/instance status checks for all 200 instances and publish ALARM transitions instantly to SNS for paging, while the same event triggers SSM Automation runbooks that execute governed restarts with role-based control, concurrency limits, and automatic logging to CloudTrail and CloudWatch, satisfying real-time detection, remediation, and audit together. The PagerDuty-integrated alarming design provides excellent instant paging and incident tracking but is detection-only without an automation engine, so recovery stays manual and the automated restart requirement fails despite meeting latency. The hourly EventBridge scheduler design offers SSM remediation with audit logging but runs on a fixed interval rather than event-driven alarms, so CPU spikes and failed checks wait up to an hour and the instant paging requirement fails for mission-critical latency. The alarm-triggered Lambda reboot design achieves real-time detection and automatic restarts but uses custom code instead of versioned, approved SSM runbooks with centralized logging, so governance and audit trail fail despite operational recovery. Exam caveat: when a stem demands both immediacy and governance, prefer native alarm to SSM Automation over custom Lambda or paging-only integrations that satisfy only one half. Practical check: validate alarm metrics, thresholds and SNS paging subscriptions, SSM execution role least privilege, and CloudTrail entries showing every runbook execution with instance ID and timestamp.