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回あたりの初期化コストは変わらない。むしろ正常処理まで失敗させるリスクがある

正解：C

A　初期化処理そのものは速くなるが、実行環境の新規作成に伴うコールドスタートは残る。集中アクセス時の初回遅延を確実には解消できない

B　いわゆるウォームアップだが、維持できる実行環境はごく少数で、同時に大量到達するバーストには対応できない。仕組みも自前運用になる

C（正解）　正解。事前に初期化済みの実行環境が確保される。Application Auto Scalingのスケジュールを併用すれば必要な時間帯だけ確保数を増やせるためコストも抑えられる

D　同時実行の枠を確保するだけで、実行環境の事前初期化は行われない。コールドスタートによる初回遅延は解消しない

正解：B

A　要件は満たすがリソース・メソッド・ステージ・デプロイの管理が必要になる。今回不要な機能のために構成要素が増える

B（正解）　正解。関数に組み込みのHTTPS(S)エンドポイントが1設定で払い出され、追加サービスなしでSigV4認証を強制できる

C　常時課金されるALBが必要になり、SigV4認証も標準では提供されない。単純なエンドポイント公開には重い

D　CloudFrontのオリジンにLambda関数を直接指定することはできない。関数URLやAPI Gatewayなどのエンドポイントを経由する必要がある

正解：D

A　初期化は速くなるがアプリケーション全体の書き換えが必要で、「大幅な書き換えを避けたい」という制約に反する

B　コールドスタートは解消できるが、確保している間は実行の有無にかかわらず課金される。常時課金を増やしたくないという条件に合わない

C　ウォームプールはAuto Scalingグループが初期化済みEC2インスタンスを停止やハイバネートの状態で待機させる仕組みで、実行環境をサービス側が管理するLambdaには適用できない

D（正解）　正解。初期化済みの実行環境スナップショットをキャッシュして復元するため、追加料金なしで起動時間を大幅に短縮できる。有効化はバージョンに対して行い、エイリアス経由で呼び出す

正解：A

A（正解）　正解。関数の応答で失敗したレコードのシーケンス番号を返す部分バッチレスポンスにより、失敗レコード以降のみが再試行の対象となり成功分のチェックポイントが進む

B　詰まりは解消するが、一時的なエラーで失敗したレコードもすべて捨てることになる。正常レコードを進めるという要件とは別の副作用が大きい

C　バッチは進むが、失敗の記録が一切残らずデータ欠落に気付けない。障害の可視性を失う悪い設計

D　ストリームに載る情報量が変わるだけで、バッチ失敗時の再試行挙動には影響しない。むしろ処理に必要な属性が取れなくなる

正解：C

A　GB秒あたりの単価はメモリ設定によって変わらない。安くなったのは単価ではなく消費したGB秒の総量

B　リクエスト課金はメモリ設定と無関係に発生する。そのような免除は存在しない

C（正解）　正解。8倍のメモリでも実行時間が8分の1未満になればGB秒は減る。CPUバウンドな処理ではメモリを上げるほうが安くなることがある

D　メモリ設定によってプロビジョニングされた同時実行が自動で有効になることはない。両者は独立した設定

正解：B

A　Lambdaの最大実行時間は15分で、60分に設定することはできない。前提が成立しない

B（正解）　正解。実行時間の上限がなく、タスク実行中のみ課金されるためアイドルコストが発生しない

C　実行できるがインスタンスが月のほとんどをアイドルで過ごし課金され続ける。パッチ適用などの運用負荷も増える

D　各ステップを15分以内に収める設計が必要で、40分の一体処理を分割できる保証がない。コンテナ化済みという前提も活かせない

正解：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　50本のポリシーを管理することになり、増減のたびに作成と削除が発生する。「本数を増やさずに」という要件に反する

B　規約は強制力がなく、他人のプレフィックスを操作できてしまう。最小権限の原則に反する

C（正解）　正解。Resourceに ${aws:username} を使うとリクエスト元のユーザー名に展開されるため、単一のポリシーで各自のプレフィックスに限定できる

D　タグは書き込み時に本人が任意に設定できるため、他人の名前を付ければ回避できる。プレフィックス分離の手段としては弱い

正解：B

A　aws:SourceVpcはVPCエンドポイント経由のアクセスに使う条件キーで、オフィスからのインターネット経由アクセスには適用されない

B（正解）　正解。aws:SourceIpで送信元IP範囲を、aws:SecureTransportがfalseの場合にDenyすることでHTTPS必須をそれぞれ表現できる

C　aws:RequestedRegionはリクエスト先リージョンの制限であり、通信の暗号化の有無とは無関係

D架空　aws:PrincipalOrgIDは組織メンバーであることの判定に使う条件キー。aws:TlsRequiredという条件キーは存在しない

正解：A

A（正解）　正解。IMDSv2はPUTでセッショントークンを取得してから使うため、単純なGETを誘発するタイプのSSRFでは認証情報を取得できない

B　長期認証情報をディスクに置くことになり、ファイル読み取り型の攻撃で同様に窃取される。むしろ悪化する

C　メタデータサービスへのアクセスはインスタンス内部のリンクローカル通信であり、セキュリティグループでは制御できない

D　外部からの直接到達は減るが、Webアプリが公開されている限りSSRFの経路は残る。メタデータの保護にはならない

正解：C

A　長期認証情報の利用を避けるという要件に反する。Secrets Managerに入れてもキー自体は長期のまま

B　呼び出し側の許可だけではクロスアカウントアクセスは成立しない。リソース側でも明示的に許可する必要があり、この設定だけではAccessDeniedExceptionになる

C（正解）　正解。返された一時認証情報でクライアントを初期化すれば、長期認証情報なしでクロスアカウントアクセスができる

D　ネットワーク到達性の話であり、DynamoDBのようなリージョンサービスへの認可は解決しない

正解：D

A　ロールの最大セッション時間の上限は12時間であり、24時間は設定できない。ロールチェーンの場合はさらに1時間に制限される

B　有効期限の問題は消えるが、長期認証情報の管理という別のリスクを抱え込む。設計の後退となる

C　処理内容によっては分割できず、根本的にはトークンの更新で解決すべき問題を回避しているにすぎない

D（正解）　正解。SDKのロール引き受け用プロバイダーは有効期限を追跡して自動的に更新するため、長時間の処理でも中断しない

正解：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バケットへ暗号化して保存され、後続アクションが入力アーティファクトとして取得する

正解：A

A（正解）　正解。承認されるまでパイプラインは待機し、承認・却下のアクションはIAMで制御できる

B　実現できるがパイプラインが分断され、どのビルド成果物がデプロイされるかの追跡が難しくなる

C　時間による待機であって承認ではない。誰が承認したかの記録も残らない

D　CodeDeployのフックは検証用のスクリプトや関数を実行する仕組みで、人による承認の待機を担うものではない

正解：C

A　ポーリング間隔は利用者が任意に短縮できる設定として提供されていない。仕組み自体を変えるべき

B　コミットがなくてもパイプラインが動き、無駄なビルドとコストが発生する。イベント駆動になっていない

C（正解）　正解。イベント駆動になることで遅延がほぼなくなり、無駄なポーリングも解消する。推奨される検出方法でもある

D　リポジトリを起点とした開発フローが壊れ、手作業が増える。改善ではなく後退

正解：B

A　置き換え用タスクセットの作成前に実行されるフックで、テストトラフィックはまだ流れていない

B（正解）　正解。テストリスナー経由でトラフィックが流れた後に実行されるため、この段階で検証を行い失敗ならデプロイを中止できる

C　本番リスナーの切り替え後に実行される。この時点では既に利用者へ影響が出ている

D　EC2やオンプレミス向けのインプレースデプロイで使われるフックで、ECSのappspecでは指定できない

正解：C

A　バッチ単位で既存インスタンスを更新するため、デプロイ中の容量が一時的に低下する

B　容量は維持できるが、既存インスタンスを順次更新するため新旧が混在し、切り戻しにも再デプロイが必要になる

C（正解）　正解。新しいインスタンス群を別のAuto Scalingグループに作成してから切り替えるため、混在せず容量も落ちない。失敗時は新規グループを破棄するだけで戻せる

D　全インスタンスを同時に更新するため、デプロイ中はサービスが停止する。最も高速だが可用性の要件を満たさない

正解：A

A（正解）　正解。新バージョンのインスタンスへ指定した割合のトラフィックを一定時間流し、健全性を確認してから全体へ移行するカナリアデプロイを行う

B　新旧の混在は防げるが、切り替えは一括で行われる。割合を指定した段階的な誘導はできない

C　インスタンスを順に更新するだけで、トラフィックの割合を制御する仕組みはない

D　全インスタンスを一斉に更新するため、段階的な誘導とは正反対の挙動になる

正解：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トレースあたりの情報量が減るだけで、トレース件数に基づく課金は変わらない

正解：C

A　保持期間に0日という設定はなく、既定は無期限。設定できる最短でも1日で、即座に消えるわけではない

B　メモリ不足であれば関数自体がエラーで終了する。正常完了しているという前提と矛盾する

C（正解）　正解。logs:CreateLogStreamやlogs:PutLogEventsも実行ロールの権限で行われるため、基本的な実行ロールポリシーが欠けているとログだけが出なくなる

D　Lambdaのログ出力は実行環境が担い、利用者のVPCの経路を通らない。VPC設定はログ欠落の原因にならない

正解：A

A（正解）　正解。パターンに一致したログ行をカウントするカスタムメトリクスが生成され、しきい値超過でSNSへ通知できる

B　手作業になり通知も自動化されない。夜間や休日の検知ができない

C　実現できるがカウントの集計と時間窓の管理を自作することになる。標準機能で済む要件には過剰

D　CloudTrailはAPI呼び出しの監査記録であり、アプリケーションが出力したログの内容は対象外

正解：D

A　関数の実行が終わると処理が打ち切られるため、送信が完了しない可能性がある。信頼性に欠ける

B　実現できるが中間テーブルと集計処理の運用が増える。標準の仕組みで代替できる

C　トレースの検索には使えるが、CloudWatchのメトリクスとしてアラームやダッシュボードに利用することはできない

D（正解）　正解。CloudWatch Logsが取り込む際にメトリクスを自動抽出するため、API呼び出しの待ち時間なしにカスタムメトリクスを記録できる

正解：C

A　収集間隔が5分から1分に短くなるだけで、取得できるメトリクスの種類は増えない

B　インスタンスタイプによって取得できる標準メトリクスの種類が変わるわけではない

C（正解）　正解。メモリやディスクの空き容量はゲストOS内部の情報のため、ハイパーバイザーからは観測できずエージェントによる収集が必要になる

D　ログの保存先を作るだけで、メトリクスの収集とは別の機能