AWS DVA サンプル問題

正解：B

A　初期化済みの実行環境を事前に用意してコールドスタートを短縮する機能であり、本来の目的はレイテンシ改善。確保した数を超えるバーストは結局アカウント枠を奪い合ううえ、待機中も課金され続ける

B（正解）　正解。予約された同時実行はその関数専用の枠を切り出し、他の関数から消費されないよう隔離する

C　同時実行数は「実行中の呼び出し数」で決まるため多少は緩和されるが、処理が途中で打ち切られてレポートが壊れる。決済関数を保証する仕組みにはならない

D　1実行あたりの時間は短くなるが、同時実行数の枠そのものは変わらない。バースト時のスロットリングは解消しない

正解：D

A　初期化のたびにネットワーク取得と展開が走りコールドスタートが悪化する。S3の権限管理も追加で必要になり、運用はむしろ複雑になる

B　共有自体は可能だが、VPC設定・マウントターゲット・アクセスポイントの構成が必要でオーバーヘッドが大きい。単なる読み取り専用の依存ライブラリ配布には過剰

C　実現は可能だがイメージのビルドとECRへのプッシュが毎回必要で、ZIPパッケージのままレイヤーだけ差し替える方式より手順が多い

D（正解）　正解。レイヤーを新バージョンとして発行し関数の参照を更新するだけでよく、関数コードの再ビルドが不要になる。1関数あたり5レイヤーまで、解凍後合計250MBの制限内で使える

正解：C

A　呼び出し側の改修が必要になるという要件に反する。振り分けロジックを各クライアントに実装する運用負荷も高い

B　$LATESTは常に最新コードを指すため、デプロイした瞬間に100%のトラフィックが新コードに向かう。段階的な切り替えができない

C（正解）　正解。エイリアスの加重ルーティングは2つのバージョン間でトラフィックを割合分割でき、呼び出し側はエイリアスARNを参照したままでよい

D　予約された同時実行は同時実行数の上限を決める設定で、トラフィックの割合分割とは無関係。超過分はスロットリングされるだけで旧コードには流れない

正解：A

A（正解）　正解。バッチサイズを増やせば1回の呼び出しで複数メッセージを受け取れ、バッチウィンドウを設ければメッセージが溜まるまで待ってからまとめて起動できる

B　処理中のメッセージが他のコンシューマーに見えなくなる時間の設定で、1回の呼び出しで受け取るメッセージ数には影響しない。むしろ関数のタイムアウトに合わせて調整すべき値

C　順序保証と重複排除のための選択であり、呼び出し回数の削減が目的ではない。メッセージグループ単位の直列処理になり、かえってスループットが落ちる可能性がある

D　同時実行が1に絞られるだけで呼び出し回数は変わらない。キューが滞留して処理遅延が深刻化し、接続コストの問題も解決しない

正解：C

A　メモリとCPUは増えるが、/tmpの容量はメモリ設定とは独立したエフェメラルストレージの設定で決まる。ディスク不足は解消しない

B　デプロイパッケージが展開される領域と、書き込み可能な一時領域は別枠。パッケージを小さくしても書き込み可能容量は増えない

C（正解）　正解。/tmpの容量は関数設定で512MBから10240MBまで構成でき、確保した容量に応じた課金が発生する

D　実行時間の上限を延ばすだけで、ディスク容量とは無関係。同じ場所で容量不足エラーになる

正解：B

A　1回あたりの処理量が減るだけで並列度は上がらない。呼び出し回数が増えてオーバーヘッドが増し、遅延はさらに悪化する

B（正解）　正解。1シャードに対して最大10個のバッチを同時処理でき、同一パーティションキーのレコードは同じバッチ処理系に送られるため順序は保たれる

C　同時実行の上限を4に固定するだけで、既定でもシャードあたり1バッチずつ処理されている。並列度は上がらない

D　各コンシューマーに専用のスループットと低レイテンシ配信を提供する機能で、読み取り帯域の競合には効くが、この関数の処理並列度そのものは変わらない

正解：D

A　失敗したイベント本文は退避できるが、DLQに入るのは元のペイロードのみで、エラー内容や応答の詳細は含まれない。要件の半分しか満たさない

B　関数が起動できずに失敗するケースや初期化エラーを捕捉できない。ログからペイロードを再投入する運用も手作業になる

C　非同期呼び出しにはイベントソースマッピングが存在しない。この設定はSQSやKinesisなどのポーリング型ソースに対するもので、Event呼び出しには適用されない

D（正解）　正解。宛先に送られるレコードにはリクエストID・エラー内容・元のペイロードを含む呼び出しレコードが格納され、DLQより多くの情報が得られる

正解：A

A（正解）　正解。初期化コードは実行環境が再利用される限り再実行されないため、以降の呼び出しでは接続確立のオーバーヘッドを回避できる

B　接続オブジェクトはシリアライズして復元できるものではなく、ファイルI/Oが増えるだけ。設計として成立しない

C　環境変数は文字列しか保持できず、接続やクライアントインスタンスを渡す手段ではない。設定値の受け渡し用途にとどまる

D　遅い実行を失敗させるだけで、1回あたりの初期化コストは変わらない。むしろ正常処理まで失敗させるリスクがある

正解：B・D

A　説明が逆。後から追加・削除できるのはGSIのほうで、LSIはテーブル作成時にのみ定義できる

B（正解）　正解。GSIはベーステーブルから非同期にレプリケートされるため、書き込み直後の読み取りが古い値を返すことがある。強い整合性が必要ならベーステーブルかLSIを使う

C　専用キャパシティを持つのはGSIのほう。LSIはベーステーブルのキャパシティを消費するため、別途プロビジョニングする対象ではない

D（正解）　正解。同じパーティション内での並べ替え軸を増やす仕組みであり、パーティションキーそのものを変えたい場合はGSIを使う

E　10GBの制約はLSIを持つテーブルのほうに存在する。GSIは独立したテーブルとして管理されるためこの上限はない

正解：A・C・F

A（正解）　正解。初期化フェーズで一度だけ走り、その環境が再利用される間は再実行されない。SDKクライアントや設定の読み込みをここに置く根拠になる

B　Lambdaは直後の呼び出しに備えて実行環境を一定時間保持し再利用する。毎回破棄されるなら初期化コードをハンドラー外に置く最適化自体が成立しない

C（正解）　正解。/tmp は実行環境に紐づくため内容が残る。キャッシュとして活用できる反面、残留ファイルを前提にしない実装と、機密データを残さない配慮が必要になる

D　実行環境は関数のバージョン単位で分離されており、別の関数と共有されることはない。関数をまたぐ情報漏えいを心配する必要はない

E　ハンドラーが結果を返した時点で実行環境は凍結され、未完了の非同期処理はそのまま止まる。次の呼び出しで解凍された際に予期しないタイミングで再開するため、ハンドラー内で完了を待つ必要がある

F（正解）　正解。実行環境が再利用されると前回の値がそのまま残るため、ユーザー固有の情報をグローバルに置くと別のリクエストから読み取られる不具合になり得る。再利用されるかどうかはLambda側の判断で、コードからは制御できない

正解：D

A　ユーザープールが発行するのはJWTであり、S3はSigV4署名を要求する。JWTを直接付けてもS3にはアクセスできない

B　サインインの概念がなく全員が同じゲストロールになるため、ユーザー専用フォルダを分離できない

C　IAMユーザーはアプリケーションのエンドユーザー管理に使うものではなく、数万人規模ではクォータも運用も破綻する

D（正解）　正解。ユーザープールが認証、アイデンティティプールが認可（AWS認証情報の払い出し）を担う役割分担が基本形となる

正解：B

A　ユーザーが増えるたびにポリシーの更新が必要で、バケットポリシーのサイズ上限にもすぐ達する

B（正解）　正解。Resourceに ${cognito-identity.amazonaws.com:sub} を書くとリクエストごとにそのユーザーのアイデンティティIDへ展開され、1つのロールで自分専用プレフィックスに限定できる

C　クライアント側の検証は改ざんできるため、認可の強制力がない。認証情報を持つ以上バケット全体を操作できてしまう

D　ACLの被付与者はAWSアカウントや定義済みグループで、Cognitoのアイデンティティを直接指定できない。オブジェクト作成後の設定になる点も要件に合わない

正解：A

A（正解）　正解。Authorizationヘッダーで送られたトークンをAPI Gatewayが検証し、クレームはリクエストコンテキストのauthorizer経由でLambdaへ渡される

B　実現できるがJWKSの取得と署名検証を自作することになり、標準のオーソライザーがある以上カスタムコードが無駄に増える

C　認可はできるが、渡されるのはIAMのプリンシパル情報であり、ユーザープールのクレームをそのまま利用する形にはならない

D　APIキーは呼び出し元の識別と従量管理のための仕組みで、認証手段ではない。ユーザー認証の代替にしてはならない

正解：C

A　スコープに基づいてユーザープールのAPI操作やリソースサーバーへの認可に使うトークン。ユーザーの属性クレームは基本的に含まれない

B　有効期限が切れた他のトークンを再取得するためのもので、それ自体にユーザー属性の情報は持たない

C（正解）　正解。OpenID Connectで定義される認証結果を表すトークンで、subやemailなどのユーザー属性クレームを含む

D　STSの一時認証情報に含まれる要素の名称であり、Cognitoユーザープールが発行する3種類のトークンには含まれない

正解：B

A　バケット全体が誰にでも公開され、アクセス元の制御も監査もできなくなる。要件を満たす最小権限の構成ではない

B（正解）　正解。ゲストにもスコープを絞った一時認証情報を払い出せ、認証済みロールとは別のポリシーを適用できる

C　長期認証情報の配布であり抽出されるリスクが高い。ゲストと認証済みの権限分離もできない

D　全ゲストが同一の資格情報を共有することになり、パスワード管理と失効の運用が破綻する。標準の非認証アイデンティティを使うべき

正解：C

A　SaaS側の送信元IPが固定である保証がなく、変更のたびに更新が必要になる。混乱した代理問題への標準的な対策でもない

B　認証情報の露出期間は短くなるが、誰が引き受けられるかという問題は解決しない

C（正解）　正解。外部IDは混乱した代理問題を防ぐための仕組みで、値を知らない第三者はロールを引き受けられない

D　長期認証情報を社外に渡すことになりローテーションも困難。クロスアカウントアクセスはロールで行うのが原則

正解：A

A（正解）　正解。IAMのポリシー評価ロジックでは、どのポリシーであっても明示的なDenyがあれば他のAllowを上書きして拒否となる

B　アイデンティティベースポリシーがリソースベースポリシーより優先されるという規則はない。評価は両方を合わせて行われる

C　ポリシーの更新日時が評価に影響することはない。もっともらしいが誤り

D　同一アカウントではどちらかのAllowで許可されうるという性質はあるが、明示的なDenyは常に評価される

正解：D

A　実行ロールは関数自身が他サービスを呼ぶための権限であり、S3から呼ばれる側の可否には関与しない

B　S3イベントによる起動にVPC配置は不要。むしろVPC配置はS3への到達経路の話であり、起動の可否とは別

C　確かに同一リージョンである必要があるが、その場合はイベント通知の設定自体が作成時に失敗する

D（正解）　正解。他サービスから関数を呼ばせるには、関数側のリソースベースポリシーで s3.amazonaws.com からの lambda:InvokeFunction を許可する必要がある。コンソール経由の設定では自動付与されるが、手動やIaCでは明示が必要

正解：C

A　人の判断に依存するため夜間や休日の異常に即応できない。自動ロールバックという要件を満たさない

B　段階的な切り替えはできるが、監視と切り戻しがすべて手作業になる。自動化の要件に届かない

C（正解）　正解。指定した割合と待機時間でエイリアスの加重を自動制御し、関連付けたCloudWatchアラームが発報すれば即座に旧バージョンへ戻す

D　実行環境の事前確保数の設定であり、トラフィックの配分やロールバックとは無関係

正解：B

A　トラフィックを新バージョンへ移した後に実行されるフック。事前検証には使えず、失敗を検知したときには既に利用者に影響が出ている

B（正解）　正解。トラフィック移行前に実行される検証用フックで、指定したLambda関数がFailedを返すとデプロイは中止されロールバックされる

C　EC2やオンプレミス向けのデプロイで使われるフックで、Lambdaのデプロイでは利用できない

D　EC2やECSのデプロイで使われるフック。Lambdaのappspecで指定できるフックは2種類のみ

正解：D

A　1台ずつ更新するため処理能力が徐々に落ち、切り戻しも再デプロイになるため即座には戻せない

B　全台を同時に更新するためデプロイ中に処理能力が失われる。失敗時の影響も最大となる

C　半数ずつ更新するため処理能力が半減し、切り戻しにも同じ時間がかかる

D（正解）　正解。新旧の環境が並行して存在するため能力を落とさず、切り戻しはロードバランサーの向き先を戻すだけで完了する

正解：A

A（正解）　正解。cacheのpathsにnode_modulesなどを指定すればビルド間で依存関係を再利用でき、変更がない限りダウンロードをスキップできる

B　CPUとメモリは増えるがダウンロードはネットワーク待ちが支配的で、時間短縮の効果は限定的。単価も上がる

C　打ち切られる時間が延びるだけで所要時間は変わらない。むしろ問題を放置する対処

D　依存関係が導入されずビルドが失敗する。所要時間の削減にはなっても成果物が得られない

正解：C

A　リポジトリを閲覧できる全員にトークンが見えてしまう。最も避けるべき保存場所

B　プロジェクト設定やビルドログで値が露出しうる。平文で書きたくないという要件に反する

C（正解）　正解。envのsecrets-managerやparameter-storeで参照すると、値はビルドサービスロールの権限で実行時に取得され、定義にはキー名だけが残る

D　イメージを取得できる者に読まれるうえ、ローテーションのたびにイメージの再作成が必要になる

正解：B

A　CodeBuildの送信元IPは固定されず、データベースを公開する時点で要件に反する

B（正解）　正解。ビルドコンテナがVPC内にENIを持ち、プライベートなリソースへ到達できる。外部通信が必要ならNATゲートウェイを併用する

C　IAMの許可があってもネットワーク経路がなければ接続できない。到達性の問題は解決しない

D　VPCに接続していないビルド環境の通信はVPC外から来るため、セキュリティグループでの許可対象にならない

正解：D

A　EFSの共有は不要。CodePipelineは成果物の受け渡しを標準機能として提供する

B　成果物は永続化されるストアに保存される。メモリ上で受け渡す仕組みではない

C　CodeArtifactはパッケージ管理のためのサービスで、パイプラインの入出力アーティファクトの保管先ではない

D（正解）　正解。アクションの出力アーティファクトがアーティファクトストアのS3バケットへ暗号化して保存され、後続アクションが入力アーティファクトとして取得する

正解：B

A　関数全体の実行時間はわかるが、その内訳がDynamoDBなのか外部APIなのかを切り分けられない

B（正解）　正解。呼び出し先ごとのサブセグメントで所要時間が分解され、どのダウンストリームが遅延の原因かを特定できる

C　アプリが出力した情報しか分析できず、外部呼び出しの内訳を得るには計測コードの実装が別途必要になる

D　誰がいつ管理操作を行ったかの監査記録であり、リクエストごとの処理時間の内訳は取得できない

正解：C

A　メタデータはトレースに保存されるがインデックス化されないため、フィルタ式による検索の対象にならない

B　セグメント名が顧客ごとに増えてサービスマップが破綻する。カーディナリティの高い値を名前に入れるのは不適切

C（正解）　正解。アノテーションはインデックス化されるため、コンソールのフィルタ式で annotation.customerId = "..." のように検索できる

D　サンプリングルールは記録する割合を決めるもので、個々のトレースに検索可能な属性を付ける仕組みではない

正解：A

A（正解）　正解。EC2やECSではSDKがUDPでデーモンへセグメントを送るため、デーモンの稼働が前提となる。Lambdaでは実行環境に組み込まれているため不要

B　awsvpcはFargateでも標準的に使われるモードで、トレースの送信を妨げるものではない

C　既定のルールでも毎秒1件は必ず記録される。まったく表示されない状況の説明にならない

D　アプリが動作していない状況であればトレース以前にサービスが提供されない。前提と矛盾する

正解：D

A　関数が正常終了している時点でタイムアウトには達していない。トレース欠落の説明にならない

B　VPC配置の有無はトレースの送信可否に影響しない。Lambdaのトレース送信は実行環境が担う

C　既定のサンプリングでも一定量は記録されるため、まったく出ない状況の主因としては考えにくい

D（正解）　正解。トレースの送信は関数の実行ロールの権限で行われるため、xray:PutTraceSegmentsとxray:PutTelemetryRecordsを含むAWSXRayDaemonWriteAccess相当の許可が必要になる

正解：B

A　無効化した区間のトレースが欠落し、サービスマップが分断されて調査の役に立たなくなる

B（正解）　正解。毎秒の最低記録件数とそれを超える分の割合を指定でき、パスやサービス名ごとに異なるルールを適用できる

C　X-Rayのトレース保持期間は利用者が任意に設定するものではなく、記録件数に応じた課金も変わらない

D　1トレースあたりの情報量が減るだけで、トレース件数に基づく課金は変わらない