【公式ドキュメント連携・全範囲カバー】AWS DVA-C02日本語問題集 260問（詳細解説付き）

更新履歴

• 2025/3:  演習問題4 網羅性向上のため問題を追加しました。( +50問)

• 2025/6:  演習問題1~4(全問題) 解説を大幅強化しました。また、古い傾向の問題を削除し、新しい傾向の問題に差し替えました。（OpsWork、CodeStarなどの廃止サービスの削除、App Runnerなどの新規サービスの問題を追加）

コース紹介

DVA-C02の全ての出題範囲を網羅した実践問題集です。
AWS DVA（AWS Certified Developer - Associate）に合格したい方はもちろんのこと、AWSでシステム開発される方の開発能力、セキュリティ能力、デプロイ能力、トラブルシュート能力を向上するために最適なコースです。

本問題集のサンプル

以下本問題集のサンプル問題で自分が求めているレベルかを確認してください

問題

ある企業では、毎日パートナーから注文のバッチを受け取るアプリケーションを運用しています。このアプリケーションはAWS Lambda関数を使ってバッチを処理します。ただし、バッチに注文が含まれていない場合、迅速にAmazon SNSを使用して通知を送信する必要があります。この要件を満たすために、最小限の実装コストで対応できる方法を2つ選んでください。

選択肢

A.  既存のLambda関数のコードを更新し、各パートナーの注文数をAmazon CloudWatchのカスタムメトリクスに送信します。

B.  新しいLambda関数をスケジュール実行し、CloudWatchメトリクスを24時間ごとに分析して注文がない場合にSNSトピックに通知を送信するよう設定します。

C.  既存のLambda関数を変更して、注文データをAmazon Kinesis Data Streamsに記録します。

D.  Amazon Kinesis Data Streamsを利用し、新しいLambda関数を設定して注文データを追跡し、注文がない場合にSNS通知を送信します。

E. CloudWatchカスタムメトリクスの値が0の場合にSNS通知を送信するCloudWatchアラームを設定します。

考えてからスクロールしてください

・

・

・

・

・

・

・

・

正解：A, E

解説：

A: 既存のLambda関数にCloudWatchのPutMetricData APIを使用してカスタムメトリクスを送信するコードを数行追加するだけで実装できます。この方法は既存のアーキテクチャを大幅に変更することなく、最小限のコード変更で注文数の監視が可能になります。カスタムメトリクスを使用することで、パートナーごとや日付ごとの詳細な追跡も可能であり、将来的な分析やレポート作成にも活用できます。実装コストが低く、保守も容易な方法です。

E: CloudWatchアラームは、AWSマネジメントコンソールから数分で設定できる標準機能です。メトリクス値が指定した条件（この場合は0）を満たした場合に、自動的にSNSトピックに通知を送信できます。追加のコード実装は一切不要で、設定のみで要件を満たすことができます。アラームの設定は非常にシンプルであり、閾値の変更や通知先の追加も容易です。運用コストも最小限に抑えられる理想的な解決方法です。

問われている要件

• 毎日受け取るバッチに注文が含まれていない場合の迅速な通知

• Amazon SNSを使用した通知の実装

• 最小限の実装コストでの対応

前提知識

Amazon CloudWatchカスタムメトリクス

• メトリクス送信: PutMetricData APIを使用した独自メトリクスの作成

• ディメンション: パートナー名、日付などによるメトリクスの分類

• データポイント: タイムスタンプ付きの数値データ

• 名前空間: メトリクスの論理的なグループ化

• 統計: Sum、Average、Maximum、Minimumなどの集計値

CloudWatchアラームの機能

• 閾値監視: メトリクス値の上限・下限監視

• アラーム状態: OK、ALARM、INSUFFICIENT_DATAの3つの状態

• 通知アクション: SNS、Auto Scaling、EC2アクションとの連携

• 複合アラーム: 複数のアラーム条件を組み合わせた監視

• アラーム履歴: 状態変化の詳細なログ記録

Lambda関数での実装パターン

• メトリクス送信: boto3のCloudWatchクライアントを使用

• エラーハンドリング: メトリクス送信失敗時の適切な処理

• バッチ処理: 複数メトリクスの一括送信による効率化

• パフォーマンス: 非同期処理によるレスポンス時間最適化

Amazon SNSの通知機能

• トピック: メッセージの配信チャネル

• サブスクリプション: Email、SMS、HTTPエンドポイントなどの配信先

• メッセージフィルタリング: 条件に基づく選択的配信

• 配信ステータス: 成功・失敗の詳細なログ

• 重複除去: FIFOトピックでの重複排除機能

監視アーキテクチャのベストプラクティス

• メトリクス設計: ビジネス要件に基づく適切なメトリクス定義

• アラーム設定: 誤報を避ける適切な閾値設定

• 通知管理: 適切な通知頻度と受信者の設定

• ダッシュボード: 可視化による状況把握の向上

コスト最適化の考慮事項

• カスタムメトリクス料金: メトリクス数とAPI呼び出し回数に基づく課金

• アラーム料金: アラーム数に基づく月額料金

• SNS料金: 通知回数に基づく従量課金

• Lambda料金: 実行時間とメモリ使用量に基づく課金

実装の具体例（Python）

（教材にはソースコードが例示されます。）

解くための考え方

この問題では、既存システムへの最小限の変更で監視・通知機能を追加することが求められています。

効果的なアプローチは、以下の2段階で構成されます：

1. データ収集: 既存Lambda関数でのメトリクス送信

2. 監視・通知: CloudWatchアラームによる自動通知

このアーキテクチャにより、コード変更を最小限に抑えながら、リアルタイムでの注文監視と迅速な通知が実現できます。正解選択肢の組み合わせは、実装の容易さ、運用コストの低さ、保守性の高さという3つの観点で最適解となります。

Kinesis Data Streamsや追加Lambda関数を使用する方法は、要件に対して過剰な複雑性を導入するため、最小限の実装コストという条件に適合しません。

参考資料（教材には公式ドキュメントへのリンクが記載されます。）

1. Amazon CloudWatch メトリクスの概要:

2. CloudWatchアラームの設定方法:

3. Amazon SNSの使用例:

不正解選択肢の評価

B：新しいLambda関数の作成、EventBridgeでのスケジュール設定、CloudWatchメトリクスの分析ロジックの実装など、複数のコンポーネントを追加する必要があり、実装コストが高くなります。また、24時間ごとの分析では、問題で要求されている「迅速な通知」に対応できません。さらに、メトリクス分析のための複雑なロジックを実装する必要があり、保守性の面でも劣ります。最小限の実装コストという要件に適合しません。

C：Kinesis Data Streamsは、リアルタイムストリーミングデータの処理に特化したサービスです。単純な注文有無の通知という要件に対して、ストリーミング処理の仕組みを導入するのは明らかに過剰設計（オーバーエンジニアリング）です。Kinesisの設定、シャード管理、データ保持期間の設定など、追加の運用負荷が発生し、実装コストも大幅に増加します。この要件には不適切な技術選択です。

D：Kinesis Data Streamsの導入に加えて、新しいLambda関数の作成、ストリーム処理ロジックの実装、エラーハンドリングの設定など、非常に多くの実装が必要になります。この方法は最も実装コストが高く、単純な通知要件に対して極めて複雑なアーキテクチャを構築することになります。また、Kinesisの継続的な運用コストも発生するため、コスト効率の面でも問題があります。

DVA-C02の特徴

実践的なシナリオベースの出題です。単にAWSサービスの機能を理解しておくだけでは点数を取ることは難しいです。どのような要件で各AWSサービスを用いればよいのかを説明できるように力をつけておくことが大切です。

本問題集の特徴

• DVA-C02の出題形式に沿った本番ライクな問題

• 全問題に詳細な解説とAWS公式ドキュメントへのリンクを記載

• 不正解選択肢の理由についての解説