AWS DEA サンプル問題

正解：B

A　スループット（12MB/秒 ÷ 1MB/秒）だけを見た値。シャードには1秒あたり1,000レコードという書き込み回数の上限もあり、20,000レコード/秒はこの数では処理しきれない

B（正解）　正解。シャードあたりの書き込み上限は1MB/秒かつ1,000レコード/秒。データ量では12、レコード数では20が必要となり、大きい方の20が最小値になる

C　12と20を足した値だが、2つの上限は同時に適用される独立した制約であり、加算するものではない。過剰プロビジョニングとなりシャード時間の無駄なコストが発生する

D　PutRecordsによるバッチ送信はAPI呼び出し回数を減らすだけで、シャード側で数えられるレコード数やバイト数は変わらない。集約を使ってもシャードの帯域上限1MB/秒は超えられない

正解：C

A　要件は満たせるが、コンシューマアプリの実装・デプロイ・スケーリング・チェックポイント管理をすべて自前で運用することになり「運用を最小化したい」に反する

B　小さなオブジェクトが大量に生成され、変換までのバッチ遅延も1時間になる。2分以内という要件を満たさない

C（正解）　正解。Firehoseはフルマネージドでバッファリング、Parquet/ORCへのレコード形式変換、動的パーティショニングを標準機能として提供し、コンシューマコードが不要

D　SQSはメッセージキューであり、ファイルサイズを揃えたバッファリングやParquet変換の機能を持たない。Lambda側で集約ロジックを実装する必要があり複雑になる

正解：A

A（正解）　正解。同一パーティションキーのレコードは同じシャードに入り、シャード内では取り込み順が保持される。センサー単位の順序が保証され、センサーIDが多数あればシャード間に分散もできる

B　スループットは均等になるが、同一センサーのレコードが複数シャードに散らばるため順序が保証されない。順序要件を犠牲にした選択

C　全体の順序は保証できるが、書き込みが1MB/秒・1,000レコード/秒に制限されスケールしない。センサー間の順序は不要なので過剰な制約

D　タイムスタンプをキーにすると同時刻のレコードが同一シャードに集中してホットシャードを招く。加えてシャードをまたいだ再ソートは順序保証にならず、バッファリングの複雑さも増す

正解：D

A　偏りの原因であるパーティションキーの分布は変わらないため、ホットシャードは解消しない。使われないシャードのコストだけが増える

B　エラー時の再送は緩和策にすぎず、スループット不足そのものは解決しない。遅延が増え、バックログが蓄積する

C　保持期間は書き込み済みレコードを保管する期間であり、書き込み側のスロットリングとは無関係。エラーは減らない

D（正解）　正解。オンデマンドモードはトラフィックに応じてシャードを自動で調整し、ホットパーティションも内部的に分割される。容量計画が不要になる

正解：B

A　標準コンシューマではシャードあたりGetRecordsは1秒5回までという制限があり、3つのアプリで共有するとかえってスロットリングが増える

B（正解）　正解。拡張ファンアウトはコンシューマごとにシャードあたり2MB/秒の専用帯域を割り当て、HTTP/2プッシュにより約70ミリ秒で配信する

C　動作はするが書き込みコストとシャード数が3倍になり、プロデューサー側の実装も複雑化する。拡張ファンアウトで解決できる問題に対して非効率

D　標準コンシューマの2MB/秒はシャード単位で全コンシューマが共有するため、シャードを増やしても1つのシャードを3アプリで分け合う構図は変わらない

正解：C

A　DynamoDBへの書き込みが増えてスループットが大幅に低下する。加えて処理後チェックポイント前のクラッシュは依然として起こりうるため、重複はゼロにならない

B　再処理できる範囲が狭まるだけで、クラッシュ時の再送そのものは防げない。むしろ障害復旧の余地を失う

C（正解）　正解。Kinesisは少なくとも1回の配信であり重複を前提に設計する。一意キーによる条件付き書き込みやUPSERTで、同じレコードが再処理されても結果が変わらないようにする

D　拡張ファンアウトは読み取り帯域とレイテンシを改善する機能で、配信セマンティクスは変わらない。重複配信は依然として発生する

正解：A

A（正解）　正解。Kinesis Data Streamsの保持期間はデフォルト24時間で、最大365日まで延長できる。延長分は追加課金されるが、コンポーネントを増やさず過去データを再読み取りできる

B　保持期間はシャード数と無関係のストリーム単位の設定。シャードを増やしてもデータが保持される期間は変わらない

C　TRIM_HORIZONで読めるのは保持期間内のデータのみ。デフォルト24時間のままでは30日はさかのぼれず、通常運用でも毎回全件再処理になってしまう

D　実現は可能だが「追加のコンポーネントを増やさない」という条件に反する。再処理の入り口も変わるため下流の実装変更が必要になる

正解：D

A　Firehose経由のRedshift配信も内部的にはS3に中間ファイルを置いてCOPYするため小ファイル問題は残る。加えて分析基盤の変更は要件に含まれていない

B　Lambda変換はバッファ内のレコードを加工する仕組みで、バッファそのものを大きくしない限り出力ファイルサイズは増えない。処理コストが増えるだけ

C　1ファイルあたりの容量は減るがファイル数は変わらない。小ファイルが多いことによるAthenaのオブジェクト一覧取得とタスク起動のオーバーヘッドは解消しない

D（正解）　正解。Firehoseはバッファサイズかバッファ間隔のどちらかが先に閾値へ達した時点でフラッシュする。許容遅延の範囲で両方を引き上げれば、出力ファイルが大きくまとまる

正解：B

A　テナントが増えるたびにストリームとプロデューサーのルーティング設定を追加する必要があり、運用が破綻する。ストリーム数のクォータにも抵触しやすい

B（正解）　正解。動的パーティショニングはレコード内容からパーティションキーを抽出し、配信先プレフィックスを動的に組み立てる機能。コードを書かずに実現できる

C　実現はできるがコピーによるストレージとリクエストの二重コスト、Lambdaの実装と失敗時のリカバリが必要になり、標準機能を使うより明らかに手間が大きい

D　ライフサイクルはストレージクラス移行と有効期限切れを扱う機能で、オブジェクトのキー（プレフィックス）を変更する機能はない

正解：C

A　Firehoseは設定された回数だけ再試行した後に諦める。無限リトライは行わず、後続のレコードが滞留し続けることもない

B　メトリクスは記録されるが、レコード自体が失われるわけではない。バックアップ先が設定されていれば実データが保全される

C（正解）　正解。Firehoseは変換失敗レコードをエラー出力プレフィックスに保存する。ソースレコードのバックアップを有効にすれば変換前の生データもS3に残せる

D架空　Firehoseにデッドレターストリームという概念はない。失敗レコードの退避先はS3のエラープレフィックスであり、Kinesisへ戻す仕組みは存在しない

正解：A

A（正解）　正解。MSKはオープンソースのKafkaをそのまま実行するマネージドサービスで、Kafka APIとコンシューマグループの挙動が互換。ブートストラップサーバーの向き先変更だけで移行できることが多い

B　概念は似ているがAPIは互換ではなく、コンシューマグループの代わりにKCLとDynamoDBのリース管理を使う。アプリの書き換えが必須になる

C　SQSは1メッセージを1コンシューマが消費して削除するキューであり、複数のコンシューマグループが同じデータを独立して読むというKafkaのモデルを再現できない

D　SNSはプッシュ型のパブサブで、オフセットを指定した過去データの再読み取りができない。Kafkaのログ保持モデルとは根本的に異なる

正解：C

A　機能的には正しいが、ワーカーのスケーリング、パッチ適用、可用性確保をすべて自前で運用することになる。マネージドな選択肢がある場面では過剰な負荷

B　MSKをLambdaのイベントソースにはできるが、ファイルのバッファリングやフォーマット変換を自分で書く必要があり「コードを書かずに」という条件に反する

C（正解）　正解。MSK ConnectはKafka Connectのマネージド実行環境で、コネクタの設定だけでS3へのシンクが可能。ワーカーの自動スケーリングも設定できる

D　DMSはKafkaをターゲットとしてサポートするが、ソースとして指定することはできない。方向が逆であり構成できない

正解：D

A　夜間のアイドル時間もブローカー料金が発生し続ける。変動が極端なワークロードではコスト効率が非常に悪い

B　MSKクラスターにはEC2のような停止機能がなく、ブローカー単位で日次に落として起こす運用はできない。実現不可能な前提に立っている

C　ティアードストレージは古いログセグメントを安価な階層に移してストレージコストを下げる機能。コンピュート側のサイジング問題は解決しない

D（正解）　正解。MSK Serverlessはブローカーやストレージの容量計画が不要で、スループットに応じて自動でスケールし使用量に対して課金される

正解：B

A　実現できるがクライアント証明書の発行・配布・失効というPKI運用が必要になる。「証明書の運用を避けたい」という方針に反する

B（正解）　正解。MSKのIAMアクセスコントロールはSASL/OAUTHBEARERベースの認証とIAMポリシーによる認可を組み合わせ、証明書運用なしにトピック単位の制御ができる

C　証明書は不要になるが、ユーザーごとのパスワード管理とローテーション、Kafka ACLの個別設定が必要でIAM統合より運用が煩雑

D　ネットワークレベルの到達制御であり、トピック単位の読み書き権限という粒度の認可は表現できない

正解：C

A　エクスポート開始から切り替えまでの更新が失われる。データ量が大きいほど停止時間が長くなり、数分という要件を満たせない

B　フルロード中に発生した変更が反映されないため、切り替え時にデータの欠損が生じる。継続的な更新があるシステムでは使えない

C（正解）　正解。異種DB間のためSCTでスキーマとストアドコードを変換し、DMSのフルロード＋CDCで差分を追い続けることで切り替え時の停止を最小化できる

D　DataSyncはファイルストレージ間の転送サービスで、Oracleのデータファイルをそのまま別エンジンのAuroraに接続することはできない

正解：A・B・C

A（正解）　正解。ロード中は1行挿入するたびにインデックスの更新と参照整合性のチェックが走る。移行が終わってからまとめて作成する方が全体では圧倒的に速い

B（正解）　正解。挿入のたびにトリガーの処理が実行されると1行あたりのコストが跳ね上がる。移行完了後に有効化し、必要であれば差分を後から計算する

C（正解）　正解。既定では限られた数のテーブルしか同時にロードされない。並列数を上げ、単一の巨大なテーブルは行の範囲で分割して並列ロードすることでレプリケーションインスタンスの能力を使い切れる

D　ソースとターゲットの行を突き合わせる処理が追加で動くため、移行そのものはむしろ遅くなる。移行結果の正しさを確認する用途には有用だが高速化策ではない

E　完全LOBモードはサイズ上限のないLOBを1件ずつ転送するため最も低速になる。性能を優先する場合は上限付きLOBモードで最大サイズを指定する

F　フルロードはCPU・メモリ・ネットワークを消費する。インスタンスを小さくすると同時に処理できる量が減り、さらに遅くなる

正解：B・C

A　スループットとコンシューマの並列度を上げるための設定。複製されていないパーティションをいくら増やしても、そのパーティションを保持するブローカーが失われればデータは失われる

B（正解）　正解。各パーティションが3つのブローカーに複製されるため、1つのブローカーが失われても残りのレプリカからデータを読み出せる。3つのアベイラビリティーゾーンに分散したクラスターではゾーン障害にも耐えられる

C（正解）　正解。プロデューサーがacks=allを指定したとき、書き込みを成功とみなすために同期済みレプリカが最低2つ必要になる。複製が追いついていない状態で成功を返してしまう（＝直後の障害で失われる）ことを防げる

D　同じキーの最新の値だけを残すログコンパクションの設定で、古いレコードはむしろ削除される。障害時の複製とは無関係

E　保存と転送のデータ量を減らす設定。ディスク使用量とネットワーク帯域には効果があるが、レプリカが存在しなければ障害時にデータは失われる

正解：C

A　列指向のMPPデータウェアハウスで大規模な集計に強いが、単一行の高頻度な読み書きは苦手。一桁ミリ秒の応答も想定されていない

B　分析用途には適するがオブジェクトストレージであり、単一レコードの更新や一桁ミリ秒の応答には向かない。クエリのたびにスキャンが発生する

C（正解）　正解。キーによる一桁ミリ秒のアクセスと高いスループットを提供し、項目ごとに属性が異なるスキーマレスな設計にも対応する

D　リレーショナルな整合性は得られるが、毎秒数万件の書き込みには垂直スケールの限界があり、カテゴリごとに異なる属性は列の増加やJSON型の多用を招く

正解：B

A　行がラウンドロビンで均等分散されるため、結合のたびにノード間で大量のデータ再分散（リディストリビューション）が発生する

B（正解）　正解。結合キーを分散キーにすると同じ値の行が同一スライスに配置され、ノード間のデータ移動なしでローカルに結合できる

C　全ノードに全行を複製するため、10億行のファクトテーブルではストレージが爆発的に増え、ロードも極端に遅くなる。大きなテーブルには使えない

D　分散キーが結合キーと一致しないため、結合のたびに再分散が必要になる。日付での分散はデータ量の偏りも招きやすい

正解：A

A（正解）　正解。小さなディメンションテーブルを全ノードに複製することで、どのスライスでもローカルに結合できる。数MB程度ならストレージのオーバーヘッドも小さい

B　均等分散されるが結合のたびにブロードキャストや再分散が発生する。小さなテーブルであれば複製しておく方が効率的

C　ファクトテーブル側の分散キーと一致しない限り再分散が起きる。複数のファクトテーブルと結合する場合はすべてに合わせられない

D　毎回S3へのアクセスが発生し、頻繁に結合されるマスタとしてはレイテンシが不利。小さなテーブルをローカルに持たない理由がない

正解：D

A　分散キーはノード間のデータ配置を決めるもので、ブロック単位のスキップには直接寄与しない。日付での分散は特定ノードへの偏りも招く

B　Redshiftには一般的なB-treeインデックスという概念がない。ブロックのゾーンマップとソートキーがその役割を担う

C　Redshiftのローカルテーブルにパーティションという構文はない。パーティションはSpectrumの外部テーブルやデータレイク側の概念

D（正解）　正解。ソートキー順に格納されるとブロックごとの最小値・最大値を記録したゾーンマップが有効に働き、範囲外のブロックを読み飛ばせる

正解：C

A　複合ソートキーは先頭列でのフィルタに強く効くが、2番目以降の列だけで絞り込むクエリには効果が薄い。混在する条件には偏った性能になる

B　AUTOはワークロードに応じてRedshiftが調整するが、複数列を等しく扱う保証はない。要件が明確な場面では明示的な設計の方が確実

C（正解）　正解。インターリーブソートキーは各列に均等な重みを与えるため、どの列単独のフィルタでも同程度の効果が得られる。ただしVACUUM REINDEXの負荷は増える

D　DISTKEYはテーブルにつき1列しか指定できない。複数指定という前提が成立しない

正解：B

A　圧縮で多少は削減できるが、ほとんど参照されない8年分に対してクラスターストレージの単価を払い続けることになる

B（正解）　正解。コールドデータを安価なS3に置きつつ、Spectrumによりローカルテーブルと同じSQLで結合・UNIONできる。スキャンした分だけの課金になる

C　分析のたびにクラスターの復元が必要で、数時間の準備時間がかかる。同じSQLでシームレスに分析するという要件を満たさない

D　DynamoDBはキーアクセス向けでスキャン中心の分析には不向き。ストレージ単価もS3より高く、コスト面でも不利

正解：A

A（正解）　正解。待ち行列が発生した際に一時的なクラスターを自動追加して読み取りクエリを処理する。使用した分だけの課金で、ピーク時だけ能力を拡張できる

B　1日の大半が過剰な容量となり、コスト効率が悪い。ピークが短時間である場合は特に無駄が大きい

C　同時実行数を増やしてもクラスターの物理リソースは変わらないため、1クエリあたりのメモリが減って個々の実行が遅くなることが多い

D　定型的な集計には有効だが、アドホックなクエリには適用できず、ビューの更新負荷も別途発生する。同時実行の逼迫そのものへの対処にはならない

正解：C

A　権限は実行可否を制御するもので、リソースの配分やクエリの優先度には関係しない。ETLが実行できなくなるだけ

B　同時実行は減るが個々のBIクエリはETLの後ろで待たされたままになる。応答時間の改善につながらない

C（正解）　正解。WLMはキューごとに同時実行数やメモリ配分を制御でき、自動WLMではクエリ優先度によって短時間クエリを優先的に処理できる

D　ETLの処理内容そのものを変えてしまい、データが不完全になる。リソース競合の解決方法として成立していない

正解：D

A　結果キャッシュは同一クエリの再実行に有効だが、テーブルが更新されると無効化され、パラメータが異なるクエリには効かない。安定した改善にはならない

B　フィルタの効率は上がるが、集計そのものは毎回10億行を走査する。事前計算による改善には及ばない

C　実装と無効化の管理をダッシュボードごとに行うことになり、重複した仕組みが増える。データベース側の機能で解決できる

D（正解）　正解。マテリアライズドビューは集計結果を実体として保持し、クエリを高速化する。自動リフレッシュや増分リフレッシュにより更新の運用も軽い

正解：B

A　単一ファイルは1つのスライスからしか読み込めず、クラスターの並列性がまったく活かされない。最も遅いロード方法になる

B（正解）　正解。COPYは複数ファイルを全スライスで並列に読み込む。スライス数の倍数に分割すると負荷が均等になり、ロードが最も高速になる

C　単一行INSERTの繰り返しは列指向ストレージに対して極めて非効率で、COPYと比べて桁違いに遅い。避けるべき方法

D　実現はできるが、S3からRedshiftへの一括ロードにはCOPYが最適化されている。DMSを挟むと余計なレプリケーションインスタンスのコストと変換処理が増える

正解：A

A（正解）　正解。Redshiftは自動VACUUMと自動ANALYZEを備えるが、大量更新の直後など必要なタイミングで明示的に実行することもできる

B　役割が逆。VACUUMが領域回収とソート、ANALYZEが統計情報の更新を行う

C　VACUUMとANALYZEで回復できる。作り直しは権限やビューの再設定が必要になり、対処として過剰

D　自動テーブル最適化はソートキーや分散キーの設計を見直す機能で、削除済み行の領域回収や統計情報の更新までは肩代わりしない。役割が異なる

正解：C

A　データが最大1日古くなり、復元のたびに時間とストレージが必要。実質的にコピーを作っており要件に反する

B　Redshift内のローカルテーブルは参照できないため、分析対象が限定される。ワークロード分離の手段としては制約が大きい

C（正解）　正解。データ共有はデータを複製せずに別のクラスターやサーバーレスから読み取りアクセスを提供し、コンピュートを完全に分離できる

D　影響は減るが同じクラスターのリソースを共有し続けるため完全な分離にはならない。分析チームの生産性も大きく損なわれる

正解：D

A　利用していない時間帯もノード料金が発生し続ける。週に数回の利用ではアイドル時間の割合が圧倒的に大きい

B　一時停止でコンピュート料金は止まるが、起動・停止の自動化とサイジングの判断は依然として必要。管理を避けたい要件に完全には合わない

C　復元に時間がかかり、手順も煩雑。復元漏れや削除漏れによる事故のリスクもある

D（正解）　正解。Serverlessはクラスター管理が不要で、クエリ実行時のみRPU単位で課金される。断続的な利用パターンに最も適する

正解：B

A　誰がいつジョブを起動したかは分かるが、ジョブ内部で発生した例外の内容は記録されない。API監査とアプリケーションログは役割が異なる

B（正解）　正解。Glueはジョブ実行ごとに出力ログとエラーログをCloudWatch Logsへ送る。エラーログにはPythonやSparkの例外とスタックトレースが記録される

C　リソース設定の変更履歴は分かるが、実行時の失敗理由は記録されない。設定変更が原因かを補助的に調べる材料にとどまる

D　接続性の問題を疑う場合の二次的な調査材料。まずアプリケーションレベルの例外内容を確認するのが順序として正しい

正解：C

A　ストリームへの流入量を示す指標で、書き込み側の状況は分かるがコンシューマが追いつけているかは判断できない

B　書き込み側のスロットリングを示す指標。プロデューサー側の容量不足を検知するもので、消費の遅れとは別の問題

C（正解）　正解。読み取ったレコードがストリームに書き込まれてからの経過時間を示す。この値が増え続けていればコンシューマが流入に追いついていない

D　読み取ったデータ量を示す指標で、絶対量からは遅れの有無を判断できない。流入量との比較も時間軸のずれを直接は表さない

正解：A

A（正解）　正解。実行計画で想定される処理と、システムビューに記録された実測値を突き合わせることで、再分散やディスクベースの処理といったボトルネックを特定できる

B　クラスター全体の負荷は分かるが、特定クエリのどのステップが遅いかは特定できない。原因の切り分けには粒度が粗すぎる

C　調査ではなく当てずっぽうの対処。原因が分散キーの不一致や統計情報の陳腐化であれば、ノードを増やしても改善しない

D　CloudTrailはAPI呼び出しの記録であり、Redshift内部で実行されたSQLのステップ別実行統計は含まれない

正解：D

A　セルフサービス分析の価値を損なう。過剰な制限で本来の目的が達成できなくなる

B　事後の通知であり、既に発生した高額なスキャンは止められない。予防的な統制になっていない

C　バケットポリシーにリクエスト数の上限を設ける仕組みはない。仮に制限してもクエリ失敗という形でしか現れず制御として不適切

D（正解）　正解。ワークグループのデータ使用量制御でクエリ単位のスキャン上限を設けると、閾値を超えたクエリは自動的にキャンセルされる。部門別のコスト可視化も同時に実現できる

正解：B

A　誤操作による終了を防ぐ設定で、ステップ完了後の自動終了やログの保全とは直接関係しない。調査のためにクラスターを残し続けるのはコスト面でも非効率

B（正解）　正解。ログのアーカイブ先を指定するとステップ、YARNアプリケーション、各ノードのログがS3に保存され、クラスター終了後も調査できる

C　クラスターが稼働中なら有効だが、終了後はノード自体が存在しないため接続できない。事後調査の手段にならない

D　ステップの投入や終了といったAPI操作は記録されるが、アプリケーションが出力したエラーの詳細は含まれない

正解：C

A　フルロードフェーズの行スループットを示す指標。CDCフェーズの遅延を表すものではない

B　レプリケーションインスタンスの空きメモリを示す指標。リソース逼迫の兆候にはなるが、遅延そのものの大きさは表さない

C（正解）　正解。ソースからの読み取り遅延とターゲットへの適用遅延をそれぞれ秒単位で示す。どちらの側がボトルネックかも切り分けられる

D　インスタンスの負荷は分かるが、遅延の秒数は分からない。高負荷でなくてもターゲット側の適用が遅ければ遅延は増える

正解：A

A（正解）　正解。データの鮮度というビジネス上のSLAを直接メトリクス化して監視できる。ジョブの成否だけでなく「時刻までに終わったか」を判定できる

B　ジョブが失敗せずに単に遅延している場合を検知できない。SLA違反の多くは失敗ではなく遅延として現れる

C　人手に依存し、休日や担当者の不在時に検知が漏れる。自動化できる監視を手作業で行う理由がない

D　利用の有無は分かるが、データが所定の時刻までに揃ったかどうかは判断できない。ログの反映にも遅延がある

正解：B

A　実現できるがエクスポートのスケジュール、テーブル定義、パーティション管理が必要で、障害時の即時調査には手順が重い

B（正解）　正解。Logs Insightsは複数のロググループを横断して構造化クエリを実行でき、フィルタ、集計、可視化を追加設定なしで行える

C　特定パターンの発生回数を追うには有効だが、任意のキーワードでの探索的な検索には向かない。事前にフィルタを定義しておく必要がある

D　検索は容易になるが、サービスごとの保持期間や権限を分けられなくなる。Logs Insightsの横断検索で十分に対応できる

正解：C

A　実行時間の上限を延ばすだけで、既に失敗したジョブの再実行にはならない。エラーの種類と対策が一致していない

B　処理量に応じてワーカー数を増減させる機能で、失敗したジョブが自動的に再実行されるわけではない。一時的なネットワークエラーへの対処にもならない

C（正解）　正解。Glueのジョブ定義には再試行回数の設定があり、失敗時に指定回数まで自動的に再実行される。一時的な障害への標準的な対処

D　処理済みデータをスキップして増分処理する機能で、失敗時の自動再実行とは別の目的。再試行の代わりにはならない

正解：D

A　Storage LensはS3のストレージを分析する機能で、Redshiftのローカルストレージの内訳は分からない

B　クラスター全体の使用率は分かるが、テーブル単位の内訳には分解できない。原因の特定には別の情報源が必要

C　クエリ単位の実行時間や頻度は分かるが、どのテーブルがストレージを占有しているかは示さない。症状の観測であって原因の特定にはならない

D（正解）　正解。SVV_TABLE_INFOはテーブル単位のブロック数、分散スキュー、未ソート行の割合を示す。VACUUM対象や分散設計の見直し対象も同時に判断できる

正解：B

A　ブローカーへの流入量を示す指標で、コンシューマ側の処理状況は分からない。負荷の把握には使えるが遅れの検知には不十分

B（正解）　正解。最新のオフセットとコンシューマのコミット位置との差を示し、消費がどれだけ遅れているかを直接表す。拡張モニタリングで取得できる

C　ブローカーのディスク使用率を示す指標。消費が遅れると間接的に増える傾向はあるが、遅れの大きさを表す直接的な指標ではない

D　クラスターのコントローラーが正常に1つ存在するかを示す指標で、クラスターの健全性確認に使う。消費の遅れとは無関係

正解：B

A　運用は最も簡単だが、キーポリシーによるアクセス制御ができず、キーの使用履歴を個別に監査することもできない。両方の要件を満たさない

B（正解）　正解。キーポリシーとIAMポリシーで復号権限を制御でき、KMSのAPI呼び出しがCloudTrailに記録されるため誰がいつ復号したかを追跡できる

C　リクエストごとにキーを渡す方式で、キーの保管と配布が自社責任になる。IAMによる制御やKMSの監査ログの恩恵も受けられない

D　キー管理をすべて自前で行うことになり、運用負荷が最も高い。KMSと組み合わせない限り監査も困難になる

正解：C

A　保管時の暗号化を保証する設定であり、通信路が暗号化されているかどうかとは別の話。転送中の保護にはならない

B　パブリック公開を防ぐ重要な設定だが、認証された利用者がHTTPで接続することは防げない

C（正解）　正解。この条件キーはリクエストがHTTPSかどうかを表す。falseのときに明示的に拒否すれば、暗号化されていない通信を確実に遮断できる

D　インターネットを経由しなくなるが、エンドポイント経由でもHTTPでの接続自体は成立しうる。プロトコルの強制にはならない

正解：A

A（正解）　正解。Kinesisはサーバーサイド暗号化に対応し、KMSのカスタマー管理キーを指定できる。キーポリシーで読み書きできるプリンシパルを制御できる

B　Base64は符号化であって暗号化ではない。誰でも復元できるため保護にならない

C　Kinesisはリージョンサービスでサブネットに配置するものではない。ネットワークの閉域化は保管時の暗号化とも別問題

D　S3上のデータは守られるが、ストリーム内に保持されている間は平文のまま。要件は取り込み経路での保管時暗号化

正解：D

A　スクリプトを閲覧できる全員に認証情報が露出する。バージョン管理システムにも平文で残り続ける最悪の選択

B　ジョブ定義を参照できる利用者やAPIから平文で読めてしまう。CloudTrailのログに残る可能性もある

C　バケットポリシーで保護はできるが、ローテーションの仕組みがなく、誤った権限設定で漏洩するリスクが残る

D（正解）　正解。Secrets Managerは暗号化された保管、IAMによるアクセス制御、自動ローテーション、CloudTrailによる取得履歴の記録をすべて提供する

正解：B

A　再暗号化は不要。KMSは過去のキーマテリアルを保持し続け、古い暗号文はそのまま復号できる

B（正解）　正解。キーIDやARNは変わらず、新規の暗号化には新しいマテリアルが使われる。古い暗号文は保持された過去のマテリアルで復号される

C　自動ローテーションではキーIDもARNも変わらない。アプリケーション側の変更は不要

D　AWSマネージドキーも自動的にローテーションされる。カスタマー管理キーを選ぶ理由は権限制御や監査の粒度であってローテーションの可否ではない

正解：C

A　既存クラスターの暗号化変更は可能。前提が誤っている

B　Redshiftの暗号化はクラスター単位の設定で、テーブル単位で暗号化を切り替える構文はない

C（正解）　正解。既存クラスターに対して暗号化を有効化でき、Redshiftがバックグラウンドでデータを暗号化されたクラスターへ移行する。移行中は性能への影響がある

D　ネットワークレベルのアクセス制御であり、保管時の暗号化とはまったく別の統制。要件を満たさない

正解：A

A（正解）　正解。エンドポイント経由のリクエストのみを許可する条件をバケットポリシーに書くことで、インターネット経由のアクセスを確実に拒否できる

B　パブリック公開は防げるが、認証された自社のプリンシパルがインターネット経由でアクセスすることは防げない

C　S3バケットはリージョンサービスであり、VPCのサブネット内に配置するものではない。前提が誤っている

D　インスタンス側からの接続先は制限できるが、バケット側で「どこからのアクセスを受け付けるか」を制御できない。他の経路からのアクセスは残る

正解：B

A　キーの指定だけでは各種の暗号化は有効にならない。保管時と転送中の設定はそれぞれ明示する必要がある

B（正解）　正解。EMRのセキュリティ設定は保管時・転送中の暗号化と認証をひとまとめに定義した再利用可能な構成で、クラスター作成時に指定する

C　自前実装になり、EMRFSやSpark間通信の暗号化を正しく構成するのは困難。標準機能があるため選ぶ理由がない

D　S3上のデータは保護されるが、ノード間通信とローカルディスクは暗号化されない。要件の一部しか満たさない

正解：C

A　メッセージの中身は守られるがメタデータや通信経路は保護されない。ブローカー間通信の暗号化にもならない

B　アクセス元の制限であって暗号化ではない。通信内容は保護されない

C（正解）　正解。MSKはクライアントとブローカー間、およびブローカー間の転送中暗号化をそれぞれ設定できる。TLSのみを許可する構成にすれば平文接続を排除できる

D　ブローカーのストレージという保管時の暗号化であり、通信路の保護とは別の統制