DOP構成管理と Infrastructure as Code (IaC)
大企業のプラットフォームチームは、VPC・セキュリティグループ・IAMロールを含む標準的なアプリケーション基盤テンプレートを複数の開発チームが再利用できるようにしたいと考えています。各チームはパラメータをカスタマイズでき、共通コンポーネントをバージョン管理した上で他のCloudFormationテンプレートからネイティブリソースタイプとして参照できることが要件です。最も適切なアプローチはどれですか?
ACloudFormation StackSetsを使用して、すべての開発チームのアカウントに同一のスタックを一括展開する
StackSetsは同一のスタック構成を複数アカウント・リージョンに一括展開する機能であり、各チームが独自パラメータでカスタマイズしたり、他のCloudFormationテンプレートからネイティブリソースタイプとして直接参照したりする要件を満たしません。
BCloudFormationネストされたスタックを使用し、共通コンポーネントをS3の子テンプレートとして管理し、マスタースタックからパラメータを渡す
ネストされたスタックはデプロイ時にスタック間の依存関係が生じます。子テンプレートへの参照はS3 URLの形式となり、ネイティブリソースタイプとして参照できるModulesとは異なります。
CCloudFormation Modulesを使用し、共通コンポーネントをプライベートレジストリにバージョン管理して登録し、各チームのテンプレートからモジュールタイプとして参照する
✓ 正解
CloudFormation Modulesはテンプレートフラグメントをプライベートレジストリにバージョン管理して登録し、他テンプレートからネイティブリソースタイプとして参照できる機能です。テンプレートのコンパイル時にインライン展開されるため依存スタックが不要であり、再利用性とバージョン管理に優れています。
DAWS Service Catalogにポートフォリオとプロダクトを作成し、各チームにプロダクトのローンチ権限を付与してセルフサービス化する
Service Catalogは承認済みプロダクトをセルフサービス形式で展開する仕組みですが、CloudFormationテンプレート内でネイティブリソースタイプとして参照する機能はなく、本要件には適していません。
解説
CloudFormation Modulesはテンプレートフラグメントをプライベートレジストリにバージョン管理して登録し、他テンプレートからネイティブリソースタイプとして参照できる機能です。テンプレートのコンパイル時にインライン展開されるため依存スタックが不要であり、再利用性とバージョン管理に優れています。
選択肢AはStackSetsは同一のスタック構成を複数アカウント・リージョンに一括展開する機能であり、各チームが独自パラメータでカスタマイズしたり、他のCloudFormationテンプレートからネイティブリソースタイプとして直接参照したりする要件を満たしません。
選択肢Bのネストされたスタックはデプロイ時にスタック間の依存関係が生じます。子テンプレートへの参照はS3 URLの形式となり、ネイティブリソースタイプとして参照できるModulesとは異なります。
選択肢DのService Catalogは承認済みプロダクトをセルフサービス形式で展開する仕組みですが、CloudFormationテンプレート内でネイティブリソースタイプとして参照する機能はなく、本要件には適していません。
ドメイン別正答率・予想スコアでリアルタイムに実力把握
無限ノックでDOPを徹底対策。全問AI生成のオリジナル問題。
無料で演習を始める →