AWS認定資格 WEB問題集＆徹底解説

DevOpsエンジニア-プロフェッショナル

正解 C問題
分野1：SDLC の自動化 タスクステートメント1.2：CI/CD パイプラインへの自動テストの統合
要復習（もう一度解きたい問題） 1 2 3 4
次の問題前の問題
合格に向けて、もっと深く学習する
豊富な問題と詳細なAWSサービス解説を、24時間無料でお試しいただけます
プレミアム会員機能を無料で試す ❯
問題文と選択肢
ある旅行予約サイトの運営会社は、キャンペーン用の静的サイトを Amazon S3 に配置し Amazon CloudFront で配信しています。更新は AWS CodePipeline で自動化されており、ソース、ビルド、S3 への同期と CloudFront のキャッシュ無効化、本番ドメインへの切り替えという順にステージが並んでいます。

キャッシュ無効化が終わると、配信 URL の /version.json に対するリクエストは HTTP 200 を返します。開発チームは、この確認をパイプラインの中で自動的に行い、200 以外が返った場合はその時点でパイプラインを失敗させて本番ドメインへの切り替えに進ませないようにしたいと考えています。

運用オーバーヘッドを最小限に抑えつつ、この要件を満たすソリューションはどれですか。
  • キャッシュ無効化のステージの後に、CodePipeline が標準で備える HTTP エンドポイントテストのアクションプロバイダーを追加し、確認先の URL と期待するステータスコード 200 を設定画面で指定する。
  • 配信 URL を 5 分間隔で確認する Amazon CloudWatch Synthetics のカナリアを作成し、実行が失敗したときに Amazon SNS で開発チームへ通知する。
  • キャッシュ無効化のステージの後に確認用のステージを設け、そこに AWS Lambda 呼び出しアクションを配置する。関数は /version.json へリクエストを送ってステータスコードを評価し、CodePipeline から受け取ったジョブ ID を添えて PutJobSuccessResult または PutJobFailureResult を呼び出す。
  • パイプライン実行の状態変更イベントを Amazon EventBridge で受け取り、AWS Lambda 関数が /version.json を確認して、200 以外であれば StopPipelineExecution を呼び出す。
解説 頻出度★★★★★
この問題は、「パイプラインの途中で URL を検証 × 200 以外なら以降のステージへ進ませない」という要件で、Lambda 呼び出しアクションから PutJobSuccessResult / PutJobFailureResult で結果を返すという CodePipeline の定石を選べるかがポイントです。

A. キャッシュ無効化のステージの後に、CodePipeline が標準で備える HTTP エンドポイントテストのアクションプロバイダーを追加し、確認先の URL と期待するステータスコード 200 を設定画面で指定する。

CodePipeline には「確認先の URL と期待するステータスコードを画面で指定するだけ」で動く HTTP エンドポイントテスト用のアクションプロバイダーは存在しません。
テストカテゴリで選べるのは AWS CodeBuild や AWS Device Farm、サードパーティ製ツールなどで、HTTP レスポンスの検証を行いたい場合はCodeBuild のコマンドか Lambda 関数として自分で実装する必要があります。
設定だけで済むという最も運用が楽そうな書き方をした、存在しない機能の選択肢です。

B. 配信 URL を 5 分間隔で確認する Amazon CloudWatch Synthetics のカナリアを作成し、実行が失敗したときに Amazon SNS で開発チームへ通知する。

Amazon CloudWatch Synthetics のカナリアはパイプラインとは独立して 5 分間隔で回る外形監視であり、パイプラインの実行状況と同期していません。
失敗しても行われるのは Amazon SNS による通知だけで、パイプラインを失敗させる（本番ドメインへの切り替えを止める）力はありません。
本番切り替えは先に進んでしまい、「200 以外ならその時点で止める」という要件を満たせません。デプロイ後の継続監視としては有効な仕組みですが、本問の用途は別です。

正解

C. キャッシュ無効化のステージの後に確認用のステージを設け、そこに AWS Lambda 呼び出しアクションを配置する。関数は /version.json へリクエストを送ってステータスコードを評価し、CodePipeline から受け取ったジョブ ID を添えて PutJobSuccessResult または PutJobFailureResult を呼び出す。

正解です。CodePipeline のLambda 呼び出しアクションを確認用ステージに置くと、関数はイベントの CodePipeline.job.id でジョブ ID を受け取り、処理結果を PutJobSuccessResult / PutJobFailureResult で返します。
AWS 公式ドキュメントにも、デプロイした Web ページへリクエストを送り、ステータスコードや本文を検証して失敗時に PutJobFailureResult を呼ぶ例がそのまま掲載されています。
失敗を返した時点でそのアクションが失敗しパイプラインは停止するため、後続の本番ドメイン切り替えステージには進みません。管理するのは小さな関数 1 つだけで、運用オーバーヘッドも最小です（結果を返さないとアクションがタイムアウトするまで待たされる点に注意）。

D. パイプライン実行の状態変更イベントを Amazon EventBridge で受け取り、AWS Lambda 関数が /version.json を確認して、200 以外であれば StopPipelineExecution を呼び出す。

EventBridge でパイプラインの状態変更イベントを受けて StopPipelineExecution を呼ぶ構成は、イベント配信・関数実行の間に後続ステージが開始してしまう競合を避けられず、本番ドメインへの切り替えを確実に止められません。
検証ロジックをパイプラインの外側に置くため、失敗が「ステージの失敗」として履歴に残らず、どこで何が起きたのか追いにくくなります。
ルール・関数・停止 API 呼び出しと部品も増え、運用オーバーヘッドを最小にするという要件から外れます。

これだけ覚える（記憶フック）
パイプラインに独自チェックを挟むなら Lambda 呼び出し＋ジョブ結果 API。通知だけの監視では止められない。
正解への思考ルート 問題文から要件を抽出し、選択肢の適否を判断するのがポイントです。
要件 判断ポイント
パイプラインの中で自動的に /version.json を確認したい パイプラインに任意の処理を差し込む標準手段が Lambda 呼び出しアクション。外側の監視サービスでは代替できない
→選択肢（C）が正解
200 以外ならその時点でパイプラインを失敗させる PutJobFailureResult を返すとアクションが失敗し、後続ステージは実行されない
→選択肢（C）が正解
本番ドメインへの切り替えに進ませない（順序の保証） 検証をステージとして間に挟むことが必須。イベント駆動で後から止める方式は競合が残る
→選択肢（D）を消す
運用オーバーヘッドを最小限に抑える 標準機能に見える提案でも、存在しないアクションプロバイダーは選べない
→選択肢（A）を消す
検証はデプロイのたびに 1 回行えばよい（常時監視ではない） Synthetics カナリアは定期実行の外形監視で通知するだけ。パイプラインの制御には使えない
→選択肢（B）を消す
ひっかけポイント
  • 選択肢 A は「標準で備える」「設定画面で指定するだけ」という最も運用が楽に見える書き方で誘導してくるが、CodePipeline に HTTP エンドポイントテストのアクションプロバイダーは存在しない。存在しない機能を最善手に見せる典型的な罠
  • 選択肢 B の CloudWatch Synthetics は「配信 URL を自動で確認する」点だけ見ると要件に合っているように読めるが、結果が SNS 通知どまりでパイプラインを止められない。「検知」と「制御」の違いを問うている
  • 選択肢 C の肝はジョブ ID を添えて結果を返すこと。これを忘れた Lambda 関数はアクションがタイムアウトするまでパイプラインが待ち続ける（実務でも頻出のミス）
  • 選択肢 D の StopPipelineExecution は実在する API なので否定しづらいが、状態変更イベントを受け取った時点では後続ステージが動き出している可能性があり、「その時点で止める」保証にならない
出題バリエーション 同じ知識が本番では条件を変えて出題されます。
問題文がこう変わったら 正解はこう変わる
「検証をシェルコマンド（curl）で書きたい／既存のテストスクリプトを流用したい」 CodeBuild をテストアクションとして挟む構成が正解軸に。終了コードでパイプラインの成否が決まる。
「本番切り替えの前に人による承認を挟みたい」 手動承認アクション（承認ステージ）が正解軸に。SNS で承認依頼を通知する。
「デプロイ後も継続的に配信 URL を監視して異常を検知したい」 CloudWatch Synthetics カナリア＋CloudWatch アラームが正解軸に（本問の選択肢 B の本来の用途）。
「検証に失敗したら自動的に前のバージョンへ切り戻したい」 CodeDeploy の Blue/Green と自動ロールバック、または切り戻し用のパイプライン／ステージ再実行が論点に。
「複数の検証を並列に実行して全部成功したら次へ進めたい」 同一ステージ内にrunOrder を同じにした複数アクションを並べる設計が論点に変わる。
関連サービスの解説 Amazon CloudFront
AWS CodePipeline
AWS Lambda
リファレンス この問題を解くために必要な知識を扱う公式ドキュメントです。
知識項目 公式ドキュメント
CodePipeline の Lambda 呼び出しアクションとジョブ結果の通知 (PutJobSuccessResult / PutJobFailureResult) CodePipeline のパイプラインで AWS Lambda 関数を呼び出す - AWS CodePipeline
＋ 質問 / コメント
解答・解説に疑問がある場合や、よりよい解説がある場合など、お気軽にコメントください。ただし、短文コメントは表示されません。また、中傷などコメントの内容によっては、会員機能を停止させて頂きます。教え学び合える場になれば嬉しいです。（コメント投稿にはログインが必要です）
正答率 0%
No.15 解説
ある旅行予約サイトの運営会社は、キャンペーン用の静的サイトを Amazon S3 に配置し Amazon CloudFront で配信しています。更新は AWS CodePipeline で自動化されており、ソース、ビルド、S3 への同期と CloudFront のキャッシュ無効化、本番ドメインへの切り替えという順にステージが並んでいます。

キャッシュ無効化が終わると、配信 URL の /version.json に対するリクエストは HTTP 200 を返します。開発チームは、この確認をパイプラインの中で自動的に行い、200 以外が返った場合はその時点でパイプラインを失敗させて本番ドメインへの切り替えに進ませないようにしたいと考えています。

運用オーバーヘッドを最小限に抑えつつ、この要件を満たすソリューションはどれですか。
  • キャッシュ無効化のステージの後に、CodePipeline が標準で備える HTTP エンドポイントテストのアクションプロバイダーを追加し、確認先の URL と期待するステータスコード 200 を設定画面で指定する。
  • 配信 URL を 5 分間隔で確認する Amazon CloudWatch Synthetics のカナリアを作成し、実行が失敗したときに Amazon SNS で開発チームへ通知する。
  • キャッシュ無効化のステージの後に確認用のステージを設け、そこに AWS Lambda 呼び出しアクションを配置する。関数は /version.json へリクエストを送ってステータスコードを評価し、CodePipeline から受け取ったジョブ ID を添えて PutJobSuccessResult または PutJobFailureResult を呼び出す。
  • パイプライン実行の状態変更イベントを Amazon EventBridge で受け取り、AWS Lambda 関数が /version.json を確認して、200 以外であれば StopPipelineExecution を呼び出す。

次の問題前の問題


(会員限定)当問題の評価をお願いします。改善に活用します。
広告

会員機能

お役立ち情報

姉妹サイト

アンケート

サイト情報