MENU
Udemy講師クーポン配布中。詳しくはこちら（AIP問題集追加しました）
  1. ホーム
  2. 無料問題集一覧｜Udemy講師作成
  3. 【無料】AWS DVA-C02練習問題10問｜Udemy講師作成

【無料】AWS DVA-C02練習問題10問｜Udemy講師作成

AWS DVA無料問題集です。正解と解説を確認する際は右側のボタンを押下してください。

問題集の完全版は以下Udemyにて発売しているためお買い求めください。問題集への質問はUdemyのQA機能もしくはUdemyのメッセージにて承ります。Udemyの問題1から10問抜粋しております。

多くの方にご好評いただき、講師評価 4.5/5.0 を獲得できております。ありがとうございます。

特別価格： 通常2,600円 → 1,500円

講師クーポン適用で42%OFF

講師クーポン【全出題範囲を網羅+詳細な解説】AWS DVA-C02日本語実践問題集260問(ディベロッパーアソシエイト)

【全出題範囲を網羅+詳細な解説】AWS DVA-C02日本語実践問題集200問+α(ディベロッパーアソシエイト)

この資格を活かしたキャリア情報

DVA資格の取得後にどんなキャリアが開けるか、詳しくはこちら：
→ DVA合格者の転職市場価値と求人傾向

AWS資格全体のキャリア活用法：
→ AWS資格は転職・キャリアアップでどう活きる？資格別市場価値と実体験

問題文：
ある開発チームは、Amazon ECS on AWS Fargate で稼働する API を AWS CloudFormation で管理しています。チームは、新しいバージョンを利用者に公開する前に、社内の QA チームだけが専用のテスト用エンドポイント経由で新バージョンを検証できる状態を作り、検証が完了してから本番トラフィックを段階的に移行したいと考えています。移行中に Amazon CloudWatch アラームが発報した場合は、旧バージョンへ自動的に切り戻す必要があります。
この要件を満たすために、CloudFormation でどのように構成すべきですか？

選択肢：
A. テンプレートに AWS::CodeDeployBlueGreen 変換を宣言し、Hooks セクションのフックで本番リスナーとテストリスナーを段階的に切り替えます。

B. テンプレートの ECS サービスに UpdatePolicy 属性を追加し、AutoScalingRollingUpdate でテスト用のバッチサイズと一時停止時間を指定します。

C. テンプレートの ECS サービスのデプロイ設定を変更し、minimumHealthyPercent と maximumPercent で段階的な入れ替え幅を指定します。

D. テンプレートをデプロイするパイプラインに手動承認アクションを追加し、テストの完了を承認してからスタックの更新を実行します。

正解：A

A. テンプレートに AWS::CodeDeployBlueGreen 変換を宣言し、Hooks セクションのフックで本番リスナーとテストリスナーを段階的に切り替えます。

正解 テンプレートのTransformセクションにAWS::CodeDeployBlueGreen変換を宣言し、HooksセクションでAWS::CodeDeploy::BlueGreenフックを定義すると、スタック更新がそのままBlue/Greenデプロイとして実行されます。変換とフックはセットで記述する点に注意してください。フックには対象のECSサービス、本番リスナーとテストリスナー、2つのターゲットグループ、トラフィック移行方式を書きます。スタックを更新するとCodeDeployが新しいタスクセットを起動し、テストリスナー宛てのリクエストだけがそちらへ向かうため、利用者に公開する前にQAチームだけで検証できます。検証後は本番リスナーの割合をカナリアまたは線形で移していきます。自動の切り戻しは、スタック更新時のRollbackConfigurationにCloudWatchアラームをロールバックトリガーとして登録することで構成します（テンプレート本体ではなくスタック側の設定です）。

B. テンプレートの ECS サービスに UpdatePolicy 属性を追加し、AutoScalingRollingUpdate でテスト用のバッチサイズと一時停止時間を指定します。

不正解 UpdatePolicy属性を指定できるリソースは決まっており、AutoScalingRollingUpdateはAWS::AutoScaling::AutoScalingGroupの更新方法を制御するためのものです。AWS::ECS::Serviceはこの属性をサポートしていないため、ECSサービスの更新方法を制御する手段になりません。仮にAuto Scalingグループ側に指定したとしても、決められるのはインスタンスの入れ替え順序と一度に置き換える台数だけで、リクエストの宛先を検証用と本番用に分けることはできません。この属性が有効なのは、Auto Scalingグループ配下のインスタンスを無停止で入れ替えたい場合です。

C. テンプレートの ECS サービスのデプロイ設定を変更し、minimumHealthyPercent と maximumPercent で段階的な入れ替え幅を指定します。

不正解 この2つのパラメータはローリングアップデート専用の設定で、入れ替え中に維持する実行タスク数の下限と上限を決めます。設定自体は正しく適用されますが、入れ替え中は新旧のタスクが同じターゲットグループに登録され、ロードバランサーはリクエストをどちらへ振るかを区別しないため、特定のグループだけに新バージョンを見せることができません。この設定が適切なのは、切り替え中の可用性とタスク数の増減幅を調整したい場合です。

D. テンプレートをデプロイするパイプラインに手動承認アクションを追加し、テストの完了を承認してからスタックの更新を実行します。

不正解 手動承認アクションが制御できるのはスタックを更新するタイミングだけで、更新が始まれば全利用者のリクエストが一度に新バージョンへ向かい、段階的な移行にはなりません。承認前の段階では新バージョンが起動していないため、そもそも検証する対象が存在しません。アラームを条件とした切り戻しも働かず、問題が起きれば人が気付いてから手作業で戻すことになります。人による確認を挟みたい場合も、BeforeAllowTrafficライフサイクルイベントフックにLambda関数を割り当て、検証結果を返すまで移行を保留させる方法があります。

全体的な説明

問われている要件

  • CloudFormationで管理するECS on Fargateサービスへの新バージョン適用
  • 一般公開前にQAチームだけが専用エンドポイントで検証できる仕組み
  • 検証後に本番トラフィックを段階的に移行するリリース戦略
  • CloudWatchアラーム発報時に自動で切り戻す仕組み

前提知識

Blue/Greenデプロイとは

Blue/Greenデプロイは、現在稼働中の環境（Blue環境）と並行して新しい環境（Green環境）を構築し、検証完了後にトラフィックを切り替えるデプロイ手法です。トラフィックを段階的に移行することで、リスクを抑えながらリリースできます。

AWS CodeDeploy for ECS

CodeDeployはECSサービスのBlue/Greenデプロイをサポートしており、以下の機能を提供します：

  • 自動的な新しいタスクセットの作成
  • 本番リスナーとテストリスナーによる経路の分離
  • 移行速度やテスト期間を指定できるデプロイ設定
  • CloudFormationから実行する場合、切り戻しはスタックのロールバックとして行われる

CloudFormationのTransformセクションとHooksセクション

Transformセクションはテンプレートの前処理を行うマクロを指定する場所で、Blue/GreenデプロイではここにAWS::CodeDeployBlueGreen変換を宣言します。

  • HooksセクションではAWS::CodeDeploy::BlueGreenフックを定義し、対象のECSサービス、本番リスナーとテストリスナー、ターゲットグループ、トラフィック移行方式を指定します
  • 変換とフックはセットで記述する必要があり、片方だけではBlue/Greenデプロイになりません
  • スタック更新をトリガーにCodeDeployが呼び出され、タスクセットの作成からトラフィック移行までが自動化されます
  • アラームを条件とした自動の切り戻しは、フックではなくスタックのRollbackConfigurationにロールバックトリガーを登録して実現します

リソースごとの更新制御の違い

UpdatePolicy属性はAuto Scalingグループ、Lambdaエイリアス、ElastiCacheレプリケーショングループなど対応するリソースにのみ指定でき、ECSサービスのローリングアップデートはタスク数の下限と上限で調整しますが、いずれも経路の分離は行いません。

図による解説

アーキテクチャ図

アーキテクチャ図の解説

この図は、AWS CodeDeploy を使用した ECS on Fargate アプリケーションの Blue/Green デプロイの流れを表しています。

CloudFormation テンプレートに AWS::CodeDeployBlueGreen 変換と AWS::CodeDeploy::BlueGreen フックを記述することで、新しいタスクセット（Green 環境）が作成され、Application Load Balancer のテストリスナーが Green 環境だけを指すようになります。

QA チームがテストリスナー経由で検証を終えると、本番リスナーのトラフィックが段階的に Green 環境へ移行します。移行中に CloudWatch アラームが発報した場合は、スタックに登録したロールバックトリガーが働き、本番リスナーの向き先が Blue 環境へ戻されます。

解くための考え方

判断の軸は、検証用の経路を本番の経路から分離できるか、移行の比率を制御できるかの2点です。タスクの入れ替え幅を決めるだけの設定や、更新のタイミングを人が承認するだけの仕組みでは、どちらも満たせません。変換とフックを記述すれば、タスクセットの作成、テストリスナーによる経路の分離、本番リスナーでの段階的移行が自動化されます。

なお2025年7月からはAmazon ECS自体にも組み込みのBlue/Greenデプロイ機能が追加されましたが、本問のようにCodeDeployとCloudFormationによる構成を問われた場合は、変換とフックの組み合わせが解答になります。

参考資料

目次

スポンサーリンク

以下スポンサーリンクです。

この記事がお役に立ちましたら、コーヒー1杯分（300円）の応援をいただけると嬉しいです。いただいた支援は、より良い記事作成のための時間確保や情報収集に活用させていただきます。

目次