AWS DVAのサンプル問題（本番形式・解説付き）

AWS DVA（Amazon Web Services・AWS Certified Developer – Associate（DVA-C02））の出題形式を、実際の問題で確かめられます。ここに掲載する5問は、無料の会員登録で解ける模試第1回（65問）の冒頭から抜粋したオリジナル問題です。当サイトは全925問を本番CBT準拠の形式で収録しており、この5問はそのごく一部にあたります。

設問1

ある会社は、IoT機器から届くデータを、Amazon Kinesis Data Streamsのプロビジョンドモードで受け取る計画を立てている。データは1件0.5KBのレコードで、毎秒3,500件書き込まれる見込みである。書き込みの上限だけで考えるとき、必要なシャードはいくつか。

7シャードが要る。
4シャードが要る。（正解）
2シャードが要る。
1シャードが要る。

解説

1シャードの書き込みは、毎秒1MBまたは毎秒1,000レコードまで受けられる。データ量は3,500×0.5KB=1,750KBで約1.75MB/秒なので2シャードで足りるが、件数は3,500件/秒で4シャードが要る。両方を満たす多い方の4が答えになる。7シャードは3,500件を500件ずつに分けた値で、1シャードの上限の毎秒1,000レコードを使い切っていない。1シャードや2シャードでは件数の上限を超える。

設問2

ある開発者が、AWS STSから受け取った一時的なセキュリティ認証情報を、AWS SDKを使わない独自のツールに設定しようとしている。STSから発行される一時的な認証情報に通常含まれる要素の組み合わせとして正しいものはどれか。

アクセスキーIDとシークレットアクセスキーの2つ（長期的なIAMユーザーの認証情報と同じ構成で、有効期限だけが付く）
ユーザー名とパスワードの2つ（マネジメントコンソールへのサインインで使う情報と同じ組み合わせ）
アクセスキーID、シークレットアクセスキー、セッショントークンの3つ（正解）
APIキーとシークレットの2つで、発行された値の組み合わせをリクエストヘッダーに添えて送る

解説

STSが発行する一時的なセキュリティ認証情報には、アクセスキーID・シークレットアクセスキーに加えて、セッショントークン（SessionToken）が含まれます。APIリクエストの署名にはこの3つ全てが必要です。長期的なIAMユーザーのアクセスキーにはセッショントークンは存在しません。

他の選択肢が誤りである理由

「アクセスキーIDとシークレットアクセスキーの2つ（長期的なIAMユーザーの認証情報と同じ構成で、有効期限だけが付く）」長期的なIAMユーザーのアクセスキーはこの2つですが、一時的な認証情報にはセッショントークンも含まれます。
「ユーザー名とパスワードの2つ（マネジメントコンソールへのサインインで使う情報と同じ組み合わせ）」IAMのプログラムアクセスにはユーザー名とパスワードではなく、アクセスキーの仕組みが使われます。
「APIキーとシークレットの2つで、発行された値の組み合わせをリクエストヘッダーに添えて送る」AWSのAPI認証は「APIキー」という用語ではなく、アクセスキーID／シークレットアクセスキー（＋セッショントークン）の仕組みを使います。

設問3

ある開発チームは、サーバーレスのバッチ処理をAWS Lambdaで実装している。デプロイの仕組みを作る前に、コードと依存関係をどのような形に固めて配ればよいかを決めたい。選べる形式の組み合わせとして正しいものはどれか。

コンテナイメージで固める形式と、AppConfigのホスト型ストアに置く形式の2つから選ぶ。
Elastic Beanstalkのソースバンドルと、SSMドキュメントに登録する形式の2つから選ぶ。
.zipで固める形式と、CloudFormationのテンプレートで固める形式の2つから選ぶ。
.zipで固める形式と、コンテナイメージで固める形式の2つから選ぶ。（正解）

解説

Lambdaのパッケージングでは、コードと依存を.zipかコンテナイメージに固める。CloudFormationのテンプレートはインフラを宣言するIaCの記述であり、AppConfigのホスト型ストアは設定データの保管先、Elastic Beanstalkのソースバンドルは別サービスのアプリケーションバージョンの形で、どれもLambdaの成果物の形式ではない。

設問4

ある開発チームは、AWS SDKを使ってAmazon DynamoDBやAmazon S3のAPIを呼び出すアプリケーションを作っている。一時的なネットワークエラーやスロットリングエラーに対するリトライ処理について、チーム内で「全部自分たちで書く必要がある」という意見が出た。リトライ処理は、開発者がゼロから実装しなければならないか。

はい。AWS SDKにはリトライ機能が内蔵されておらず、自前で実装する必要がある
いいえ。リトライはAWS側のサーバーで自動的に行われ、クライアント側のSDKでは待機時間や再試行回数を設定できない
はい。ただしAPI Gatewayを経由する呼び出しでは、API Gateway側がリトライを肩代わりする
いいえ。AWS SDKには、再試行可能なエラーに対する指数バックオフを含むリトライ機構がデフォルトで組み込まれており、最大リトライ回数などは設定でカスタマイズもできる（正解）

解説

AWS SDKには、スロットリングや一時的なサーバーエラーなど再試行可能なエラーに対して、指数バックオフを用いた自動リトライの仕組みがデフォルトで組み込まれています。最大リトライ回数やリトライモードは設定でカスタマイズ可能です。AWS SDKにはデフォルトのリトライ機構が組み込まれており、ゼロから自前実装する必要はありません。リトライはクライアント側（SDK）の挙動であり、サーバー側だけで自動的に行われるものではありません。設定のカスタマイズもクライアント側で可能です。リトライ機構はAPI Gatewayに限定されたものではなく、SDKを通じた多くのAWSサービス呼び出しに共通する仕組みです。

他の選択肢が誤りである理由

「はい。AWS SDKにはリトライ機能が内蔵されておらず、自前で実装する必要がある」AWS SDKにはデフォルトのリトライ機構が組み込まれており、ゼロから自前実装する必要はありません。
「いいえ。リトライはAWS側のサーバーで自動的に行われ、クライアント側のSDKでは待機時間や再試行回数を設定できない」リトライはクライアント側（SDK）の挙動であり、サーバー側だけで自動的に行われるものではありません。設定のカスタマイズもクライアント側で可能です。
「はい。ただしAPI Gatewayを経由する呼び出しでは、API Gateway側がリトライを肩代わりする」リトライ機構はAPI Gatewayに限定されたものではなく、SDKを通じた多くのAWSサービス呼び出しに共通する仕組みです。

設問5

ある会社が、購買申請の処理をAWS Step Functionsのステートマシンで自動化している。一定額を超える申請は、上長が社内の承認画面でボタンを押すまで先に進めてはならず、承認には数日かかることもある。開発者は、承認が完了するまでステートマシンの実行を一時停止させ、承認画面のシステムからの通知を受けて再開させたい。最も適した仕組みはどれか。

Waitステートに固定の待機時間を設定し、承認されていなくても時間経過で次に進める。例えば24時間を待機時間として指定しておき、経過後は承認済みとみなして後続処理へ進む構成にして、承認の記録は別途手作業で残す
「Wait for Callback（.waitForTaskToken）」パターンを使い、タスクトークンを外部システムに渡し、承認されたらSendTaskSuccessでステートマシンを再開させる（正解）
Choiceステートで承認の有無を判定し、外部システムからの通知が来るまでステートマシンを同じ判定に戻して待たせる
Parallelステートで承認処理と後続処理を同時に実行し、外部システムからの通知で後続処理を再開させる

解説

「Wait for Callback（.waitForTaskToken）」パターンでは、ステートマシンがタスクトークンを発行して外部システム（承認システムなど）に渡し、そのトークンを使ってSendTaskSuccessまたはSendTaskFailureが呼ばれるまで実行を一時停止します。人間の承認のような外部要因を待つユースケースに適しています。固定の待機時間で次に進めてしまうと、実際に承認されたかどうかに関係なく処理が進んでしまい、要件を満たしません。Choiceステートは条件分岐を行うだけで、外部からの通知を待って実行を一時停止させる仕組みは持たず、判定を繰り返すと実行が無駄に回り続けます。Parallelステートで後続処理を承認と同時に実行してしまうと、承認前に後続処理が進んでしまい、要件（承認を待ってから進める）に反します。

他の選択肢が誤りである理由

「Waitステートに固定の待機時間を設定し、承認されていなくても時間経過で次に進める。例えば24時間を待機時間として指定しておき、経過後は承認済みとみなして後続処理へ進む構成にして、承認の記録は別途手作業で残す」固定の待機時間で次に進めてしまうと、実際に承認されたかどうかに関係なく処理が進んでしまい、要件を満たしません。
「Choiceステートで承認の有無を判定し、外部システムからの通知が来るまでステートマシンを同じ判定に戻して待たせる」Choiceステートは条件分岐を行うだけで、外部からの通知を待って実行を一時停止させる仕組みは持たず、判定を繰り返すと実行が無駄に回り続けます。
「Parallelステートで承認処理と後続処理を同時に実行し、外部システムからの通知で後続処理を再開させる」Parallelステートで後続処理を承認と同時に実行してしまうと、承認前に後続処理が進んでしまい、要件（承認を待ってから進める）に反します。

続きは、会員登録なしでそのまま50問解けます。採点と解説つきで、上と同じ本物の問題です。

登録なしで50問解く

← AWS DVA の資格ページへ