DOP構成管理と Infrastructure as Code (IaC)
AWS CDKを使用して本番環境と開発環境に同じインフラを展開しています。
本番環境ではDeletionPolicyをRetainに、開発環境ではDestroyに設定したい。
また、本番環境のみ詳細なCloudWatchメトリクスを有効化したい。
CDKでこれを実現する最もクリーンな方法はどれですか？
A環境ごとに本番用・開発用のCDKスタッククラスを別々に作成し、それぞれのクラスのコンストラクト内に環境固有の設定を直接記述する
環境ごとに別クラスを作成すると重複コードが増え、DeletionPolicy・metricsなどの変更箇所が分散します。DRY原則に違反し保守性が低下します。
BCDKのContext機能を使用して環境識別子を外部から渡し、スタック内でcontext.tryGetContext()を呼び出して環境ごとに条件分岐する
Contextは文字列型で型チェックが効かず、IDEの自動補完も得られません。Propsのような型安全性がなく、保守性・可読性がPropsより劣ります。
CisProdのようなブール型パラメータをスタックのPropsとして定義し、CDKアプリのエントリーポイントで環境ごとに異なるPropsでスタックをインスタンス化する
✓ 正解
isProdなどのブール値をStackPropsに追加し、bin/app.tsでスタックをインスタンス化する際に環境を指定するのがCDKのベストプラクティスです。型安全で補完が有効です。
DAWS Systems Managerパラメータストアに環境ごとの設定値を格納し、CDKのシンセシス実行時にSSMから動的に読み込んで適用する
synthesis時のSSM読み込みはシンセシス（テンプレート生成）が外部依存になり、オフライン動作できなくなります。CDKの理想であるネットワーク不要な設計に反しています。
解説
CDKでは型安全なPropsインターフェースを通じて環境差異を表現するのがベストプラクティスです。isProdフラグをStackPropsに追加し、bin/app.tsで new MyStack(app, 'Prod', { isProd: true }) と new MyStack(app, 'Dev', { isProd: false }) のように分岐することで、DeletionPolicy（removalPolicy）や詳細メトリクス（detailedMonitoring）を環境ごとに制御できます。
選択肢AはCDKスタッククラスを環境ごとに分けると重複コードが増え、変更箇所が分散して保守性が低下します。
選択肢BのContext値は文字列型で型チェックが効かず、IDEの補完も得られないためPropsより保守性・可読性が劣ります。
選択肢DのSSMからのシンセシス時読み込みはアンチパターンであり、シンセシスはネットワーク不要でオフライン動作できるのが理想です。
ドメイン別正答率・予想スコアでリアルタイムに実力把握
無限ノックでDOPを徹底対策。全問AI生成のオリジナル問題。
無料で演習を始める →