CloudWatch Agent（設定のSSM Parameter Store配布）難易度 標準無料
Auto Scalingグループで管理される数十台規模のEC2インスタンス（同一のCloudWatch Agent設定を使う）に対し、エージェント設定ファイルを一元管理し、新規起動インスタンスにも自動的に同じ設定を適用したい。個々のインスタンスに設定ファイルを手動コピーする運用は避けたい。最も適切な設計を選べ。（単一選択）
- ACloudWatch Agentの設定JSONをSystems Manager Parameter Storeへ保存し、起動時のユーザーデータで
amazon-cloudwatch-agent-ctl -a fetch-config -c ssm:<parameter-name>のように参照させる - B設定ファイルをあらかじめ書き込んだ状態でAMIを作成し、Auto Scalingグループの起動テンプレートで常にそのAMIを参照する
- C各インスタンスにSSHで個別ログインし、設定ファイルを手動でコピー・配置してエージェントを再起動する
- DCloudFormationのスタック更新のたびにUserDataスクリプト内へ設定JSONの全文をハードコーディングし、スタック更新で反映する
正解・解説・誤答理由・ひっかけを見る▼ open
✓ 正解：AAI作成・独立検証済
解説
CloudWatch Agentは、設定ウィザード（amazon-cloudwatch-agent-config-wizard）で生成したJSON設定を、
Systems Manager Parameter Storeにパラメータとして保存し、各インスタンスは起動時に
amazon-cloudwatch-agent-ctl の -c ssm:<parameter-name> オプションでその設定を取得・適用する運用に対応している。
- この方式であれば、設定を1箇所（Parameter Store）で更新するだけで、以後起動するインスタンス（Auto Scaling起動時など）は 起動スクリプト（ユーザーデータ）経由でSSMパラメータを参照し常に最新の設定を取得できる。
- 設定変更時も、Parameter Store側を更新して既存インスタンス群にエージェント再起動（設定の再取得）をSSM Run Command等で一括実行すれば足り、 個々のインスタンスへ手動でファイルをコピーする必要がない。
- 設定をParameter Storeへ書き込む側（管理者・CI/CDパイプライン）には
CloudWatchAgentAdminPolicyが必要（前問のCloudWatchAgentServerPolicyは実行側インスタンスに付与するロール）。
- B動作はするが、設定変更のたびにAMI再作成・起動テンプレート更新が必要になり、一元管理・即時反映という要件に対しては運用コストが高い。
- C要件で明示的に避けたいとされている「手動コピー」の運用そのもの。数十台規模・新規起動インスタンスへの自動適用には向かない。
- D設定変更のたびにスタック更新（インスタンスの置き換え等）を伴う重い手順になり、Parameter Store経由の軽量な一元管理に比べ運用性が劣る。
ひっかけ： 「AMIに設定ファイルを焼き込む（B）」でも動きはするが、設定変更のたびにAMIを作り直してAuto Scalingの起動テンプレートを更新する運用になり、
設定の一元管理・即時反映という点でSSM Parameter Store方式より運用コストが高い。
公式ドキュメント・関連Amazon CloudWatch User Guide ― Store the CloudWatch agent configuration file in Parameter Store↗
AIが作成し、独立した検証を経た解説です（有資格者による監修は経ていません）