AWS認定資格 WEB問題集&徹底解説
デベロッパー–アソシエイト
問題文と選択肢
解析基盤を自前で構築・運用することは避け、Pull Request が作成されるたびに自動でレビューが走り、指摘がコード上のコメントとして残る仕組みにしたいとしています。
運用負荷を最小限に抑えてこの要件を満たす、最も適切なアプローチはどれですか?
- Amazon CodeGuru ProfilerをCIパイプラインに組み込み、Pull Requestごとにプロファイリングレポートを生成する
- AWS CodeBuildのテストが失敗したときにのみ、Amazon CodeGuru Reviewerを手動で実行する
- リポジトリをAmazon CodeGuru Reviewerに関連付け、Pull Requestをトリガーとして自動レビューを実行する
- Amazon CloudWatch Logs Insightsのクエリを作成し、静的解析の代わりに使用する
A. Amazon CodeGuru ProfilerをCIパイプラインに組み込み、Pull Requestごとにプロファイリングレポートを生成する
Amazon CodeGuru Profiler は、本番稼働中のアプリケーションの CPU・メモリ使用状況を継続的にプロファイリングし、性能上のボトルネックやコスト高な処理を見つけるサービス。
対象は「動いているコードの実行時の振る舞い」であって、ソースコードを読んで欠陥を指摘する静的解析ではない。
PR の段階でプロファイリングレポートを出しても、バグや非効率な実装の検出という要件を満たせない。
B. AWS CodeBuildのテストが失敗したときにのみ、Amazon CodeGuru Reviewerを手動で実行する
Amazon CodeGuru Reviewer 自体は正しい道具だが、実行契機が誤り。「テストが失敗したときにのみ」「手動で」という運用では、テストが通る PR のレビューが漏れ、レビューのたびに人手が要る。
要件は「Pull Request ごとに自動」「運用負荷を最小限に」であり、手動トリガーは真っ先に消える。
サービスの選択が合っていても、トリガー方式が要件と食い違う典型的な誤答パターン。
C. リポジトリをAmazon CodeGuru Reviewerに関連付け、Pull Requestをトリガーとして自動レビューを実行する
リポジトリを Amazon CodeGuru Reviewer に関連付け(repository association)ておけば、以後は Pull Request の作成をトリガーとして自動でコードレビューが実行され、指摘が PR 上のコメントとして残る。
解析基盤の構築・スケーリング・ルールのメンテナンスは不要で、運用負荷が最も小さい。
検出対象も並行処理の不具合・リソースリーク・AWS SDK の非効率な使い方など、まさに「バグや非効率な実装」であり、要件をすべて満たす唯一の選択肢。
D. Amazon CloudWatch Logs Insightsのクエリを作成し、静的解析の代わりに使用する
Amazon CloudWatch Logs Insights は、収集済みのログをクエリして分析するためのサービス。分析対象はソースコードではなく実行時に出力されたログである。
そもそも Pull Request の時点ではアプリケーションが動いておらずログが存在しないため、静的解析の代替にはなり得ない。
クエリを自作して運用する分、要件の「運用負荷最小」にも反する。
CodeGuru は Reviewer=静的解析(コード)、Profiler=実行時性能(ランタイム)。PR に自動コメントは Reviewer。
正解への思考ルート
問題文から要件を抽出し、選択肢の適否を判断するのがポイントです。| 要件 | 判断ポイント |
|---|---|
| 静的解析でコードのバグ・非効率な実装を検出したい | 静的解析はCodeGuru Reviewer。CodeGuru Profiler は実行時のプロファイリングで守備範囲が違う →選択肢(A)を消す |
| 解析対象は「まだ動いていないコード」(PR 段階) | CloudWatch Logs Insights は実行後のログを分析するもの。PR 段階ではログ自体が存在しない →選択肢(D)を消す |
| Pull Request が作成されるたびに自動でレビューを実行 | リポジトリを関連付ける(repository association)だけで PR をトリガーに自動レビューが走る →選択肢(B・C)は候補、選択肢(C)が正解 |
| 運用負荷を最小限に抑えたい | 「手動実行」「失敗時のみ」は自動化の要件に反する。レビュー漏れも発生する →選択肢(B)を消す |
| 指摘をコード上のコメントとして残したい | CodeGuru Reviewer はPR に推奨事項をコメントとして書き込む →選択肢(C)が正解 |
ひっかけポイント
- CodeGuru Reviewer と CodeGuru Profiler の取り違えが最大の罠。「Reviewer=コードを読む(静的解析)」「Profiler=動いているコードを測る(実行時性能)」で覚える
- 選択肢 B はサービス名は正しいため選びたくなるが、「テスト失敗時のみ・手動」というトリガーが要件(PR ごとに自動)と食い違う。サービスが合っていても運用形態で落とす問題
- 「CloudWatch Logs Insights で静的解析を代替」は、ログ分析とコード解析を混同させる誤答。PR の時点では実行ログが存在しない点に気付けば即消せる
- 実運用上の注意として、CodeGuru Reviewer は 2025年11月7日以降、新規のリポジトリ関連付けができない(既存の関連付けのみ利用可)。同等の PR 自動レビューは Amazon Q Developer のコードレビューが後継となる。試験の出題範囲としては引き続き CodeGuru Reviewer の役割で問われる
出題バリエーション
同じ知識が本番では条件を変えて出題されます。| 問題文がこう変わったら | 正解はこう変わる |
|---|---|
| 「本番環境で CPU 使用率が高い処理を特定し、コストを下げたい」 | CodeGuru Profiler が正解に入れ替わる。 |
| 「コード内のハードコードされた認証情報やセキュリティ脆弱性を検出したい」 | CodeGuru Reviewer のセキュリティ検出(Security Detector)や Amazon Inspector のコードスキャンが正解軸に。 |
| 「ビルド・テスト・デプロイの一連の流れを自動化したい」 | CodePipeline + CodeBuild の CI/CD 構成が正解軸に変わる。 |
| 「IDE 上でコードを書きながら指摘やコード提案を受けたい」 | Amazon Q Developer(旧 CodeWhisperer 系)が正解に。 |
| 「PR にコメントするのではなく、基準を満たさないコードのマージを止めたい」 | CI(CodeBuild)のビルド失敗+ブランチ保護でゲートを設ける設計が問われる。 |
リファレンス
この問題を解くために必要な知識を扱う公式ドキュメントです。| 知識項目 | 公式ドキュメント |
|---|---|
| CodeGuru Reviewer の提供状況の変更と後継サービス(Amazon Q Developer のコードレビュー) | Amazon CodeGuru Reviewer availability change |
解析基盤を自前で構築・運用することは避け、Pull Request が作成されるたびに自動でレビューが走り、指摘がコード上のコメントとして残る仕組みにしたいとしています。
運用負荷を最小限に抑えてこの要件を満たす、最も適切なアプローチはどれですか?
- Amazon CodeGuru ProfilerをCIパイプラインに組み込み、Pull Requestごとにプロファイリングレポートを生成する
- AWS CodeBuildのテストが失敗したときにのみ、Amazon CodeGuru Reviewerを手動で実行する
- リポジトリをAmazon CodeGuru Reviewerに関連付け、Pull Requestをトリガーとして自動レビューを実行する
- Amazon CloudWatch Logs Insightsのクエリを作成し、静的解析の代わりに使用する