理解確認：AlertingとAutomatic Remediation

既存の運用環境ではCloudWatch アラームが40個あるが、通知を受けた担当者ごとに対応が異なり、誰が何をするか決まっていない。最初に改善すべきことはどれか。

CloudWatch アラームの対象障害は原因判定が明確で、復旧操作は事前検証済み、影響範囲も限定され、成功条件も機械的に確認できる。最も適切な対応方針はどれか。

本番データ処理を一時停止する復旧操作をSystems Manager Automationで標準化したい。ただし業務影響が大きいため、実行前に責任者の承認が必要である。最も適切な設計はどれか。

同じ種類の障害について、復旧手順そのものは標準化されている。しかし、影響範囲によって「担当者が確認して実行する」「責任者の承認後に実行する」「即時に自動実行する」を使い分けたい。最も適切な設計方針はどれか。

アプリケーションの5xx率が上昇したが、原因はアプリケーション、データベース、外部依存のいずれも考えられる。復旧操作によって本番全体へ影響する可能性もある。最も適切な自動修復方針はどれか。

Systems Manager Automationで段階的な復旧処理を実行する。処理の途中で別の安全性メトリクスが悪化した場合は、残りの処理を継続せず停止したい。最も適切な設計はどれか。

既存サービスで自動修復を導入する。自動処理だけで完結させず、人へのエスカレーションへ切り替える条件として適切なものを3つ選択してください。

運用チームには多数の通知が届くが、受信しても行う作業がない通知が多く、重要な通知を見落としている。改善として最も適切なものはどれか。

重大な業務障害が発生した。一次運用担当者は定義済み手順を実行できるが、復旧しない場合のサービス停止判断や業務部門との調整権限は持っていない。次の対応として最も適切なものはどれか。

Systems Manager Automationで本番リソースを修復するランブックを運用する。必要以上の権限を持つ利用者の認証情報に依存せず、安全に実行したい。最も適切な権限設計はどれか。

責任者の承認を待ってからSystems Manager Automationを続行するためaws:approveの利用を検討している。現在の仕様について最も正しいものはどれか。

既存サービスではCloudWatch アラームを障害検知に使用している。既知の低影響障害ではSystems Manager Automationを起動し、別の重大アラームでは人への通知へ振り分けたい。検知条件はCloudWatch アラーム側に残し、応答先の振り分けをアラーム設定へ埋め込みたくない。

この責任分離を実現する構成として最も適切なものはどれか。