Overview

更新履歴2025/3: 演習問題4 網羅性向上のため問題を追加しました。( +50問)2025/6: 演習問題1 , 2, 3 解説を大幅強化しました。演習1, 2, 3に関して古い傾向の問題を削除し、新しい傾向の問題に差し替えました。（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段階で構成されます：データ収集: 既存Lambda関数でのメトリクス送信監視・通知: CloudWatchアラームによる自動通知このアーキテクチャにより、コード変更を最小限に抑えながら、リアルタイムでの注文監視と迅速な通知が実現できます。正解選択肢の組み合わせは、実装の容易さ、運用コストの低さ、保守性の高さという3つの観点で最適解となります。Kinesis Data Streamsや追加Lambda関数を使用する方法は、要件に対して過剰な複雑性を導入するため、最小限の実装コストという条件に適合しません。参考資料（教材には公式ドキュメントへのリンクが記載されます。）Amazon CloudWatch メトリクスの概要:CloudWatchアラームの設定方法: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公式ドキュメントへのリンクを記載不正解選択肢の理由についての解説

Skills

Reviews