AWS Certified Developer - Associate
Associate / ベンダー資格(AWS)
どんな試験か
AWS上でクラウドネイティブなアプリケーションを開発・デプロイ・デバッグできることを証明する資格です。Lambda、DynamoDB、API Gateway、SAMなど開発者向けサービスの実装知識を問われます。
出題傾向
AWSサービスによる開発 32%
セキュリティ 26%
デプロイメント 24%
トラブルシューティングと最適化 18%
公式試験ガイド(DVA-C02)に基づく出題比率。1000点満点中720点が合格基準。
サンプル問題（3問）
公式の過去問は非公開のため、DVA-C02の出題傾向に沿った例題を掲載しています。AWS公式の「Exam Prep Official Practice Question Set」(AWS Skill Builderで無料)も活用できます。
問1
Lambda関数からRDS for MySQLに接続するアプリケーションを開発している。秒間数百回のLambda実行で、DB接続数が上限に達する問題が発生した。コード変更を最小限にとどめつつ問題を解消するには、どの方法が最も適切か。
A. Lambdaの予約済み同時実行数を1に設定して直列化する
B. RDS Proxyを導入し、Lambdaから RDS Proxy 経由でRDSに接続する
C. RDSのインスタンスタイプを大きくする
D. Lambdaのメモリサイズを最大値まで増やす
B. RDS Proxyを導入し、Lambdaから RDS Proxy 経由でRDSに接続する
C. RDSのインスタンスタイプを大きくする
D. Lambdaのメモリサイズを最大値まで増やす
答えを見る
正解：B
Lambdaは並列実行されるたびにDB接続を作るため、急激なスケールでDB接続数が枯渇する典型的な問題です。RDS Proxyはコネクションプールとして機能し、複数のLambda実行で接続を共有・再利用できます。Lambda側はDB接続先のエンドポイントをRDS ProxyのものにするだけでOKでコード変更は最小限。 Aは並列度を1にするとスループットが極端に下がります。Cはmax_connectionsが上がっても根本解決にはならず、コストも増加。DはCPUに比例してメモリも増えますが本問の原因ではありません。
Lambdaは並列実行されるたびにDB接続を作るため、急激なスケールでDB接続数が枯渇する典型的な問題です。RDS Proxyはコネクションプールとして機能し、複数のLambda実行で接続を共有・再利用できます。Lambda側はDB接続先のエンドポイントをRDS ProxyのものにするだけでOKでコード変更は最小限。 Aは並列度を1にするとスループットが極端に下がります。Cはmax_connectionsが上がっても根本解決にはならず、コストも増加。DはCPUに比例してメモリも増えますが本問の原因ではありません。
問2
DynamoDBのテーブルに対する書き込み量が想定を大きく超え、ProvisionedThroughputExceededExceptionが頻発している。コードはAWS SDKの標準設定を使っている。アプリケーション側で対処する第一手として最も適切なものはどれか。
A. SDKの標準動作である指数バックオフ付きリトライ(exponential backoff)が機能しているか確認し、必要なら再試行回数を増やす
B. テーブルを削除して作り直す
C. すべての書き込みをSQSにキューイングしてからEC2でバッチ処理する
D. グローバルセカンダリインデックス(GSI)を全カラムに追加する
B. テーブルを削除して作り直す
C. すべての書き込みをSQSにキューイングしてからEC2でバッチ処理する
D. グローバルセカンダリインデックス(GSI)を全カラムに追加する
答えを見る
正解：A
ProvisionedThroughputExceededExceptionは「スループットが瞬間的に超過した」ことを示すスロットリングエラーで、AWS SDKは標準で指数バックオフ付きリトライが組み込まれています。まずは設定の確認と再試行回数の調整が第一手です。根本対応としてはオンデマンドキャパシティへの切り替えやキャパシティの引き上げが選択肢に入ります。 Bは破壊的すぎる対処でデータも失われます。Cはアーキテクチャの大幅変更が必要。Dは書き込み量を増やすだけで逆効果(GSIへの書き込みもキャパシティを消費)。
ProvisionedThroughputExceededExceptionは「スループットが瞬間的に超過した」ことを示すスロットリングエラーで、AWS SDKは標準で指数バックオフ付きリトライが組み込まれています。まずは設定の確認と再試行回数の調整が第一手です。根本対応としてはオンデマンドキャパシティへの切り替えやキャパシティの引き上げが選択肢に入ります。 Bは破壊的すぎる対処でデータも失われます。Cはアーキテクチャの大幅変更が必要。Dは書き込み量を増やすだけで逆効果(GSIへの書き込みもキャパシティを消費)。
問3
CloudFormationでステージングと本番の2環境を管理している。同じテンプレートを使いつつ、環境ごとにインスタンスタイプを変えたい。最も標準的な実装方法はどれか。
A. 環境ごとに別のテンプレートファイルを用意する
B. テンプレートに Parameters セクションを定義し、デプロイ時にパラメータで環境別の値を渡す
C. デプロイ前にスクリプトでテンプレートを書き換える
D. 1つのスタックに両環境のリソースを全部定義する
B. テンプレートに Parameters セクションを定義し、デプロイ時にパラメータで環境別の値を渡す
C. デプロイ前にスクリプトでテンプレートを書き換える
D. 1つのスタックに両環境のリソースを全部定義する
答えを見る
正解：B
CloudFormationのParametersセクションは「デプロイ時に環境別の値を注入する」ための標準機能です。同じテンプレートを保ちつつ、aws cloudformation deployコマンドの--parameter-overridesで環境別の値を渡せます。 Aは同じ意図のテンプレートが2つに分裂しメンテナンス性が下がります。Cは原始的な方法で再現性・差分管理が困難。Dは環境分離の原則に反します。Mappings や Conditions も併用できますが、本問の「インスタンスタイプを変える」程度の差ならParametersで十分です。
CloudFormationのParametersセクションは「デプロイ時に環境別の値を注入する」ための標準機能です。同じテンプレートを保ちつつ、aws cloudformation deployコマンドの--parameter-overridesで環境別の値を渡せます。 Aは同じ意図のテンプレートが2つに分裂しメンテナンス性が下がります。Cは原始的な方法で再現性・差分管理が困難。Dは環境分離の原則に反します。Mappings や Conditions も併用できますが、本問の「インスタンスタイプを変える」程度の差ならParametersで十分です。
向いている人
・AWS上で実装を行う開発者
・Solutions Architect Associateと並行で取得を目指す方
・サーバーレス開発を学びたい方
学習リソース
公式
AWS認定公式サイト AWS Skill Builder (公式学習プラットフォーム) 問題集
AWS認定デベロッパー-アソシエイト問題集 講座
Udemy AWS認定デベロッパー-アソシエイト試験突破講座