【DVA-C02】WEB問題集：デプロイ編

WEB問題集

DVA-C02#1(deployment)

開発者は SAM テンプレートで Lambda、API Gateway、DynamoDB を一括デプロイしています。本番環境のデプロイ前にステージング環境で 5% のトラフィックを新バージョンに送り、エラーが出なければ自動的に 100% にしたいです。最も適切な設定はどれですか。

A. API Gateway の Stage Variable で 5% のリクエストを新 Lambda バージョンへルーティングするスクリプトを書きます。
B. Lambda の Provisioned Concurrency を 5% 増やし、CloudWatch Synthetics で監視します。
C. SAM の AutoPublishAlias と DeploymentPreference を Canary10Percent5Minutes と Alarms 付きで定義します。
D. CodePipeline で Manual Approval を間に挟み、本番への昇格を運用者が判断します。

正解と解説ディスカッション 0

正解：C

正解の根拠

SAM の AutoPublishAlias と DeploymentPreference を組み合わせると、CodeDeploy 経由で Canary や Linear デプロイが宣言的に行えます。Alarms を指定すれば失敗時の自動ロールバックも提供されます。

Lambda デプロイ戦略

戦略	挙動
Canary10Percent5Minutes	10% を 5 分後 100%
Linear10PercentEvery1Minute	1 分ごと 10%
AllAtOnce	即時 100%

コード例

MyFn:
  Type: AWS::Serverless::Function
  Properties:
    AutoPublishAlias: live
    DeploymentPreference:
      Type: Canary10Percent5Minutes
      Alarms: [!Ref ErrorAlarm]

不正解の理由

D: 手動承認は要件 (自動昇格) と合いません。
A: Stage Variable では割合制御できません。
B: Provisioned Concurrency はパフォーマンス用途で、トラフィック分割機構ではありません。

参考：SAM Safe Deploy

DVA-C02#2(deployment)

CodePipeline で構築した CI/CD パイプラインで、CodeBuild ステップから ECR にイメージを push し、その image tag を後続の CodeDeploy ECS Blue/Green デプロイに渡したいです。最も推奨される実装はどれですか。

A. CodeBuild の buildspec で imagedefinitions.json を artifacts に出力し、Deploy ステージで参照します。
B. CodeBuild の environment variables で IMAGE_TAG を Output Artifacts に書き、Lambda Function で Pipeline を Update します。
C. CodeBuild が直接 ECS UpdateService を呼び出し、CodePipeline には完了通知のみ返します。
D. CodeBuild が S3 にバージョンファイルを Put し、CodeDeploy が同期的に Get します。

正解と解説ディスカッション 0

正解：A

正解の根拠

CodeDeploy ECS Blue/Green デプロイには appspec.yaml と imagedefinitions.json (もしくは imageDetail.json) のアーティファクトを介してイメージ参照を渡す方式が標準で、複数イメージにも対応します。

必要なアーティファクト

ファイル	用途
imageDetail.json	ECR イメージ URI
appspec.yaml	タスク定義と Hook
taskdef.json	ECS タスク定義

コード例

artifacts:
  files:
    - imageDetail.json
    - appspec.yaml
    - taskdef.json

不正解の理由

B: Pipeline Update をその都度行うのは複雑かつ循環的です。
D: S3 経由はタイミング保証が弱く、標準フローから外れます。
C: CodeBuild が直接デプロイすると CodePipeline のステージ可視性が失われます。

参考：CodePipeline Files

DVA-C02#3(deployment)

CDK で複数環境 (dev/stg/prod) にデプロイする際、環境ごとに RDS インスタンスサイズや Lambda メモリ等の設定を切り替えたいです。最も推奨される CDK の方法はどれですか。

A. CloudFormation Parameters を使い、cdk deploy 時に --parameters で値を渡します。
B. CodeBuild 環境変数を 3 つの Pipeline で別々に設定し、Stack をビルドします。
C. cdk.json の context にマップで設定を定義し、Stack 内で Stage 名から context.tryGetContext で取得します。
D. 環境ごとに app.py を 3 つ作成し、それぞれで定数を上書きしてビルドします。

正解と解説ディスカッション 0

正解：C

正解の根拠

CDK の cdk.json コンテキスト機能を使えば、環境ごとに設定値を一元管理でき、Stack コードから動的に取得できます。Synth 時に確定するため再現性も担保されます。

CDK 設定管理パターン

方式	長所	短所
cdk.json context	シンプル・再現性	機密値は別管理
CFN Parameters	デプロイ時注入	CDK の利点を損なう
環境変数	柔軟	追跡しにくい

コード例

// cdk.json
"context": {"dev": {"memory": 256}, "prod": {"memory": 1024}}
// Stack
const cfg = this.node.tryGetContext(stage);
new Function(this, "F", {memorySize: cfg.memory});

不正解の理由

D: app.py 重複は DRY 違反で保守性が悪いです。
A: Parameters は CDK のベストプラクティスで非推奨とされています。
B: Pipeline 単位の環境変数は値の追跡性が低くなります。

参考：CDK Context

DVA-C02#4(deployment)

Elastic Beanstalk で Node.js アプリを実行しています。デプロイ時のダウンタイムを 0 にし、失敗時に旧バージョンへ即時に戻したいです。最適なデプロイポリシーはどれですか。(2 つ選択)

（2つ選択）

A. Immutable: 新 Auto Scaling Group を作成し、検証後に切替えます。
B. Blue/Green (環境スワップ): URL スワップで瞬時切替が可能です。
C. Rolling: バッチ単位で更新し、容量を一時的に下げます。
D. All at once: 同時に全インスタンス更新し、迅速にロールアウトします。
E. Rolling with additional batch: 追加容量を確保しつつバッチ更新します。

正解と解説ディスカッション 0

正解：A, B

正解の根拠

Immutable は新規 ASG をプロビジョニングし、Health Check 通過後に切り替えるためダウンタイムなしかつ即時ロールバックが可能です。Blue/Green (環境スワップ) も別環境を立て、CNAME 切替で同様の特性を実現します。

Beanstalk デプロイポリシー

方式	停止時間	ロールバック
All at once	あり	遅い
Rolling	容量低下	遅い
Rolling+additional	なし	遅い
Immutable	なし	即時
Blue/Green	なし	即時

不正解の理由

D: All at once はダウンタイムを伴います。
C: Rolling は処理中容量が低下します。
E: Rolling with additional batch はダウンタイムなしですが、ロールバックは遅いです。

参考：Beanstalk Deploy

DVA-C02#5(deployment)

CloudFormation で 30 を超えるリソースを管理しており、Lambda 関数群と RDS、ネットワーク層の更新頻度が大きく異なるため、独立に変更管理したいです。最も適切な構造化はどれですか。

A. StackSets でアカウント横断展開し、各リソースを別 Stack に分けます。
B. 関心領域別に独立 Stack に分割し、Cross-Stack Reference (Outputs/Imports) または SSM Parameter Store でリソース ARN を共有します。
C. Nested Stacks で論理的に分割し、ルートテンプレートからネスト参照します。
D. 単一スタックを維持し、Change Set で関心領域以外の変更を Skip します。

正解と解説ディスカッション 0

正解：B

正解の根拠

更新頻度や責務が異なるリソース群は独立 Stack に分割して変更影響範囲を限定するのが推奨です。Cross-Stack Reference や SSM Parameter Store を介した疎結合の参照で値を共有します。

スタック分割パターン

方式	用途
独立 Stack + Export/Import	更新サイクル分離
Nested Stack	ライフサイクル共通の分割
StackSet	マルチアカウント展開

コード例

NetworkStack:
  Outputs: {VpcId: {Export: {Name: VpcId}}}
AppStack: {VpcId: !ImportValue VpcId}

不正解の理由

D: 単一巨大スタックは更新リスクが高く、Change Set で個別 Skip は実務的でないです。
C: Nested Stack はライフサイクルを共有するため独立更新には不向きです。
A: StackSets は複数アカウント展開用で、責務分割の解ではありません。

参考：Cross-Stack