DOPインシデントとイベントへの対応
ある企業のDevOpsチームは、複数の本番アプリケーションを AWS CloudFormation スタックで管理している。運用担当者がインシデント対応中にマネジメントコンソールから手動でセキュリティグループや Auto Scaling の設定を変更することがあり、これがスタックの実構成とテンプレートの乖離（ドリフト）を生んで、後続デプロイの失敗や再現性の低下を招いている。チームは全スタックのドリフトを毎日自動で検出し、ドリフトが見つかったスタックについては DevOps 担当者へ通知したうえで、承認後にテンプレート定義の状態へ戻せる運用を、常時稼働の追加インフラなしで構築したい。最も適切な方法はどれか。
AAmazon EventBridge のスケジュールルールで毎日 Lambda を起動し、各スタックに対して DetectStackDrift を呼び出す。DRIFTED のスタックを Amazon SNS で通知し、承認後に元テンプレートでスタックを更新して修正する。
✓ 正解
DetectStackDrift を EventBridge スケジュールルール＋Lambda で毎日呼び出せば、常時稼働インフラなしで全スタックのドリフトを定期検出できる。DRIFTED のみ SNS 通知し承認後に元テンプレートで更新する流れが、検出・通知・承認後修正の要件に完全に合致する。
BAWS Config のマネージドルール cloudformation-stack-drift-detection-check を有効化し、非準拠と評価されたスタックに Systems Manager Automation の自動修復アクションを関連付けて、検出と同時にテンプレート状態へ即座に自動で戻す。
cloudformation-stack-drift-detection-check はドリフト検出には使えるが、SSM Automation で検出と同時に無条件で自動的に元へ戻すため、DevOps 担当者の承認後に修正するという明示要件を満たさない点で不適切。
CAWS Config の設定タイムラインで各スタックのリソース変更履歴を毎日目視で確認し、変更が見つかったスタックを手動で再デプロイしてドリフトを解消する運用フローを整備する。
Config の設定タイムラインはリソース変更の履歴確認には有効だが、毎日の目視チェックと手動再デプロイは自動化されておらず運用負荷が大きい。自動検出・通知の要件を満たさないため不適切。
DCloudFormation のスタックポリシーを全リソースに適用して手動変更をブロックし、ドリフトの発生自体を防ぐ。変更が必要なときはスタックポリシーを一時的に更新して対応する。
スタックポリシーはスタック更新時に特定リソースの上書きを制御する仕組みで、コンソールからの手動変更によるドリフトそのものを防止できない。ドリフト検出・通知の要件にも対応しないため不適切。
解説
CloudFormation の DetectStackDrift API は、スタックの実リソースとテンプレート定義の差分（ドリフト）を検出できる。EventBridge のスケジュールルールで毎日 Lambda を起動し、各スタックの DetectStackDrift を非同期で呼び出して結果を評価すれば、常時稼働インフラなしで定期検出が実現できる。DRIFTED のスタックのみ SNS で通知し、承認後に元テンプレートでスタックを更新すれば「検出→通知→承認後修正」の要件を満たせる。
選択肢1の AWS Config ルールは、ドリフト検出自体は可能だが、SSM Automation による無条件の即時自動修復は「承認後に戻す」という要件に反する。
選択肢2の AWS Config 設定タイムラインは、リソース変更の追跡はできるが毎日の目視確認と手動再デプロイは運用負荷が高く、自動検出の要件を満たさない。
選択肢3のスタックポリシーは、スタック更新時の特定リソース保護のための仕組みであり、コンソールからの直接的な手動変更（ドリフト）を防止する機能ではない。
ドメイン別正答率・予想スコアでリアルタイムに実力把握
無限ノックでDOPを徹底対策。全問AI生成のオリジナル問題。
無料で演習を始める →