WEB問題集
運用エンジニアは複数の AWS アカウントとリージョンに同一の VPC ベースライン CloudFormation テンプレートを展開する必要があります。新規アカウント追加時にも自動展開させたい場合、最も適した方法はどれですか。
正解：A
正解の根拠
CloudFormation StackSets は Organizations と統合することで、OU 配下の全アカウント・指定リージョンへ一括展開でき、自動デプロイを有効化すると新規参加アカウントへもベースラインが自動適用されます。これによりガバナンス維持と運用負荷削減を両立できます。
展開方式の比較
| 方式 | 新規自動適用 | 運用負荷 |
|---|---|---|
| StackSets + Org | あり | 低 |
| 個別スタック | なし | 高 |
| Service Catalog | 手動起動 | 中 |
| パイプライン乱立 | 個別構築要 | 高 |
設定例
aws cloudformation create-stack-set
--stack-set-name vpc-baseline
--template-body file://vpc.yaml
--permission-model SERVICE_MANAGED
--auto-deployment Enabled=true,RetainStacksOnAccountRemoval=false不正解の理由
- B: Service Catalog は自動展開を直接行わず、各アカウントでの起動操作が必要となり新規アカウント自動適用に不適です。
- C: パイプライン乱立は管理が煩雑になり、整合性確保が困難でアカウント追加時の自動化要件にも対応できません。
- D: 個別 CLI 実行はオペレーションミスと工数が大きく発生し、新規アカウント追加時の自動展開要件を満たせません。
運用チームは EC2 フリートに対して脆弱性パッチを月次で自動適用したいと考えています。承認済みのパッチのみを対象にし、メンテナンスウィンドウ内で並列実行する必要があります。最も適した構成はどれですか。
正解：B
正解の根拠
SSM Patch Manager はパッチベースラインで承認ルールを定義し、メンテナンスウィンドウで時間枠と並列度（同時実行数・エラー率）を制御できます。スキャン・適用結果は Compliance に記録され、運用基準に沿った定期パッチ運用が可能です。
パッチ運用方式の比較
| 方式 | 承認ルール | 並列制御 |
|---|---|---|
| Patch Manager | あり | あり |
| cron + yum | なし | なし |
| Lambda + Run Command | 自作要 | 限定的 |
不正解の理由
- A: CodeDeploy はアプリケーション配布が目的のサービスで、OS パッチの承認・適用管理機能を持たず設計目的が異なります。
- C: cron + yum 直叩きは承認管理や Compliance 記録ができない副作用があり、ガバナンス要件と監査追跡に不足があります。
- D: Lambda + Run Command はベースライン管理が不在で Compliance 記録も Patch Manager 相当の整備が必要となる副作用があります。
運用チームは Linux と Windows が混在する EC2 群に対し、定期的にカスタムソフトウェアをインストール・更新する必要があります。集中管理されたリポジトリから署名検証付きで配布したい場合、最適なサービスはどれですか。
正解：D
正解の根拠
SSM Distributor はクロスプラットフォーム対応のソフトウェアパッケージ配布機能で、バージョン管理と署名検証を行えます。State Manager と組み合わせると、関連付けに従って継続的に最新版が維持されます。
配布方式の比較
| 方式 | OS 横断 | 署名検証 |
|---|---|---|
| Distributor | あり | あり |
| CodeDeploy | あり（アプリ向け） | 限定 |
| cron + wget | あり（自前） | 自作要 |
| Beanstalk | 環境再構築 | 該当外 |
不正解の理由
- A: CodeDeploy はアプリデプロイ向けで、汎用パッケージ配布の集中管理として設計目的が異なります。
- B: cron+wget+Lambda 独自署名検証は標準機能の再発明で、バージョン管理と検証の副作用が大きい構成です。
- C: 環境再構築は重く、定期配布の設計目的とは異なる副作用があります。
運用チームは CloudFormation で更新する前に、変更がリソースに与える影響を事前に確認したいと考えています。最も適切な方法はどれですか。
正解：C
正解の根拠
Change Sets は提案された変更がどのリソースを追加・変更・置換するかを事前に表示します。実行するか破棄するかを選択でき、計画と承認を分離した安全な更新フローを実現します。
変更管理手法の比較
| 機能 | 事前影響確認 |
|---|---|
| Change Sets | あり（提案差分） |
| 直接更新 | なし |
| 並行新スタック | 不可（重複） |
| Drift Detection | 実環境ズレ確認 |
不正解の理由
- A: Drift Detection は実環境とテンプレートのズレ検出が目的の機能で、変更内容の事前評価機能は提供していません。
- B: 並行新スタック作成方式はリソースが二重化される副作用があり、データ移行も別途必要となるためコスト負荷が大きい構成です。
- D: 直接更新失敗時の手動ロールバックは復旧時間が読めない副作用があり、本番環境の変更管理として推奨されない方式です。
参考：Change Sets
運用エンジニアは Lambda 関数の機能フラグを実行時に変更し、検証用ユーザーのみ新機能を有効化したいと考えています。デプロイなしで切替可能で、誤設定検知も自動で行いたい場合、最適な選択はどれですか。
正解：D
正解の根拠
AppConfig は機能フラグや動的構成をホストし、JSON Schema や Lambda バリデータで検証してから段階デプロイ（カナリア / リニア）できます。失敗時の自動ロールバック機能もあり、Lambda 拡張で低レイテンシに取得可能です。
動的構成手法の比較
| 方式 | 段階適用 | 検証 |
|---|---|---|
| AppConfig | あり | あり |
| Parameter Store | なし | なし |
| CodeDeploy | 該当外（コード） | 該当外 |
| Secrets Manager | なし | なし |
不正解の理由
- B: Parameter Store は値の保管のみで段階適用や検証はありません。
- C: CodeDeploy はコード本体のデプロイで、機能フラグ運用には重いです。
- A: Secrets Manager は機密情報用で機能フラグ用途に最適化されていません。