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

正解：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の処理内容そのものを変えてしまい、データが不完全になる。リソース競合の解決方法として成立していない

正解：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（正解）　正解。キーポリシーと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マネージドキーも自動的にローテーションされる。カスタマー管理キーを選ぶ理由は権限制御や監査の粒度であってローテーションの可否ではない