AWS Certified Developer - Associate (DVA-C02) #15 フルスケール模擬試験 — 50 問 + 解説
読了 19分
#1 から #14 までの整理が頭に入っているかを確認する段階です。実際の試験と同じドメイン比重で 50 問 を解きます。
解き方 #
- 90~100 分 以内に解いてみます (実際の試験は 65 問/130 分ですが、本模擬試験は 50 問基準)。
- 1 問ずつすぐに解説を見ず、最後まで解いてから採点します。
- 36 問 (72%) 以上 正解すれば安全な合格圏です。
- 不足しているドメインが見えたら、該当の記事に戻って整理し直します。
ドメイン分布 #
| ドメイン | 問題数 | 範囲 |
|---|---|---|
| Domain 1 — 開発 (32%) | 16 | Q1 ~ Q16 |
| Domain 2 — セキュリティ (26%) | 13 | Q17 ~ Q29 |
| Domain 3 — デプロイ (24%) | 12 | Q30 ~ Q41 |
| Domain 4 — トラブルシューティングと最適化 (18%) | 9 | Q42 ~ Q50 |
Domain 1 — AWS サービスで開発 #
Q1. API Gateway が同期で呼び出した Lambda がエラーを投げた。Lambda の再試行動作は?
解説
同期呼び出しでは Lambda は再試行しません。再試行するかどうかは呼び出し元 (API Gateway/クライアント) が決めます。自動 2 回再試行と DLQ は非同期呼び出しの動作です。
Q2. S3 イベントで非同期呼び出しされた Lambda がすべての再試行後も失敗した。イベントを失わないようにするには?
解説
非同期呼び出しの失敗イベントは DLQ (Dead Letter Queue) または Destination に保管します。Destination は成功・失敗の両方をルーティングできるため推奨されます。同時実行・メモリ・プロビジョニング済み同時実行は処理性能のオプションにすぎず、失敗イベントを保存できません。
Q3. Lambda 関数の初回呼び出しのレスポンスが遅い (コールドスタート)。遅延を減らす最も適切な方法は?
解説
コールドスタートを解消するのはプロビジョニング済み同時実行です。予約済み同時実行は数量の確保/制限であり、コールドスタートの解消ではありません。
Q4. ある Lambda 関数がアカウント全体の同時実行を使い切り、他の関数がスロットリングされる。分離するには?
解説
予約済み同時実行は特定の関数に同時実行の取り分を確保し、上限も定めることで、ある関数の暴走から他の関数を守ります。
Q5. コストと遅延が最も重要で、単純な Lambda プロキシバックエンドだけが必要だ。適切な API Gateway は?
解説
HTTP API は REST API より約 70% 安く遅延が低いです。API キー・キャッシング・リクエスト検証が不要なら HTTP API が適しています。REST API は使用量プラン・キャッシングなどの高度な機能向け、WebSocket API は双方向のリアルタイム通信向け、Private REST API は VPC 内部専用です。
Q6. 顧客ティア別に月間 API 呼び出しの割り当てを設けたい。適切なものは?
解説
使用量プラン + API キーは REST API 専用機能で、顧客ティア別の呼び出し上限・割り当てを適用します。API キーは認証ではなく、識別・計量の手段です。Lambda オーソライザー・JWT (JSON Web Token) オーソライザーは認証・認可を処理するだけで、呼び出しの割り当てを提供しません。
Q7. プロキシ統合された Lambda を呼び出すと API Gateway が 502 Bad Gateway を返す。原因は?
解説
プロキシ統合で Lambda が
statusCode・body 形式を守らないと 502 が出ます。形式を合わせれば解決します。同時実行の超過は 429、CORS (Cross-Origin Resource Sharing) の未設定はブラウザ側のブロックであり、502 の原因ではありません。Q8. DynamoDB テーブルでパーティションキー以外の属性で頻繁に照会する必要がある。テーブルはすでに運用中だ。適切なものは?
解説
キー以外の属性での照会にはインデックスが必要で、運用中のテーブルには LSI (Local Secondary Index) を追加できないため (作成時のみ) GSI (Global Secondary Index) を追加します。Scan は全件スキャンのため非効率です。
Q9. 2 つのクライアントが同時に同じ DynamoDB 項目を修正し、上書きの競合が発生する。防ぐには?
解説
楽観的ロックは version 属性と条件付き書き込みで実装します。「自分が読んだバージョンと同じときのみ更新」という条件で、競合時には一方だけが成功します。強い整合性の読み取りは最新値を読むだけで同時書き込みの競合を防げず、アトミックカウンターは増減の累積用、TTL (Time To Live) は自動期限切れ削除用です。
Q10. 同じ注文 ID でリクエストが 2 回入っても項目を 1 回だけ作成したい。適切なものは?
解説
attribute_not_exists 条件付き書き込みは項目が存在しないときのみ作成するため、冪等な作成になります。アトミックカウンターは増減用であり、Scan 後の分岐は競合状態に弱く、強い整合性の読み取りは重複作成を防げません。Q11. DynamoDB に新しい項目が追加されると自動的に通知を送る後処理を付けたい。適切なものは?
解説
項目の変更に反応するには DynamoDB Streams を Lambda のイベントソースとして接続します。DAX は読み取りキャッシュ、TTL (Time To Live) は自動期限切れ削除にすぎず、変更イベントを発生させません。
Q12. 注文は受けた順に、重複なく正確に 1 回処理されなければならない。適切なものは?
解説
順序保証と重複排除 (正確に 1 回) は SQS FIFO (First In First Out) キューです。標準キューは at-least-once であり順序を保証しません。SNS は発行・購読、EventBridge はイベントルーティング用で、いずれも順序・重複排除を保証しません。
Q13. 1 つの注文イベントを決済・通知・分析システムがそれぞれ独立して、耐久性をもって処理する必要がある。適切なものは?
解説
SNS + SQS ファンアウトは一度発行したイベントを複数のキューへ届け、各消費者が自分のペースでバッファリング・再試行しながら独立して処理します。1 つの SQS に 3 つの消費者を置くとメッセージを分け合うため各自が全体を受け取れず、SNS のみを使うと消費者側のバッファリング・再試行の耐久性が不足します。
Q14. 毎日深夜に整理作業を実行する Lambda をトリガーしたい。適切なものは?
解説
定められた時刻・周期での実行は EventBridge スケジュールルール (旧 CloudWatch Events) です。SQS 遅延キューはメッセージの配信を少し遅らせるだけで、定められた時刻の cron 実行ではなく、DynamoDB Streams は項目の変更イベント用です。
Q15. リスト API を呼び出したが結果が一部しか返ってこない。最も可能性の高い原因は?
解説
AWS のリスト API は結果をページに分けてトークン (NextToken など) を返します。最初のページだけ読むと一部しか返りません。権限不足は AccessDenied エラー、スロットリングは呼び出し制限エラーとして現れ、部分的な返却とは異なります。
Q16. ブラウザからサーバーを経由せずに S3 へ直接大きなファイルをアップロードさせつつ、クライアントに AWS キーを配布したくない。適切なものは?
解説
署名付き URL は一時的な署名 URL で、クライアントが認証情報なしに定められた時間だけ S3 へ直接アクセスできるようにします。
Domain 2 — セキュリティ #
Q17. モバイルアプリのユーザーがログイン後に S3 へ直接アップロードできるよう、一時的な AWS 認証情報を発行する必要がある。適切なものは?
解説
一時的な AWS 認証情報の発行は Identity Pool の役割です。User Pool は認証 (ログイン・JWT) までです。
Q18. Web アプリに会員登録・ログイン・JWT 発行が必要だ。適切なものは?
解説
ユーザーディレクトリと認証 (ログイン・JWT (JSON Web Token)) は User Pool です。Identity Pool は一時的な AWS 認証情報の発行用、STS (Security Token Service) GetSessionToken は既存の IAM プリンシパル用であり、会員登録・ログイン機能はありません。
Q19. EC2 で動作するアプリケーションが S3 にアクセスする必要がある。最も安全な方法は?
解説
EC2 に IAM Role を付与すると STS (Security Token Service) の一時的な認証情報が自動供給され、長期キーを保存する必要がありません。キーを保存する方式はすべて不正解です。
Q20. RDS データベースの認証情報を定期的に自動ローテーションする必要がある。適切なものは?
解説
自動ローテーション (rotation) の内蔵は Secrets Manager であり、RDS と統合されます。Parameter Store は自動ローテーションをデフォルトでは提供しません。
Q21. コストなしでアプリケーションの設定値を階層的なパスで保存・照会したい。適切なものは?
解説
Parameter Store の標準パラメータは無料で、
/app/db/host のような階層パスで設定値を管理します。Secrets Manager は自動ローテーションを提供しますが、シークレットごとに課金されるため、コストなしの設定保存には過剰です。Q22. S3 オブジェクトを誰がいつ復号したかを監査できるようにする必要がある。適切な暗号化は?
解説
SSE-KMS は KMS (Key Management Service) キーの使用を CloudTrail で監査できるため、「誰が復号したか」の追跡が可能です。SSE-S3 は AWS 管理キーで自動暗号化しますが、キー使用の監査ログがありません。
Q23. 数 GB のサイズのデータを KMS キーで暗号化したい。正しい方式は?
解説
KMS (Key Management Service) の直接暗号化は 4KB の上限があります。大きなデータはデータキーを受け取りローカルで暗号化するエンベロープ暗号化を使います。SSE-C はユーザーがキーを自分で提供・管理する方式で、KMS キーを使うシナリオとは異なります。
Q24. 別のアカウントのリソースをコードから制御する必要がある。適切な方法は?
解説
クロスアカウントアクセスの定石は STS (Security Token Service) AssumeRole です。対象アカウントに Role を作り、信頼ポリシーで呼び出し元アカウントを許可します。
Q25. Lambda 関数が DynamoDB テーブルに書き込む必要がある。権限を与える正しい方法は?
解説
Lambda は実行ロールの権限で動作します。ロールに必要な DynamoDB 権限を付与すればよいです。
Q26. 複数のポリシーが適用されており、そのうち一つに明示的な Deny がある。最終的な結果は?
解説
明示的な Deny はどの Allow よりも優先されます。一つでも Deny があれば最終的な結果は拒否です。
Q27. API Gateway でサードパーティの OAuth トークンを独自ロジックで検証してアクセスを制御する必要がある。適切なものは?
解説
カスタムトークン・サードパーティ OIDC (OpenID Connect) の検証ロジックは Lambda オーソライザーで実装します。認証関数が IAM ポリシーを返して許可/拒否を決定します。Cognito User Pool オーソライザーは Cognito が発行したトークン専用であり、IAM 認証は SigV4 署名、API キーは計量用であり、サードパーティのトークン検証には適しません。
Q28. Identity Pool で受け取った一時的な認証情報で、ユーザーが自分所有の S3 prefix にのみアクセスできるようにしたい。適切なものは?
解説
ポリシー変数でユーザー識別子をリソースパスに入れると、1 つのポリシーでユーザー別の prefix 分離を実装できます。
Q29. 転送中 (in transit) のデータを保護する TLS 証明書を発行・管理したい。適切なものは?
解説
転送中の暗号化に使う TLS/SSL 証明書の発行・更新・管理は ACM です。KMS は保存データのキー管理です。
Domain 3 — デプロイ #
Q30. ソースをコンパイル・テストしてデプロイアーティファクトを作る段階を担当するツールは?
解説
ビルド・テストでアーティファクトを生成するのは CodeBuild であり、定義は
buildspec.yml に置きます。CodeDeploy はデプロイの実行、CodePipeline は全段階のオーケストレーション、CodeArtifact はパッケージリポジトリを担当します。Q31. ビルド段階のコマンドと段階 (install/pre_build/build/post_build) を定義するファイルは?
解説
CodeBuild のビルド定義はソースルートの
buildspec.yml です。デプロイフックの定義は appspec です。Q32. 本番デプロイの前に人が確認して承認するようパイプラインを止めたい。適切なものは?
解説
パイプラインのステージ間に手動承認 (Manual Approval) アクションを入れると、人が承認するまで進行が止まります。appspec フックはデプロイ段階内のスクリプト実行用であり、人による承認ゲートではありません。
Q33. サーバーレスアプリケーション (Lambda + API Gateway + DynamoDB) を少ないコードで定義・デプロイしたい。適切なものは?
解説
SAM (Serverless Application Model) はサーバーレス専用の CloudFormation 拡張で、短縮リソースタイプでサーバーレスアプリを簡潔に定義・デプロイします。Elastic Beanstalk は EC2 ベースの Web アプリ向け PaaS (Platform as a Service)、OpsWorks は Chef・Puppet による構成管理、CodeArtifact はパッケージリポジトリです。
Q34. CloudFormation スタックを更新する前に、どのリソースがどう変わるかを事前確認したい。適切なものは?
解説
チェンジセットはスタック更新前に変更影響 (作成・修正・置き換え・削除) を事前に見せ、意図しない置き換えを防ぎます。ドリフト検出はコンソールなど外部から手動変更された実際の状態とテンプレートの差を確認する事後機能であり、更新前のプレビューとは異なります。
Q35. CloudFormation スタックを削除しても RDS データベースは保持したい。適切なものは?
解説
DeletionPolicy: Retain はスタック削除時に該当リソースを保持します。Snapshot は削除前にスナップショットを残します。Q36. Lambda をローカル環境で実行・デバッグしたい。適切なものは?
解説
sam local は Docker で Lambda・API をローカルで実行・デバッグします。X-Ray はデプロイ済み環境の分散トレーシングツールであり、ローカル実行ツールではありません。Q37. インフラ管理を気にせず Web アプリケーションを素早くデプロイしたい (EC2・ELB・ASG を自動構成)。適切なものは?
解説
Elastic Beanstalk はコードをアップロードすると EC2・ELB・ASG (Auto Scaling Group)・ヘルスモニタリングを自動構成する PaaS (Platform as a Service) です。SAM・Lambda はサーバーレス向け、Step Functions はワークフローのオーケストレーション向けであり、EC2 ベースの Web アプリの自動構成とは目的が異なります。
Q38. デプロイ失敗時に即座に以前のバージョンへ戻せて、かつダウンタイムがあってはならない。適切なデプロイ方式は?
解説
Blue/Green は新環境にデプロイ後トラフィックを切り替えるため無停止であり、問題が起きればトラフィックを戻して即座にロールバックします。
Q39. Lambda の新バージョンを最初はトラフィックの 10% のみに送り、問題なければ全体へ拡大したい。適切なものは?
解説
Lambda エイリアスは 2 つのバージョンへトラフィックを比率で分配でき、SAM (Serverless Application Model) の
DeploymentPreference (例: Canary10Percent5Minutes) で自動化します。Q40. 新バージョンのデプロイ後にエラー率がしきい値を超えたら自動的に以前のバージョンへ戻したい。適切なものは?
解説
CodeDeploy はデプロイ中に CloudWatch アラームが鳴ると自動ロールバックします。指標ベースの自動復帰の核心はアラーム連携です。
Q41. 社内の npm・pip 依存パッケージを安全にホスティング・共有し、外部リポジトリをキャッシュしたい。適切なものは?
解説
CodeArtifact は npm・pip・Maven などのマネージドパッケージリポジトリで、外部リポジトリのプロキシ・キャッシュと内部パッケージの共有を提供します。ECR はコンテナイメージのリポジトリ、CodeCommit は Git ソースリポジトリであり、依存パッケージのホスティング用途とは異なります。
Domain 4 — トラブルシューティングと最適化 #
Q42. 複数のマイクロサービスを経由するリクエストがどこで遅くなるか、ボトルネック区間を見つけたい。適切なものは?
解説
X-Ray はセグメント・サブセグメントでリクエスト経路を追跡し、サービスマップで遅延・エラーを可視化してボトルネックを見つけます。CloudTrail は API 呼び出しの監査、Config はリソース構成の変更追跡用であり、リクエスト経路のボトルネック分析には適しません。
Q43. EC2 インスタンスのメモリ使用率を CloudWatch でモニタリングしたい。適切なものは?
解説
CPU・ネットワークはデフォルト指標ですが、メモリ・ディスクはデフォルトで提供されないため CloudWatch Agent をインストールする必要があります。
Q44. サーバーレスで API 呼び出しのコストなしに、ログだけでカスタム指標を生成したい。適切なものは?
解説
EMF は構造化された JSON ログを書くと CloudWatch が自動的に指標を抽出し、追加の API 呼び出しなしにカスタム指標を作ります。PutMetricData をリクエストごとに呼び出すと、API コストとスロットリングのリスクが大きくなります。
Q45. 誰が特定の S3 バケットを削除したかを追跡する必要がある。適切なものは?
解説
API 呼び出しの主体・時点の監査 (「誰がどの API を呼んだか」) は CloudTrail です。CloudWatch Metrics は性能指標、X-Ray はリクエスト経路、Logs Insights はログのクエリツールであり、行為者の監査には適しません。
Q46. Lambda 関数が CPU バウンドの作業で遅い。直接 CPU を設定できないなら適切な対処は?
解説
Lambda はメモリのみ設定し CPU・ネットワークが比例します。CPU が不足すればメモリを上げます。
Q47. API Gateway 背後の作業が 30 秒を超えて 504 Gateway Timeout が発生する。適切な解決は?
解説
API Gateway の統合タイムアウトは最大 29 秒です。より長い作業は非同期パターンに変える必要があります。
Q48. DynamoDB のプロビジョニングモードのテーブルで
ProvisionedThroughputExceededException が頻発する。適切でない対応は?解説
強い整合性の読み取りはコストが 2 倍になりスロットリングを悪化させます。容量引き上げ・キー分散・指数バックオフが正しい対応です。
Q49. DynamoDB の読み取りレスポンスをマイクロ秒レベルまで下げたい。適切なものは?
解説
DynamoDB 専用のインメモリキャッシュである DAX が読み取りをマイクロ秒に下げます。汎用キャッシュの ElastiCache は別途キャッシュロジックが必要で、CloudFront はコンテンツ配信キャッシュ (CDN (Content Delivery Network))、読み取りレプリカは DynamoDB の概念ではありません。
Q50. スロットリング (429/ThrottlingException) に対応するクライアントの正しい再試行方式は?
解説
スロットリングは指数バックオフ + ジッターで再試行すべきで、AWS SDK がこれをデフォルトで内蔵しています。即座・固定間隔の再試行は負荷を増やします。
採点と締めくくり #
総合スコア
正解 0 / 0
回答 0 / 0
36 問 (72%) 以上であれば安全な合格圏です。間違えた問題は単に正解を覚えるのではなく、「制約キーワードが何で、なぜその選択肢が最適なのか」 を #14 の基準で説明できるようになるまで復習してください。特によく混同するペア (User Pool vs Identity Pool、Secrets Manager vs Parameter Store、SQS vs SNS vs EventBridge、502 vs 504) を最後まで確実にします。
シリーズを終えて #
#1 試験の紹介 から始めて、開発 (32%) → セキュリティ (26%) → デプロイ (24%) → トラブルシューティングと最適化 (18%) の 4 つのドメインを一巡し、試験戦略と模擬試験で締めくくりました。DVA-C02 は単なる暗記ではなく AWS サービスをコードでどう扱い、デプロイし、デバッグするか を問う試験だという点を覚えておけば、初めて見るシナリオにも揺らぎません。
DVA-C02 合格後は、運用視点の SysOps Administrator Associate (SOA-C02)、または設計をより深く扱う Solutions Architect Associate (SAA-C03) へとつながります。実務感覚がもっと必要なら、AWS 実務トラック 27 本 に戻ってコンソールとコードの上で直接動かしてみるのもよい復習です。合格を応援しています。