模擬問題集一覧

DVA-C02 模擬問題集（練習問題）

AWS Developer – Associate 合格に向けた本番形式の模擬問題集。すべての問題に詳しい解説と、ドメイン別の弱点分析つき。

4 練習テスト 200 問 合格ライン 70% 各 120 分

この模擬問題集で身につくこと

  • 本番と同じ形式・難易度の問題で実力を確認
  • 制限時間つきの試験モードで時間配分を体得
  • 演習モードで1問ずつ解説を読みながら学習
  • すべての問題に正解の根拠つきの詳しい解説
  • ドメイン別スコアで弱点分野をひと目で把握
  • 完了後も何度でも復習して本番前に仕上げ

練習テストの内容

4 テスト · 全 200 問
1
模擬問題集①先頭 15 問 無料
50 問 120 分 合格 70%
2
模擬問題集② プラン限定
50 問 120 分 合格 70%
3
模擬問題集③ プラン限定
50 問 120 分 合格 70%
4
模擬問題集④ プラン限定
50 問 120 分 合格 70%

説明

DVA-C02（AWS Developer – Associate）の合格に向けた、本番形式の模擬問題集です。全 200 問を4 回の練習テストに分割し、 試験モード／演習モードで受験できます。各問題には正解の根拠と誤答の理由を記した詳しい解説が付き、受験後はドメイン別のスコアで弱点を把握できます。 各試験は先頭の問題から無料でお試しいただけます。

月額 ¥980 で全 200 問＋全解説が受け放題

模試プラン（¥980/月）なら、ロックされた練習テストと詳しい解説、ドメイン別の弱点分析がすべて使い放題。本番に向けて実力を仕上げましょう。

DVA-C02 の操作は、実機のハンズオンラボで身につける

問題集で覚えた知識を、本物の Azure・AWS 環境で手を動かして確かめられます。 Pro プランなら DVA-C02 対応のハンズオンラボ 21 本と、この問題集の全 200 問がすべて使えます。 ラボは会員登録だけで 1 本無料で試せます。

DVA-C02 の対応ラボを見る（21 本）ラボを 1 本無料で試す

DVA-C02 の出題範囲（カバーしている分野）

全 200 問を、本番の試験ガイドに沿った次の分野から出題しています。 受験後はドメイン別の正答率が表示され、弱点が特定できます。 難易度・学習時間・合格までの進め方はDVA-C02 の学習ガイドにまとめています。

DVA-C02 の無料練習問題（15 問・解説つき）

会員登録なしで、全 200 問のうち 15 問を正解と解説つきでご覧いただけます。 問題をクリックすると選択肢と解説が開きます。

問題 1最も運用効率の高い方法でこれらの要件を満たすソリューションはどれですか？AWS のサービスを使用した開発
問題
ある企業は、データを処理する AWS Lambda 関数のセットを開発しています。これらの Lambda 関数は、共通のサードパーティライブラリを依存関係として使用する必要があります。このライブラリは新機能やバグ修正で頻繁に更新されます。同社は、Lambda 関数が常にライブラリの最新バージョンを使用することを保証したいと考えています。 最も運用効率の高い方法でこれらの要件を満たすソリューションはどれですか？

選択肢と解説

  • 1
    依存関係と関数コードを Amazon S3 バケットに保存する。
  • 2
    ライブラリを含む Lambda レイヤーを作成し、各 Lambda 関数にアタッチする。
  • ✓
    依存関係を Amazon Elastic File System (Amazon EFS) ファイルシステムにインストールし、各 Lambda 関数にアタッチする。
  • 4
    ライブラリを読み込む新しい Lambda 関数を作成し、既存の関数が必要時にそれを呼び出すよう構成する。

解説

【正解】C

【0からの解説】
この問題の最重要キーワードは「常に最新バージョンを使用することを保証」かつ「最も運用効率が高い」です。Amazon EFS を Lambda にマウントすると、ファイルシステム上の 1 か所にインストールしたライブラリを全 Lambda 関数が同時に参照できます。ライブラリを更新するときは EFS 上のファイルを上書きするだけでよく、各関数の再デプロイやバージョン更新の操作が一切不要です。そのため「更新が頻繁」「常に最新」「運用効率最優先」という条件の組み合わせでは EFS が最も手間がかかりません。

【誤りの選択肢】
A：S3 に置くだけでは、各関数が起動時にダウンロード・展開する処理を自前で実装・管理する必要があり、運用が煩雑になります。
B：Lambda レイヤーは共有ライブラリの定番手段ですが、ライブラリを更新するたびに「新しいレイヤーバージョンを発行」し、さらに「各関数が参照するレイヤーバージョンを更新（＝各関数の再デプロイ）」する作業が毎回発生します。頻繁更新かつ常に最新という条件では EFS より運用負荷が高くなります。
D：別の Lambda 関数を呼び出してライブラリを読み込む構成は、関数間呼び出しのオーバーヘッドと実装の複雑さが増し、最も非効率です。

【参考】
Lambda で Amazon EFS を使用する
Lambda レイヤー
この問題のページを開く →
問題 2これらの要件を満たすソリューションはどれですか？デプロイ
問題
ある開発者が AWS Lambda 関数を最適化しており、その変更を本番環境で全トラフィックのごく一部に対してテストしたいと考えています。この Lambda 関数は Amazon API Gateway の REST API へのリクエストを処理します。開発者は、API Gateway の URL を変更することなく、変更をデプロイして本番環境でテストを実施する必要があります。 これらの要件を満たすソリューションはどれですか？

選択肢と解説

  • 1
    現在本番デプロイされている Lambda 関数の関数バージョンを定義する。API Gateway エンドポイントを新しい Lambda 関数バージョンを参照するよう更新する。最適化した Lambda 関数コードをアップロードして発行する。本番 API Gateway ステージでカナリアリリースを定義し、カナリアリリースに振り向けるトラフィックの割合を設定する。API Gateway エンドポイントを Lambda 関数の $LATEST バージョンを使用するよう更新する。API をカナリアステージに発行する。
  • 2
    現在本番デプロイされている Lambda 関数の関数バージョンを定義する。API Gateway エンドポイントを新しい Lambda 関数バージョンを参照するよう更新する。最適化した Lambda 関数コードをアップロードして発行する。API Gateway エンドポイントを Lambda 関数の $LATEST バージョンを使用するよう更新する。新しい API Gateway ステージをデプロイする。
  • ✓
    Lambda 関数の $LATEST バージョンにエイリアスを定義する。API Gateway エンドポイントを新しい Lambda 関数エイリアスを参照するよう更新する。最適化した Lambda 関数コードをアップロードして発行する。本番 API Gateway ステージでカナリアリリースを定義し、カナリアリリースに振り向けるトラフィックの割合を設定する。API Gateway エンドポイントを Lambda 関数の $LATEST バージョンを使用するよう更新する。カナリアステージに発行する。
  • 4
    現在本番デプロイされている Lambda 関数の関数バージョンを定義する。API Gateway エンドポイントを新しい Lambda 関数バージョンを参照するよう更新する。最適化した Lambda 関数コードをアップロードして発行する。API Gateway エンドポイントを Lambda 関数の $LATEST バージョンを使用するよう更新する。API を本番 API Gateway ステージにデプロイする。

解説

【正解】C

【0からの解説】
「URL を変えずに本番トラフィックの一部だけで新コードをテストする」＝カナリアリリースの典型シナリオです。API Gateway のカナリアリリースは、既存の本番ステージ上で新しいデプロイを「カナリア」として配置し、指定した割合のトラフィックだけを新しいバージョンに流せます。残りは従来どおり処理されるため、同一の Invoke URL のまま段階的に検証できます。
Lambda 側では「エイリアス」を使って API Gateway から参照する向き先を安定させるのが定石です。エイリアスは特定のバージョンを指す名前付きポインタで、API Gateway はエイリアスを参照しておけば、Lambda の新コードを発行してエイリアスを切り替えるだけで向き先を更新できます。選択肢 C はエイリアスとカナリアリリースを組み合わせており、URL を変えずに少量トラフィックで本番テストする要件を満たします。

【誤りの選択肢】
A：カナリアリリースには言及していますが、エイリアスではなく関数バージョンを直接参照しており、$LATEST との行き来も整合せず、エイリアスを使う本来のベストプラクティスから外れています。
B：カナリアリリースを使わず「新しいステージをデプロイ」しています。新しいステージは別の Invoke URL を持つため、「URL を変更しない」という要件に反します。
D：カナリアリリースを使わず本番ステージにそのまま全面デプロイしています。これでは一部トラフィックだけでテストする要件を満たせません。

【参考】
API Gateway のカナリアリリースデプロイ
Lambda エイリアス
この問題のページを開く →
問題 3この要件を満たす、最も運用効率の高いソリューションはどれですか？セキュリティ
問題
ある企業は、Amazon Cognito ユーザープールをアイデンティティプロバイダーとして使用するアプリケーションを持っています。同社はユーザーレコードへのアクセスを保護する必要があります。同社は多要素認証 (MFA) を設定済みです。さらに、ユーザーがログインするたびに、ログインアクティビティの通知をメールで送信したいと考えています。 この要件を満たす、最も運用効率の高いソリューションはどれですか？

選択肢と解説

  • 1
    Amazon Simple Email Service (Amazon SES) を使ってメール通知を送信する AWS Lambda 関数を作成する。その関数を呼び出す Amazon API Gateway API を追加する。ログイン確認を受け取ったときにクライアント側からその API を呼び出す。
  • ✓
    Amazon Simple Email Service (Amazon SES) を使ってメール通知を送信する AWS Lambda 関数を作成する。その関数に対して Amazon Cognito のポスト認証 (post authentication) Lambda トリガーを追加する。
  • 3
    Amazon Simple Email Service (Amazon SES) を使ってメール通知を送信する AWS Lambda 関数を作成する。ログインステータスに基づいて関数を呼び出す Amazon CloudWatch Logs のサブスクリプションフィルターを作成する。
  • 4
    すべてのログを Amazon Kinesis Data Firehose にストリーミングするよう Amazon Cognito を構成する。ストリーミングされたログを処理してユーザーごとのログインステータスに基づきメール通知を送信する AWS Lambda 関数を作成する。

解説

【正解】B

【0からの解説】
Amazon Cognito ユーザープールには「Lambda トリガー」という拡張ポイントがあり、認証フローの特定タイミングで自前の Lambda 関数を自動実行できます。「ポスト認証 (Post authentication)」トリガーは、ユーザーのサインインが成功した直後に呼び出されます。ここで Amazon SES を使ってメールを送る Lambda を実行すれば、ログインのたびに自動でログイン通知メールを送れます。Cognito の標準機能だけで完結し、クライアント改修や別系統のログ処理が不要なため、最も運用効率が高くなります。

【誤りの選択肢】
A：API Gateway 経由でクライアント側から通知 API を呼ぶ方式は、クライアント実装に依存し、クライアントが呼ばなければ通知が漏れます。サーバー側で確実にトリガーする B より信頼性・効率で劣ります。
C：CloudWatch Logs サブスクリプションフィルターでログイン成功を検知する方式は、ログ出力前提の間接的な仕組みで、フィルター設計やログ形式への依存が生じ、Cognito の専用トリガーを使う B より複雑です。
D：Kinesis Data Firehose にログをストリーミングして Lambda で処理する構成は、ストリーミング基盤の追加・運用が必要でオーバーエンジニアリングであり、運用効率の観点で B に劣ります。

【参考】
Cognito ユーザープールの Lambda トリガー
ポスト認証 Lambda トリガー
この問題のページを開く →
問題 4（2つ選択してください。トラブルシューティングと最適化
問題
あるアプリケーションが Amazon Kinesis を使用してクリックストリームデータを処理しています。Kinesis へ流れ込むクリックストリームデータのフィードには周期的なスパイク（急増）が発生します。PutRecords API 呼び出しが時折失敗し、ログを見ると失敗した呼び出しが以下のレスポンスを返していることが分かりました。 【PutRecords API のレスポンス（文字起こし）】 { "FailedRecordCount": 1, "Records": [ { "SequenceNumber": "21269319989900637946712965403778482371", "ShardId": "shardId-000000000001" }, { "ErrorCode": "ProvisionedThroughputExceededException", "ErrorMessage": "Rate exceeded for shard shardId-000000000001 in stream exampleStreamName under account 123456789." }, { "SequenceNumber": "21269319989999637946712965403778482985", "ShardId": "shardId-000000000002" } ] } この例外を緩和するのに役立つ手法はどれですか？（2つ選択してください。）

選択肢と解説

  • ✓
    指数バックオフ付きのリトライを実装する。
  • 2
    PutRecords API の代わりに PutRecord API を使用する。
  • ✓
    リクエストの頻度やサイズ、あるいはその両方を削減する。
  • 4
    Kinesis の代わりに Amazon SNS を使用する。
  • 5
    KCL コンシューマーの数を削減する。

解説

【正解】A、C

【0からの解説】
レスポンス中の ErrorCode が ProvisionedThroughputExceededException で「Rate exceeded for shard ...（シャードのレート超過）」と出ています。これは、特定シャードの書き込みスループット上限（1 シャードあたり 1,000 レコード/秒、または 1 MB/秒）を超えたことを意味します。
対処の定石は 2 つです。1 つ目は「指数バックオフ付きリトライ (A)」。一時的なスロットリングに対し、待ち時間を指数的に伸ばしながら失敗したレコードだけ再送することで、輻輳を悪化させずに成功率を高めます。PutRecords は部分的失敗を返すため、FailedRecordCount と各レコードの ErrorCode を見て失敗分のみ再送するのが正しい実装です。2 つ目は「リクエストの頻度・サイズの削減 (C)」。送信ペースやバッチサイズを抑えることで、シャードのレート上限超過そのものを回避します（あわせてシャード分割やパーティションキー分散も有効）。

【誤りの選択肢】
B：PutRecord（単一レコード）に変えてもシャードあたりのスループット上限は同じであり、むしろ 1 回あたりの効率が落ちるため、スロットリングの根本対策になりません。
D：Amazon SNS はパブリッシュ/サブスクライブ型メッセージングで、Kinesis のようなシャード単位のストリーム処理・順序保証・再処理とは用途が異なり、スロットリングの解決策として的外れです。
E：KCL コンシューマーは「読み取り側」です。今回のエラーは「書き込み (PutRecords)」のスループット超過なので、コンシューマー数を減らしても書き込みスロットリングは緩和されません。

【参考】
Kinesis Data Streams の制限とエラー再試行
API リクエストのエラー再試行と指数バックオフ
この問題のページを開く →
問題 5ブラウザが JavaScript ファイルと Web フォントをブロックしないようにするには、開発者は何をすべきですか？AWS のサービスを使用した開発
問題
ある企業は、子会社の 1 つのためにクライアントサイドの Web アプリケーションを Amazon S3 でホストしています。この Web アプリケーションは https://www.example.com から Amazon CloudFront 経由でアクセスできます。展開が成功した後、同社は残りの子会社のためにさらに 3 つのクライアントサイド Web アプリケーションを、3 つの別々の S3 バケットでホストしたいと考えています。 この目標を達成するため、開発者は共通の JavaScript ファイルと Web フォントをすべて、Web アプリケーションに配信する中央 S3 バケットに移動しました。ところがテスト中に、ブラウザが JavaScript ファイルと Web フォントをブロックすることに開発者は気付きました。 ブラウザが JavaScript ファイルと Web フォントをブロックしないようにするには、開発者は何をすべきですか？

選択肢と解説

  • 1
    中央 S3 バケットへのアクセスを許可する 4 つのアクセスポイントを作成する。各 Web アプリケーションバケットにアクセスポイントを割り当てる。
  • 2
    中央 S3 バケットへのアクセスを許可するバケットポリシーを作成する。そのバケットポリシーを中央 S3 バケットにアタッチする。
  • ✓
    中央 S3 バケットへのアクセスを許可するクロスオリジンリソース共有 (CORS) 構成を作成する。その CORS 構成を中央 S3 バケットに追加する。
  • 4
    中央 S3 バケットに対するメッセージ整合性チェックを提供する Content-MD5 ヘッダーを作成する。各 Web アプリケーションのリクエストに Content-MD5 ヘッダーを挿入する。

解説

【正解】C

【0からの解説】
各 Web アプリは自分のオリジン（例: www.example.com）から配信されますが、共通の JavaScript や Web フォントは別オリジンの「中央 S3 バケット」から読み込みます。ブラウザには「同一オリジンポリシー」というセキュリティ機構があり、異なるオリジンからのリソース取得（特にフォントや一部のスクリプト読み込み）はサーバー側が明示的に許可しない限りブロックされます。
この許可を与える仕組みが CORS（クロスオリジンリソース共有）です。中央 S3 バケットに CORS 構成を追加し、各 Web アプリのオリジンからのアクセスを許可すれば、ブラウザはレスポンスの CORS ヘッダーを見てクロスオリジン読み込みを許可します。症状（クロスオリジンのブロック）と対策（CORS 設定）が直結する典型問題です。

【誤りの選択肢】
A：S3 アクセスポイントは大規模な共有データセットへのアクセス管理を簡素化する機能で、ブラウザのクロスオリジン制約とは無関係です。
B：バケットポリシーは S3 側の認可（誰がオブジェクトを取得できるか）を制御するもので、ブラウザの同一オリジンポリシーによるブロックは解決できません。アクセス可否ではなくブラウザのオリジン制御が問題なので的外れです。
D：Content-MD5 はデータ整合性（転送中の破損検出）のためのヘッダーで、クロスオリジン読み込みの許可とは全く関係ありません。

【参考】
Amazon S3 の CORS 設定
この問題のページを開く →
問題 6暗号化要件を満たしながら、宛先リージョンでアプリケーションを実行できるよう拡張するには、開発者はどうすればよいですか？セキュリティ
問題
ある開発者は、アプリケーションを複数の AWS リージョンで実行できるよう拡張したいと考えています。開発者は最新の変更を含む Amazon マシンイメージ (AMI) をコピーし、宛先リージョンで新しいアプリケーションスタックを作成したいと考えています。会社の要件により、すべての AMI はすべてのリージョンで暗号化されている必要があります。しかし、同社が使用している AMI のすべてが暗号化されているわけではありません。 暗号化要件を満たしながら、宛先リージョンでアプリケーションを実行できるよう拡張するには、開発者はどうすればよいですか？

選択肢と解説

  • ✓
    暗号化パラメータを指定して新しい AMI を作成する。暗号化された AMI を宛先リージョンにコピーする。暗号化されていない AMI を削除する。
  • 2
    AWS Key Management Service (AWS KMS) を使用して、暗号化されていない AMI に対して暗号化を有効にする。暗号化された AMI を宛先リージョンにコピーする。
  • 3
    AWS Certificate Manager (ACM) を使用して、暗号化されていない AMI に対して暗号化を有効にする。暗号化された AMI を宛先リージョンにコピーする。
  • 4
    暗号化されていない AMI を宛先リージョンにコピーする。宛先リージョンでデフォルトの暗号化を有効にする。

解説

【正解】A

【0からの解説】
AMI（およびその基になる EBS スナップショット）は、既存の暗号化されていないものを「後からその場で暗号化」することはできません。暗号化は EBS スナップショット/ボリュームの作成・コピー時に指定するものだからです。
正しい手順は、暗号化されていない既存 AMI から「暗号化パラメータを指定して新たに暗号化済みの AMI を作成（CopyImage の Encrypted 指定など）」し、その暗号化済み AMI を宛先リージョンへコピーし、不要になった暗号化されていない AMI を削除することです。これにより全リージョンで暗号化要件を満たせます。

【誤りの選択肢】
B：KMS は暗号化に使う鍵を管理するサービスですが、「既存の暗号化されていない AMI をその場で暗号化する」という操作は存在しません。暗号化は新規作成・コピー時に行う必要があり、表現として誤りです。
C：ACM は TLS/SSL 証明書を管理するサービスで、AMI や EBS の暗号化とは全く無関係です。
D：暗号化されていない AMI をコピーしてからリージョンのデフォルト暗号化を有効にしても、すでにコピーされた AMI 自体は暗号化されません。デフォルト暗号化は「今後新規作成されるボリューム」に適用される設定であり、既存の暗号化されていない AMI を遡って暗号化するものではないため要件を満たしません。

【参考】
EBS の暗号化
AMI のコピー（暗号化指定）
この問題のページを開く →
問題 7これらの要件を満たすソリューションはどれですか？AWS のサービスを使用した開発
問題
ある開発者が、IoT デバイス上にデプロイされるアプリケーションを作成しています。このアプリケーションは、AWS Lambda 関数としてデプロイされた RESTful API にデータを送信します。アプリケーションは各 API リクエストに一意の識別子を割り当てます。アプリケーションからの API リクエストの量は、1 日のうちの任意の時間にランダムに増加することがあります。 リクエストのスロットリング期間中、アプリケーションはリクエストを再試行する必要が生じる場合があります。API は、不整合やデータ損失なしに重複リクエストを処理できる必要があります。 これらの要件を満たすソリューションはどれですか？

選択肢と解説

  • 1
    Amazon RDS for MySQL DB インスタンスを作成する。各リクエストの一意の識別子をデータベーステーブルに保存する。リクエストを処理する前にテーブルでその識別子を確認するよう Lambda 関数を変更する。
  • ✓
    Amazon DynamoDB テーブルを作成する。各リクエストの一意の識別子をテーブルに保存する。リクエストを処理する前にテーブルでその識別子を確認するよう Lambda 関数を変更する。
  • 3
    Amazon DynamoDB テーブルを作成する。各リクエストの一意の識別子をテーブルに保存する。重複リクエストを受け取ったときにクライアントエラーレスポンスを返すよう Lambda 関数を変更する。
  • 4
    Amazon ElastiCache for Memcached インスタンスを作成する。各リクエストの一意の識別子をキャッシュに保存する。リクエストを処理する前にキャッシュでその識別子を確認するよう Lambda 関数を変更する。

解説

【正解】B

【0からの解説】
この問題が問うているのは「べき等性（idempotency）」です。クライアントがリクエストを再試行すると同じリクエストが重複して届くことがありますが、API は「同じ処理を二重に実行しない」「データ損失を起こさない」必要があります。各リクエストには一意の識別子（べき等性キー）が付いているので、処理の前にその識別子を保存済みストアで照合し、未処理なら処理して記録、処理済みなら処理をスキップ（または同じ結果を返す）ようにします。
このストアには、低レイテンシ・サーバーレスでスケールし、条件付き書き込みで原子的な重複チェックができる Amazon DynamoDB が最適です。ランダムなトラフィック急増にもサーバー管理なしで追従でき、Lambda との相性も良好です。

【誤りの選択肢】
A：RDS for MySQL でも識別子の保存・照合は可能ですが、突発的なスパイクへのスケーリングや接続管理の点でサーバーレスの DynamoDB に劣り、運用負荷が高くなります。
C：DynamoDB に保存する点は良いものの、重複時に常にクライアントエラーを返す設計は不適切です。再試行は正当な動作であり、元のリクエストが成功していれば本来は成功結果（または冪等な無害応答）を返すべきで、エラー扱いにすると「データ損失なし」の要件と整合しません。
D：ElastiCache for Memcached は揮発性のキャッシュで永続性がなく、ノード障害や項目の追い出し（エビクション）で識別子が失われる可能性があります。重複検知の確実な記録には永続的な DynamoDB が適切です。

【参考】
Lambda 関数でのべき等性の実装
DynamoDB の条件付き書き込み
この問題のページを開く →
問題 8現在および将来の労力を最小にしてこの要件を満たすソリューションはどれですか？トラブルシューティングと最適化
問題
ある企業が、オンプレミスのデータベースを Amazon RDS for MySQL に移行しています。同社のワークロードは読み取りが中心です。同社は、クエリの読み取りパフォーマンスを最適化するためにコードをリファクタリングしたいと考えています。 現在および将来の労力を最小にしてこの要件を満たすソリューションはどれですか？

選択肢と解説

  • 1
    マルチ AZ の Amazon RDS デプロイを使用する。コードがデータベースに対して行う接続数を増やすか、接続プールを使用している場合は接続プールのサイズを増やす。
  • 2
    マルチ AZ の Amazon RDS デプロイを使用する。クエリがセカンダリ RDS インスタンスにアクセスするようコードを変更する。
  • ✓
    1 つ以上のリードレプリカを使って Amazon RDS をデプロイする。リードレプリカの URL をクエリが使用するようアプリケーションコードを変更する。
  • 4
    オープンソースのレプリケーションソフトウェアを使用して Amazon EC2 インスタンス上に MySQL データベースのコピーを作成する。クエリが EC2 インスタンスの IP アドレスを使用するようアプリケーションコードを変更する。

解説

【正解】C

【0からの解説】
読み取り中心のワークロードで読み取り性能を上げる定番手段が「リードレプリカ」です。RDS for MySQL はマネージドのリードレプリカを最大数台まで作成でき、読み取りクエリをレプリカに振り分けることで、プライマリ（書き込み）への負荷を下げつつ読み取りスループットを水平にスケールできます。アプリ側はレプリカのエンドポイント（URL）に読み取りクエリを向けるだけでよく、AWS がレプリケーションを管理するため、現在も将来も運用労力が小さくて済みます。

【誤りの選択肢】
A：接続数や接続プールサイズを増やしても、単一インスタンスの処理能力上限は変わらず、読み取りスループットの本質的な向上にはなりません。
B：マルチ AZ の「スタンバイ（セカンダリ）」は可用性（フェイルオーバー）のための待機系であり、通常時に読み取りトラフィックを受け付けることはできません。クエリをスタンバイに向ける構成は成立しません。
D：EC2 上に自前で MySQL レプリカを構築すると、レプリケーション設定・パッチ適用・障害対応などをすべて自分で運用する必要があり、現在も将来も労力が最大になります。マネージドのリードレプリカを使う C の対極です。

【参考】
Amazon RDS リードレプリカ
RDS マルチ AZ デプロイ
この問題のページを開く →
問題 9この要件を最もコスト効率よく満たすソリューションはどれですか？AWS のサービスを使用した開発
問題
ある企業には、オンプレミスで稼働するマルチノードの Windows レガシーアプリケーションがあります。このアプリケーションは、構成ファイルを .xml 形式で保存する集中構成リポジトリとして、ネットワーク共有フォルダを使用しています。同社はこのアプリケーションを Amazon EC2 インスタンスに移行しようとしています。AWS への移行の一環として、開発者はリポジトリに高可用性を提供するソリューションを特定する必要があります。 この要件を最もコスト効率よく満たすソリューションはどれですか？

選択肢と解説

  • 1
    Amazon Elastic Block Store (Amazon EBS) ボリュームを EC2 インスタンスの 1 つにマウントする。EBS ボリューム上にファイルシステムをデプロイする。ホスト OS を使用してフォルダを共有する。アプリケーションコードを更新し、その共有フォルダから構成ファイルを読み書きする。
  • 2
    インスタンスストアボリュームを持つマイクロ EC2 インスタンスをデプロイする。ホスト OS を使用してフォルダを共有する。アプリケーションコードを更新し、その共有フォルダから構成ファイルを読み書きする。
  • ✓
    リポジトリをホストする Amazon S3 バケットを作成する。既存の .xml ファイルを S3 バケットに移行する。アプリケーションコードを更新し、AWS SDK を使用して Amazon S3 から構成ファイルを読み書きする。
  • 4
    リポジトリをホストする Amazon S3 バケットを作成する。既存の .xml ファイルを S3 バケットに移行する。S3 バケットをローカルボリュームとして EC2 インスタンスにマウントする。アプリケーションコードを更新し、ディスクから構成ファイルを読み書きする。

解説

【正解】C

【0からの解説】
「高可用性（HA）」かつ「最もコスト効率が良い」が判断軸です。Amazon S3 は標準で複数のアベイラビリティーゾーンにデータを冗長化する高耐久・高可用なオブジェクトストレージで、追加のクラスタ構成なしに HA を実現できます。マルチノードの全 EC2 インスタンスが同じ S3 バケットを参照すれば、構成ファイルの集中リポジトリとして機能します。アプリケーションコードを AWS SDK（GetObject / PutObject）で S3 を読み書きするよう改修するのが、サーバー追加もファイルシステム管理も不要で最もコスト効率の高い方法です。

【誤りの選択肢】
A：EBS ボリュームは単一の AZ・単一インスタンスに紐づくため、そのインスタンスや AZ が障害になると共有フォルダにアクセスできず、HA を満たしません。
B：インスタンスストアは一時的（エフェメラル）ストレージで、インスタンス停止・終了時にデータが消失します。単一インスタンス構成でもあり HA も耐久性も不十分です。
D：S3 自体は HA ですが、S3 をローカルファイルシステムとしてマウントする方式（ファイルゲートウェイやサードパーティツール）は追加コンポーネントの運用・整合性管理が必要で、SDK 直接アクセスより複雑かつコスト効率が劣ります。

【参考】
Amazon S3 とは
Amazon S3 のデータ耐久性と可用性
この問題のページを開く →
問題 10これらの要件を満たすソリューションはどれですか？AWS のサービスを使用した開発
問題
ある開発者が、個人健康情報（PHI）を保存するアプリケーションを作成しています。PHI は常時暗号化されている必要があります。データは暗号化された Amazon RDS for MySQL DB インスタンスに保存されています。開発者は、頻繁にアクセスされるデータをキャッシュしてアプリケーションのパフォーマンスを向上させたいと考えており、同時にキャッシュされたデータセットをソートまたはランク付けする機能も追加したいと考えています。 これらの要件を満たすソリューションはどれですか？

選択肢と解説

  • ✓
    Amazon ElastiCache for Redis インスタンスを作成する。転送中および保管時のデータ暗号化を有効にする。頻繁にアクセスされるデータをキャッシュに保存する。
  • 2
    Amazon ElastiCache for Memcached インスタンスを作成する。転送中および保管時のデータ暗号化を有効にする。頻繁にアクセスされるデータをキャッシュに保存する。
  • 3
    Amazon RDS for MySQL リードレプリカを作成する。SSL を使用してリードレプリカに接続する。頻繁にアクセスされるデータを保存するようリードレプリカを構成する。
  • 4
    Amazon DynamoDB テーブルとそのテーブル用の DynamoDB Accelerator (DAX) クラスターを作成する。頻繁にアクセスされるデータを DynamoDB テーブルに保存する。

解説

【正解】A

【0からの解説】
要件は (1) キャッシュによる高速化、(2) キャッシュデータのソート/ランク付け、(3) 常時暗号化（保管時・転送中）の 3 つです。Amazon ElastiCache for Redis はこれをすべて満たします。Redis にはソート済みセット（Sorted Set, ZSET）というデータ型があり、スコアに基づく自動ソートやランキング取得（ZRANGE / ZREVRANGE 等）をネイティブに行えます。また Redis は保管時暗号化（at-rest）と転送中暗号化（in-transit, TLS）の両方をサポートするため、PHI の常時暗号化要件にも適合します。

【誤りの選択肢】
B：Memcached はシンプルな Key-Value キャッシュで、ソート済みセットのようなソート/ランク付けデータ構造を持ちません。要件 (2) を満たせません。
C：RDS リードレプリカは読み取りスケールのための仕組みであり、インメモリキャッシュではないためレスポンスはキャッシュほど速くなく、「ソート/ランク機能をキャッシュに追加」という意図にも合致しません。
D：DynamoDB + DAX は別のデータストアへの移行であり、既存の暗号化済み RDS データをキャッシュする要件に対して過剰かつ不適切で、ソート済みセットのようなランキング機能も提供しません。

【参考】
Amazon ElastiCache for Redis
ElastiCache for Redis の暗号化
この問題のページを開く →
問題 11最も運用上のオーバーヘッドが少なく、これらの要件を満たすソリューションはどれですか？AWS のサービスを使用した開発
問題
ある開発者が Amazon API Gateway の REST API を保守しています。顧客はフロントエンド UI と Amazon Cognito 認証を介してこの API を使用しています。 開発者は、新しいエンドポイントと後方互換性のないインターフェイス変更を含む新バージョンの API を持っています。開発者は、顧客に影響を与えることなく、チームの他の開発者にベータアクセスを提供する必要があります。 最も運用上のオーバーヘッドが少なく、これらの要件を満たすソリューションはどれですか？

選択肢と解説

  • ✓
    API Gateway API に開発（development）ステージを定義する。他の開発者には、エンドポイントをその開発ステージに向けるよう指示する。
  • 2
    新しい API アプリケーションコードを指す新しい API Gateway API を定義する。他の開発者には、エンドポイントをその新しい API に向けるよう指示する。
  • 3
    どのコードバージョンを呼び出すかを決定するクエリパラメータを API アプリケーションコードに実装する。
  • 4
    開発者が追加したい API エンドポイントのために、新しい API Gateway エンドポイントを指定する。

解説

【正解】A

【0からの解説】
API Gateway の「ステージ」は、同一 API の独立したデプロイ環境（例: prod, dev, test）です。各ステージは独自の URL（呼び出し URL に /ステージ名 が付く）を持ち、デプロイ内容を個別に管理できます。新バージョンを開発（development）ステージにデプロイし、社内開発者にはその開発ステージの URL を使ってもらえば、本番ステージを利用する既存顧客にはまったく影響を与えずにベータ検証ができます。既存 API を再利用し設定追加だけで済むため、運用オーバーヘッドが最小です。

【誤りの選択肢】
B：まったく別の API を新規作成すると、Cognito オーソライザーやリソース定義などの設定を二重に保守する必要があり、運用負荷が高くなります。
C：アプリケーションコード内でクエリパラメータによりバージョン分岐させる方式は、コードの複雑化とテスト負荷を招き、API レベルのクリーンなバージョン分離になりません。
D：新しいエンドポイント（リソース/メソッド）を既存の本番 API に追加すると、その API を使う顧客に変更が露出してしまい、「顧客に影響を与えない」要件に反します。

【参考】
API Gateway でのステージのデプロイ
REST API のセットアップ
この問題のページを開く →
問題 12この目標を達成するのに役立つアクションはどれですか？トラブルシューティングと最適化
問題
ある企業は、毎日更新される統計情報への認証不要の読み取りアクセスを提供するため、API をサービスとしてインターネット上で提供しています。同社は Amazon API Gateway と AWS Lambda を使用してこれらの API を開発しています。このサービスは人気が高まっており、同社は API の応答性を高めたいと考えています。 この目標を達成するのに役立つアクションはどれですか？

選択肢と解説

  • ✓
    API Gateway で API キャッシュを有効にする。
  • 2
    API Gateway がインターフェイス型 VPC エンドポイントを使用するよう構成する。
  • 3
    API でクロスオリジンリソース共有（CORS）を有効にする。
  • 4
    API Gateway で使用量プランと API キーを構成する。

解説

【正解】A

【0からの解説】
データは「毎日更新される」読み取り専用の統計情報なので、同じレスポンスを短時間に何度も返すケースが多くキャッシュが非常に有効です。API Gateway のステージで API キャッシュを有効にすると、エンドポイントのレスポンスを指定した TTL（存続期間）の間キャッシュし、同じリクエストに対してはバックエンドの Lambda を呼ばずにキャッシュから即座に返します。これによりレイテンシが下がり応答性が向上し、同時に Lambda の呼び出し回数とコストも削減できます。データの更新が日次なら TTL を長めに設定でき相性が良いです。

【誤りの選択肢】
B：インターフェイス型 VPC エンドポイントは VPC 内部からプライベートに API へアクセスするための仕組みで、インターネット公開 API の応答性向上には関係しません。
C：CORS はブラウザが別オリジンへのリクエストを許可するためのヘッダー設定であり、応答性能（レイテンシ）には影響しません。
D：使用量プランと API キーは利用者ごとのスロットリングやクォータ管理のための機能で、応答性を高めるものではありません。

【参考】
API Gateway での API キャッシュの有効化
この問題のページを開く →
問題 13これらの要件を満たすソリューションはどれですか？トラブルシューティングと最適化
問題
ある企業が AWS 上でサーバーレスアプリケーションを構築しています。このアプリケーションは AWS Lambda 関数を使用して、24 時間 365 日体制で顧客の注文を処理します。Lambda 関数は支払い処理のために外部ベンダーの HTTP API を呼び出します。 負荷テスト中に、開発者は外部ベンダーの支払い処理 API が時折タイムアウトしてエラーを返すことを発見しました。同社は、一部の支払い処理 API 呼び出しがエラーを返すことを想定しています。 同社は、支払い処理外部 API のエラー率が 1 時間あたりの全トランザクション数の 5% を超えた場合にのみ、サポートチームがほぼリアルタイムで通知を受け取ることを望んでいます。開発者は、サポートチームに通知するよう構成済みの既存の Amazon Simple Notification Service (Amazon SNS) トピックを使用する必要があります。 これらの要件を満たすソリューションはどれですか？

選択肢と解説

  • 1
    支払い処理 API 呼び出しの結果を Amazon CloudWatch に書き込む。Amazon CloudWatch Logs Insights を使用して CloudWatch ログをクエリする。Lambda 関数をスケジュール実行して CloudWatch ログをチェックし、既存の SNS トピックに通知する。
  • ✓
    外部支払い処理 API 呼び出しの失敗を記録するカスタムメトリクスを CloudWatch に発行する。エラー率が指定したレートを超えたときに既存の SNS トピックに通知する CloudWatch アラームを構成する。
  • 3
    外部支払い処理 API 呼び出しの結果を新しい Amazon SNS トピックに発行する。サポートチームのメンバーをその新しい SNS トピックにサブスクライブさせる。
  • 4
    外部支払い処理 API 呼び出しの結果を Amazon S3 に書き込む。定期的に実行される Amazon Athena クエリをスケジュールする。エラー率が指定したレートを超えたときに既存の SNS トピックに通知を送信するよう Athena を構成する。

解説

【正解】B

【0からの解説】
要件は「外部 API のエラー率が 1 時間あたり 5% を超えたときにのみ、ほぼリアルタイムで SNS 通知」です。これは CloudWatch のカスタムメトリクス + CloudWatch アラームの典型パターンです。Lambda から PutMetricData で「成功数」「失敗数（エラー）」などをカスタムメトリクスとして発行し、CloudWatch アラームでメトリクス演算（失敗 ÷ 全体）を用いてエラー率を算出、しきい値 5%・評価期間 1 時間でアラームを構成します。アラームのアクションに既存 SNS トピックを指定すれば、しきい値超過時に即座に通知が飛びます。マネージドで低レイテンシ、運用も簡潔です。

【誤りの選択肢】
A：ログを書き込み、別の Lambda をスケジュール実行して Logs Insights でクエリしてしきい値判定する方式は、ポーリング間隔ぶんの遅延と自作ロジックの保守負荷があり、「ほぼリアルタイム」かつシンプルという点で劣ります。
C：すべての結果を新しい SNS トピックに発行すると成功も失敗も全件通知されてしまい、「エラー率 5% 超過時のみ」という条件付き通知を実現できません。
D：S3 + Athena の定期クエリはバッチ的でレイテンシが大きく、また Athena 自体がしきい値超過で SNS に通知する機能を持たないため要件を満たせません。

【参考】
CloudWatch カスタムメトリクスの発行
CloudWatch アラームの使用
この問題のページを開く →
問題 14開発者はどのようにして関数のパフォーマンスを向上できますか？トラブルシューティングと最適化
問題
ある開発者が AWS Lambda 関数を作成しました。この関数は CPU バウンド（CPU 負荷が高い）です。開発者は、関数が素早くレスポンスを返すようにしたいと考えています。 開発者はどのようにして関数のパフォーマンスを向上できますか？

選択肢と解説

  • 1
    関数の CPU コア数を増やす。
  • ✓
    関数のメモリを増やす。
  • 3
    関数の予約済み同時実行数（reserved concurrency）を増やす。
  • 4
    関数のタイムアウトを増やす。

解説

【正解】B

【0からの解説】
AWS Lambda では、割り当てメモリ量に比例して CPU パワー（および割り当てられる vCPU）が自動的に増加します。Lambda の設定で直接コア数を指定することはできず、CPU を増やしたい場合はメモリ設定を引き上げるのが唯一の方法です。CPU バウンドな関数はメモリを増やすほど割り当て CPU が増え、処理が速く完了してレスポンスが速くなります（適切なメモリ設定はコスト最適化にもつながります）。

【誤りの選択肢】
A：Lambda には CPU コア数を直接指定する設定が存在しません。CPU はメモリ量に応じて自動で割り当てられます。
C：予約済み同時実行数は同時に実行できる関数インスタンスの上限を確保する設定で、1 回あたりの処理速度（CPU 性能）には影響しません。
D：タイムアウトは関数が実行を許される最大時間を延ばすだけで、処理を速くするものではありません。

【参考】
Lambda のメモリと CPU の関係
Lambda 関数のパフォーマンス最適化
この問題のページを開く →
問題 15この要件を満たすソリューションはどれですか？AWS のサービスを使用した開発
問題
ある企業が複数の AWS アカウントで Amazon EC2 インスタンスを実行しています。開発者は、EC2 インスタンスのすべてのライフサイクルイベントを収集するアプリケーションを実装する必要があります。このアプリケーションは、さらなる処理のために、ライフサイクルイベントを会社のメイン AWS アカウント内の単一の Amazon Simple Queue Service (Amazon SQS) キューに保存する必要があります。 この要件を満たすソリューションはどれですか？

選択肢と解説

  • 1
    すべてのアカウントからの EC2 インスタンスライフサイクルイベントを、メインアカウントの Amazon EventBridge イベントバスに配信するよう Amazon EC2 を構成する。すべての EC2 インスタンスライフサイクルイベントに一致する EventBridge ルールをメインアカウントのイベントバスに追加する。そのルールのターゲットとして SQS キューを追加する。
  • 2
    メインアカウントの SQS キューのリソースポリシーを使用して、各アカウントにその SQS キューへの書き込み権限を付与する。各アカウントの Amazon EventBridge イベントバスに、すべての EC2 インスタンスライフサイクルイベントに一致する EventBridge ルールを追加する。そのルールのターゲットとしてメインアカウントの SQS キューを追加する。
  • 3
    会社の各アカウント内のすべての EC2 インスタンスをスキャンして EC2 インスタンスのライフサイクル変更を検出する AWS Lambda 関数を記述する。ライフサイクル変更を検出した場合に、メインアカウントの SQS キューに通知メッセージを書き込むよう Lambda 関数を構成する。Lambda 関数を毎分呼び出す Amazon EventBridge スケジュールルールを追加する。
  • ✓
    メインアカウントのイベントバスのアクセス許可を、すべてのアカウントからイベントを受信できるよう構成する。各アカウントに、すべての EC2 インスタンスライフサイクルイベントをメインアカウントのイベントバスに送信する Amazon EventBridge ルールを作成する。すべての EC2 インスタンスライフサイクルイベントに一致する EventBridge ルールをメインアカウントのイベントバスに追加する。そのルールのターゲットとして SQS キューを設定する。

解説

【正解】D

【0からの解説】
EC2 のライフサイクル状態変化（起動・停止・終了など）は EventBridge に「EC2 Instance State-change Notification」イベントとして自動的に発行されます。複数アカウントのイベントを一箇所に集約する標準パターンは「クロスアカウントのイベントバス連携」です。具体的には、(1) メイン（受信側）アカウントのデフォルトイベントバスに、各メンバーアカウントからの PutEvents を許可するリソースベースのアクセス許可を設定し、(2) 各メンバーアカウントに、EC2 ライフサイクルイベントをメインアカウントのイベントバスへ転送する EventBridge ルールを作成し、(3) メインアカウント側にそのイベントに一致するルールを作って SQS キューをターゲットにします。D はこの 3 ステップを正しく記述しています。

【誤りの選択肢】
A：「EC2 がイベントを他アカウントのイベントバスに直接配信するよう構成する」設定は存在しません。EC2 イベントは自アカウントの EventBridge に出るため、明示的なバス間転送が必要です。
B：EventBridge のルールはターゲットとして他アカウントの「イベントバス」を指定できますが、他アカウントの SQS キューを直接クロスアカウントのターゲットにする方式（このシナリオ）としては正しいクロスアカウント集約パターンになっていません。標準パターンはメインアカウントのイベントバスへ転送する D です。
C：全アカウントの全 EC2 を毎分スキャンする Lambda は非効率でスケールせず、イベント駆動でないため取りこぼしや遅延が生じ、ライフサイクルイベント収集の正しいアプローチではありません。

【参考】
EventBridge のクロスアカウントイベント送信
EventBridge と EC2 の状態変化イベント
この問題のページを開く →

DVA-C02 対策のハンズオンラボ

実際の Azure・AWS 環境を払い出して手を動かせます。問題演習と組み合わせると理解が定着します。

CodePipeline にセキュリティ/ガバナンス検査ステージ(CodeBuild)を追加する
intermediate・約 50 分
CodePipeline と CodeBuild で品質・コンプライアンスゲートを実装する
intermediate・約 50 分
CodePipeline に手動承認とSNS通知でガバナンスゲートを追加する
intermediate・約 45 分
AWS コンソールで Lambda 関数を作成・テストする
beginner・約 40 分
Step Functions で S3 アップロードデータを自動分類するワークフロー
intermediate・約 50 分
Lambda + API Gateway + DynamoDB でサーバーレス CRUD API を作る
intermediate・約 50 分
音声をテキスト化して分析する処理パイプライン（Transcribe + Comprehend）
intermediate・約 50 分
IAM ポリシーのリソース指定と条件キーでワークフローのアクセスを保護する
intermediate・約 50 分
DVA-C02 のラボを全て見る（21 件）→

DVA-C02 模擬問題集についてよくある質問

DVA-C02 の練習問題は無料で試せますか？

はい。DVA-C02 は先頭 15 問を会員登録なしで、正解と全選択肢の解説つきでご覧いただけます。16 問目以降は模試プラン（月額 ¥980）または Pro プラン（月額 ¥4,980）でご利用ください。

問題は何問ありますか？

DVA-C02 は本番形式の練習テスト 4 回・全 200 問を収録しています。全問に解説が付いています。

解説は付いていますか？

全ての問題に、正解の理由と各選択肢がなぜ誤りなのかの解説を付けています。ドメイン（出題分野）別の正答率も受験後に確認できます。

DVA-C02 のハンズオン学習もできますか？

はい。DVA-C02 に対応するハンズオンラボを 21 件ご用意しています。実際の Azure・AWS 環境を払い出して手を動かしながら学習できます。