DOP構成管理と Infrastructure as Code (IaC)
あるチームはCodePipelineを使用してCloudFormationスタックを本番環境にデプロイしています。以下の2つの要件があります。
①本番デプロイ前に変更内容をセキュリティチームが確認・承認する必要がある。
②リソースの置換（Replacement）を含む変更は承認フロー前に自動検出してチームに明示的に警告する。
この要件を満たす最も適切なパイプライン構成はどれですか？
ACodePipelineのCloudFormationアクションをActionMode: CREATE_UPDATEで設定してデプロイし、CloudTrailイベントをEventBridgeで検知して変更内容をSNSでセキュリティチームに通知する。問題があれば通知後に手動でロールバックする
CloudFormationアクション（CREATE_UPDATE）で直接デプロイするため、本番変更が先に適用されてしまい、事前に置換リソースを検出・確認できません。CloudTrailやEventBridgeの通知は事後的なもので、危険な置換を事前に阻止できません。
Bパイプラインを①CHANGE_SET_REPLACEアクション（変更セット作成）②Lambda Invokeアクション（DescribeChangeSet APIでReplacement=Trueのリソースを検出し承認リクエストに警告を付加）③Manual Approvalアクション④CHANGE_SET_EXECUTEアクションの順に構成する
✓ 正解
CHANGE_SET_REPLACEで変更セットを作成し、Lambda関数がDescribeChangeSet APIでReplacement=Trueのリソースを検出。その情報をManual Approvalに付加することで承認者が置換リソースの影響を十分に理解した上で判断できます。段階的で要件を満たすアプローチです。
Cパイプライン先頭にManual Approvalアクションを配置してセキュリティチームがソースコードレビューを事前実施した後、ActionMode: REPLACE_ON_FAILUREでデプロイする。Replacementリソースの検出にはAWS Configカスタムルールを使用する
事前のソースコードレビューは変更セット内容の確認と異なります。AWS Config カスタムルールでは置換検出はできず、実際の変更セット内容における置換リソースを特定できません。検出手段として不足しています。
DCloudFormation StackPolicyですべてのリソースのReplacementタイプ更新をDenyに設定し、Manual Approvalを廃止してポリシー拒否エラーをセキュリティチームへのアラートとして運用する
Stack Policyですべての置換タイプ更新をDenyに設定すると、正当な置換更新まで拒否されて柔軟性を失います。一部の置換は必要な場合があり、全面禁止は過度に制限的で運用に支障が出ます。
解説
CHANGE_SET_REPLACEで変更セットを作成後、Lambda関数がDescribeChangeSet APIを呼び出してReplacement=Trueのリソースを検出し警告をManual Approvalのコメントに付加することで、承認者は置換リソースを把握した上で判断できます。その後CHANGE_SET_EXECUTEでデプロイします。
選択肢AはActionMode: CREATE_UPDATEでデプロイが先行するため本番変更が先に適用されてしまい、事後通知では承認前検出という要件を満たせません。
選択肢Cのソースコードレビューは変更セットの具体的な変更内容確認と等価ではなく、Replacementリソースの自動検出も行われないため不十分です。
選択肢DのCloudFormation StackPolicyでReplacement全面禁止はすべての置換変更を一律拒否してしまい、承認フローによる柔軟な管理ができなくなります。
ドメイン別正答率・予想スコアでリアルタイムに実力把握
無限ノックでDOPを徹底対策。全問AI生成のオリジナル問題。
無料で演習を始める →