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

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

正解 B,D,E問題
分野1：SDLC の自動化 タスクステートメント1.2：CI/CD パイプラインへの自動テストの統合 タスクステートメント1.1：CI/CD パイプラインの実装
要復習（もう一度解きたい問題） 1 2 3 4
前の問題
合格に向けて、もっと深く学習する
豊富な問題と詳細なAWSサービス解説を、24時間無料でお試しいただけます
プレミアム会員機能を無料で試す ❯
問題文と選択肢
モバイルゲームの課金基盤を開発するチームは、ソースコードを GitHub のリポジトリで管理しています。これまで main ブランチへの取り込み手順が定まっておらず、動作確認が済んでいないコードがそのままマージされて本番障害につながったことがありました。

そこでチームは、プルリクエストが開かれた時点と内容が更新された時点で AWS CodeBuild による自動テストが人手を介さずに走り出し、あわせてプルリクエストの内容を Amazon Q Developer が自動でレビューして指摘をコメントで返すようにしたいと考えています。さらに、自動テストの結果が問題なしとなるまで main へのマージを受け付けず、それに加えてリポジトリの責任者 (コードオーナー) が内容を確認して承認するまではマージできない状態にすることを求めています。

GitHub リポジトリと AWS アカウントの接続はすでに完了しています。この運用を実現するために必要な設定はどれですか。（3 つ選択）
  • AWS CodePipeline を用意し、ソースに GitHub を、続くステージに AWS CodeBuild を配置したうえで、その後段に手動承認アクションを追加し、責任者が AWS マネジメントコンソールで承認するまで処理が進まないようにする。
  • AWS CodeBuild のビルドプロジェクトでソースプロバイダーに対象の GitHub リポジトリを指定し、プルリクエストの作成時と更新時に発火するウェブフックイベントを有効にしたうえで、ビルドの成否をコミットステータスとして GitHub へ報告させる。
  • GitHub から届くプルリクエストのイベントを Amazon EventBridge で受け、AWS Lambda から AWS CodeBuild を起動して、その結果に応じて GitHub の API 経由でマージの可否を書き換える処理を自作する。
  • GitHub Marketplace から Amazon Q Developer の GitHub アプリを対象リポジトリにインストールし、Amazon Q Developer コンソールに登録する。プルリクエストが作成されると Amazon Q のコードレビューエージェントが内容を自動的に解析し、指摘をコメントとして投稿する。
  • GitHub 側で main ブランチにブランチ保護ルールを設定し、マージ前のステータスチェックの合格を必須にしたうえで、コードオーナーによるレビュー承認も必須にする。
  • 毎晩定刻に AWS CodeBuild プロジェクトを実行するスケジュールを組み、その時点で未マージのブランチをまとめてテストして、失敗したブランチの一覧を開発チームへ通知する。
解説 頻出度★★★★★
この問題は、「プルリクエスト起点の自動テスト × AI による自動レビュー × マージのゲート」を、CodeBuild のウェブフック＋コミットステータス、Amazon Q Developer の GitHub アプリ、GitHub のブランチ保護ルールという三点セットで組み立てられるかがポイント

A. AWS CodePipeline を用意し、ソースに GitHub を、続くステージに AWS CodeBuild を配置したうえで、その後段に手動承認アクションを追加し、責任者が AWS マネジメントコンソールで承認するまで処理が進まないようにする。

AWS CodePipeline はマージ後（ブランチへのプッシュ後）に動くデプロイのためのパイプラインであり、プルリクエスト単位で走らせてマージ自体を止める仕組みではない。
手動承認アクションはパイプラインの進行を止めるだけで、GitHub 側のマージボタンには何の制約もかからない。
「動作確認が済んでいないコードがマージされる」という今回の課題そのものを解決できない。

正解

B. AWS CodeBuild のビルドプロジェクトでソースプロバイダーに対象の GitHub リポジトリを指定し、プルリクエストの作成時と更新時に発火するウェブフックイベントを有効にしたうえで、ビルドの成否をコミットステータスとして GitHub へ報告させる。

CodeBuild のビルドプロジェクトでソースプロバイダーに GitHub を指定すると、プルリクエストの作成時・更新時（PULL_REQUEST_CREATED / PULL_REQUEST_UPDATED）に発火するウェブフックを設定でき、人手を介さずテストが起動する。
さらに「ビルドステータスを報告する」を有効にすると、ビルドの成否がコミットステータスとして GitHub に返るため、後述のブランチ保護ルールで必須のステータスチェックとして扱える。
自動テストとマージゲートを結び付ける要となる設定であり、正解。

C. GitHub から届くプルリクエストのイベントを Amazon EventBridge で受け、AWS Lambda から AWS CodeBuild を起動して、その結果に応じて GitHub の API 経由でマージの可否を書き換える処理を自作する。

EventBridge と Lambda で同等のことを実装するのは技術的には可能だが、CodeBuild のウェブフック機能で標準提供されている処理を自作することになる。
GitHub API を叩いてマージ可否を書き換える処理まで抱え込むため、コードの保守・トークン管理・エラー処理という運用負荷が増える。
設問が求めているのは「この運用を実現するために必要な設定」であり、車輪の再発明である本選択肢は不要。

正解

D. GitHub Marketplace から Amazon Q Developer の GitHub アプリを対象リポジトリにインストールし、Amazon Q Developer コンソールに登録する。プルリクエストが作成されると Amazon Q のコードレビューエージェントが内容を自動的に解析し、指摘をコメントとして投稿する。

Amazon Q Developer for GitHub は、GitHub Marketplace からアプリをインストールして対象リポジトリへのアクセスを許可することで使えるようになる（Amazon Q Developer コンソールへの登録は、無料利用枠の上限を引き上げるための手順）。
導入するとコードレビューエージェントが新規に作成されたプルリクエストを自動的に解析し、品質やセキュリティの指摘をコメントとして投稿する（プルリクエスト内で /q review と書けば任意のタイミングでも実行できる）。
「AI レビューを人手を介さずに走らせる」という要件を満たす唯一の選択肢であり、正解。

正解

E. GitHub 側で main ブランチにブランチ保護ルールを設定し、マージ前のステータスチェックの合格を必須にしたうえで、コードオーナーによるレビュー承認も必須にする。

GitHub のブランチ保護ルールこそが、main へのマージを実際に止める仕組み。
「マージ前に必須のステータスチェック」に CodeBuild が返すコミットステータスを指定すれば、テストが通るまでマージできない状態になる。
さらに CODEOWNERS と「コードオーナーによるレビューを必須にする」を組み合わせれば、リポジトリの責任者の承認なしにはマージできないという残りの要件も満たせる。AWS 側だけでは実現できない部分を担う、正解。

F. 毎晩定刻に AWS CodeBuild プロジェクトを実行するスケジュールを組み、その時点で未マージのブランチをまとめてテストして、失敗したブランチの一覧を開発チームへ通知する。

毎晩まとめてテストする方式では、プルリクエストの作成・更新に即応できず、失敗が判明するのは最大で丸一日後になる。
結果は通知されるだけでマージを止める強制力が無いため、「動作確認が済んでいないコードがマージされる」という課題は残ったままになる。
夜間の一括テストは補完的な仕組みにはなり得るが、本問のマージゲートの要件は満たさない。

構成図

GitHub プルリクエスト（作成 / 更新）
   │ ウェブフック                     │ アプリ連携
   ▼                                  ▼
AWS CodeBuild（自動テスト）      Amazon Q Developer（コードレビュー）
   │ コミットステータスで報告          │ 指摘をコメント投稿
   ▼                                  ▼
main のブランチ保護ルール（ステータスチェック合格 ＋ コードオーナー承認）
   ▼
main へマージ
これだけ覚える（記憶フック）
テストは CodeBuild のウェブフック、ゲートは GitHub のブランチ保護。マージを止めるのは AWS 側ではない。
正解への思考ルート 問題文から要件を抽出し、選択肢の適否を判断するのがポイントです。
要件 判断ポイント
プルリクエストの作成時・更新時に自動テストを走らせる CodeBuild はウェブフックのイベントフィルターでプルリクエストの作成 / 更新を拾える。夜間バッチでは即応できない
→選択肢（F）を消す・選択肢（B）が正解
テスト結果でマージをブロックする マージを止めるのは GitHub のブランチ保護ルール。CodeBuild が返すコミットステータスを必須チェックに指定する
→選択肢（B・E）が正解
責任者が確認・承認するまでマージさせない CODEOWNERS ＋ コードオーナーのレビュー必須で実現する。CodePipeline の手動承認はマージを止めない
→選択肢（A）を消す・選択肢（E）が正解
AI によるコードレビューを自動で実施する Amazon Q Developer の GitHub アプリを入れると、プルリクエストを自動解析して指摘をコメント投稿する
→選択肢（D）が正解
「必要な設定はどれか」（判断軸） マネージド機能で足りる処理をLambda で自作する案は、必要な設定ではなく余計な作り込み
→選択肢（C）を消す
ひっかけポイント
  • 選択肢 A の手動承認アクションは CodePipeline の進行を止めるだけ。GitHub の「マージ」ボタンには一切影響しないので、承認ゲートの要件を満たさない
  • マージを止めるのは AWS 側ではなく GitHub 側の設定。CodeBuild が返せるのは合否のステータスまでで、必須チェックに指定するのはブランチ保護ルールの役目
  • 選択肢 C はやろうと思えばできるため惑わされるが、CodeBuild のウェブフック（＋ビルドステータス報告）で標準提供されている機能を自作しているだけ
  • 選択肢 F の夜間一括テストは通知するだけで強制力が無い。「テストは動いている」ように見えて、未検証コードのマージは防げない
  • Amazon Q Developer の自動レビューはプルリクエストの新規作成（およびクローズ済み PR の再オープン）で発火する。既存プルリクエストへの追加コミットで再実行したい場合は /q review を使う
出題バリエーション 同じ知識が本番では条件を変えて出題されます。
問題文がこう変わったら 正解はこう変わる
「ソースが GitHub ではなく Bitbucket / GitLab になった」 CodeBuild のウェブフックとコミットステータス報告は同様に使えるが、マージゲートは各サービス側のブランチ制限で設定する。
「テストに加えてマージ後に本番デプロイまで自動化したい」 main へのマージを起点とする CodePipeline が正解に加わる（選択肢 A の構成が意味を持つ）。
「プルリクエストのたびに検証用の環境を立ち上げてテストしたい」 CodeBuild のウェブフックから AWS CloudFormation / CDK で一時スタックを作る構成が問われる。
「AI レビューではなく静的解析や依存ライブラリの脆弱性検査を必須にしたい」 Amazon Inspector（コードスキャン）や CodeBuild 内の SAST ツールの結果をステータスチェックにする形へ。
「リポジトリが AWS CodeCommit の場合」 ブランチ保護ルールではなく承認ルールテンプレートでマージ前の承認数を強制し、テストの起動は EventBridge → CodeBuild の連携で行う型になる。
関連サービスの解説 AWS CodeBuild
Amazon Q Developer
リファレンス この問題を解くために必要な知識を扱う公式ドキュメントです。
知識項目 公式ドキュメント
Amazon Q Developer for GitHub の導入手順と自動コードレビューの発火条件 Amazon Q Developer for GitHub (プレビュー) - Amazon Q Developer
CodeBuild のプルリクエスト起動（PULL_REQUEST_CREATED / PULL_REQUEST_UPDATED） GitHub ウェブフックイベント - AWS CodeBuild
＋ 質問 / コメント
解答・解説に疑問がある場合や、よりよい解説がある場合など、お気軽にコメントください。ただし、短文コメントは表示されません。また、中傷などコメントの内容によっては、会員機能を停止させて頂きます。教え学び合える場になれば嬉しいです。（コメント投稿にはログインが必要です）
正答率 0%
No.20 解説
モバイルゲームの課金基盤を開発するチームは、ソースコードを GitHub のリポジトリで管理しています。これまで main ブランチへの取り込み手順が定まっておらず、動作確認が済んでいないコードがそのままマージされて本番障害につながったことがありました。

そこでチームは、プルリクエストが開かれた時点と内容が更新された時点で AWS CodeBuild による自動テストが人手を介さずに走り出し、あわせてプルリクエストの内容を Amazon Q Developer が自動でレビューして指摘をコメントで返すようにしたいと考えています。さらに、自動テストの結果が問題なしとなるまで main へのマージを受け付けず、それに加えてリポジトリの責任者 (コードオーナー) が内容を確認して承認するまではマージできない状態にすることを求めています。

GitHub リポジトリと AWS アカウントの接続はすでに完了しています。この運用を実現するために必要な設定はどれですか。（3 つ選択）
  • AWS CodePipeline を用意し、ソースに GitHub を、続くステージに AWS CodeBuild を配置したうえで、その後段に手動承認アクションを追加し、責任者が AWS マネジメントコンソールで承認するまで処理が進まないようにする。
  • AWS CodeBuild のビルドプロジェクトでソースプロバイダーに対象の GitHub リポジトリを指定し、プルリクエストの作成時と更新時に発火するウェブフックイベントを有効にしたうえで、ビルドの成否をコミットステータスとして GitHub へ報告させる。
  • GitHub から届くプルリクエストのイベントを Amazon EventBridge で受け、AWS Lambda から AWS CodeBuild を起動して、その結果に応じて GitHub の API 経由でマージの可否を書き換える処理を自作する。
  • GitHub Marketplace から Amazon Q Developer の GitHub アプリを対象リポジトリにインストールし、Amazon Q Developer コンソールに登録する。プルリクエストが作成されると Amazon Q のコードレビューエージェントが内容を自動的に解析し、指摘をコメントとして投稿する。
  • GitHub 側で main ブランチにブランチ保護ルールを設定し、マージ前のステータスチェックの合格を必須にしたうえで、コードオーナーによるレビュー承認も必須にする。
  • 毎晩定刻に AWS CodeBuild プロジェクトを実行するスケジュールを組み、その時点で未マージのブランチをまとめてテストして、失敗したブランチの一覧を開発チームへ通知する。

前の問題


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

会員機能

お役立ち情報

姉妹サイト

アンケート

サイト情報