第1回 問題集（データ処理・ETL）

正解: B. Amazon Kinesis Data Streams

正解の根拠・詳細解説

Kinesis Data Streams が適する理由：①シャードによる保持：受信レコードはシャード上に保持され（既定 24 時間、最大 365 日まで延長可能）、コンシューマーは自分のシーケンス番号（イテレーター位置）を独立して管理する。そのため「リアルタイム集計」「不正検知」「S3 アーカイブ」といった複数のアプリが同一データを並行に読み取れる、②再処理が可能：保持期間内なら過去のレコードを巻き戻して再読み込みできるため、障害復旧やロジック変更後の再集計に対応できる、③拡張ファンアウト：コンシューマーごとに専用スループット（シャードあたり 2MB/秒）を割り当て、消費者が増えても互いの読み取り性能を圧迫しない。誤答の理由：SQS は 1 メッセージを 1 コンシューマーが受信して削除するモデルで、同じデータを複数系統に流すには SNS ファンアウトや複数キューが別途必要になり、しかも保持後の再読込ができない。SNS はプッシュ型の通知で永続的なストリーム保持や順序保証を目的としない。

正解: B. AWS Database Migration Service（DMS）

正解の根拠・詳細解説

AWS DMS が適する理由：①フルロード＋CDC：初回に既存データを一括コピーし、その間に発生した変更をキャッシュして適用したうえで、以降はソース DB のトランザクションログ（Oracle なら REDO ログ、MySQL なら binlog）を読み取って継続的に差分を反映できる。アプリ側にトリガーを仕込む必要がなく、ソースへの負荷を抑えられる、②異種間移行：ソースとターゲットのエンジンが異なっても構わず、ターゲットに S3 を指定すれば CSV や Parquet としてデータレイクへ書き出せる（スキーマ変換が必要な場合は SCT を併用する）。実務上の注意：Oracle の CDC では補足ログ（supplemental logging）の有効化が前提になり、これを忘れると変更が捕捉できない。誤答の理由：Glue はバッチ ETL であり DB のログを追う仕組みを持たない。DataSync はファイル／オブジェクトストレージ間の転送用、Firehose はストリームの配信用で、いずれも DB の変更捕捉はできない。

正解: B. AWS Glue ETLジョブ

正解の根拠・詳細解説

AWS Glue ETL が適する理由：①サーバーレス Spark：クラスターのプロビジョニングやパッチ適用が不要で、DPU 単位の従量課金で分散処理が実行される。PySpark／Scala のスクリプトのほか、Visual ETL でノーコード定義もできる、②フォーマット変換：DynamicFrame／DataFrame で CSV を読み取り、write で Parquet（Snappy 圧縮など）として書き出すだけで列指向化が完了する。Data Catalog と統合されているためテーブル定義もそのまま引き継げる、③ジョブブックマーク：処理済みファイルを記録し、次回実行時に新規データだけを処理する増分 ETL が容易。誤答の理由：EMR の永続クラスターは細かなチューニングや Hive／HBase など幅広いエコシステムが必要な場合に有効だが、クラスター管理と待機コストが発生する。Lambda は実行時間 15 分・メモリ上限の制約があり、大量ファイルの分散変換には不向き。実務では Parquet 化によって Athena のスキャン量が大幅に減り、クエリコスト削減にも直結する。

正解: B. Kinesis Data Firehose

正解の根拠・詳細解説

Kinesis Data Firehose が適する理由：①フルマネージドの配信：バッファリング条件（サイズまたは経過時間）に従ってレコードを自動でまとめ、圧縮・暗号化したうえで S3 に書き出す。シャード管理やチェックポイント管理が不要で、スループットに応じて自動的にスケールする、②変換と最適化：Lambda による軽量変換、Parquet／ORC への形式変換、動的パーティショニングによる year=/month=/day= 形式の出力までマネージドで行える。小さなファイルが乱立しにくく、後段の Athena クエリ性能も確保しやすい、③配信先の多様性：S3 のほか Redshift や OpenSearch へも配信でき、失敗レコードはエラー用プレフィックスに退避される。誤答の理由：Kinesis Data Streams＋自前 Lambda でも同じことは実現できるが、シャード数の調整やバッチ書き込みの実装・再試行処理を自前で持つ必要があり運用負荷が高い。トレードオフとして、Firehose はバッファリングの分だけ配信に遅延が生じるため、秒未満のレイテンシが要件なら Data Streams を選ぶ。

正解: A. Amazon MSK（Managed Streaming for Apache Kafka）

正解の根拠・詳細解説

Amazon MSK が適する理由：①Kafka API 互換：オープンソースの Apache Kafka をそのまま運用するため、既存のプロデューサー／コンシューマーのコード、Kafka Connect のコネクタ、Kafka Streams などのエコシステムを書き換えずに移行できる、②運用のマネージド化：ブローカーのプロビジョニング、AZ をまたぐ配置、パッチ適用、障害ブローカーの自動置換などを AWS が担い、監視は CloudWatch や Prometheus 用のオープンモニタリングで行える、③選択肢の幅：容量を自分で設計するプロビジョンドのほか、トラフィックに応じて自動調整される MSK Serverless、コネクタを managed で動かす MSK Connect も利用できる。誤答の理由：Kinesis Data Streams はマネージドなストリーミング基盤だが Kafka API 互換ではないため、既存 Kafka クライアントの全面的な書き換えが必要になる。Amazon MQ は ActiveMQ／RabbitMQ 互換のメッセージブローカーで、JMS や AMQP を使う既存アプリ向けであり Kafka の代替ではない。

正解: A. AWS Glue Data Catalog

正解の根拠・詳細解説

Glue Data Catalog が適する理由：①中央メタデータリポジトリ：データベース・テーブル・列定義・パーティション情報・データの物理的な場所（S3 パス）や SerDe 設定を一元的に保持する。Hive メタストア互換のインターフェースを持つため、Hive／Spark ベースの処理からも扱いやすい、②サービス横断での共有：Athena は既定でこのカタログをメタストアとして参照し、Redshift Spectrum の外部スキーマ、EMR、Glue ETL ジョブも同じ定義を共有できる。テーブル定義を一箇所で直せば全サービスに反映されるため、定義の重複や不整合を避けられる、③自動登録と権限管理：Crawler と組み合わせればスキーマとパーティションを自動検出でき、Lake Formation を重ねればテーブル単位・列単位・行単位のきめ細かなアクセス制御を適用できる。誤答の理由：RDS や DynamoDB に自前のメタデータテーブルを作っても、Athena や Redshift Spectrum が自動で参照してくれるわけではない。Parameter Store は設定値の保管用でスキーマ管理には向かない。

正解: A. Amazon AppFlow

正解の根拠・詳細解説

Amazon AppFlow が適する理由：①ノーコードの SaaS 連携：Salesforce、ServiceNow、Zendesk、Slack、Google Analytics などのコネクタが用意されており、認証情報を登録して取得対象オブジェクトと宛先（S3 や Redshift など）を選ぶだけでフローが完成する。API 呼び出しやページング処理、認証トークンの更新といった実装を自前で持たなくてよい、②実行トリガーの柔軟性：オンデマンド、スケジュール、SaaS 側のイベント起動を選択でき、フルと増分の取り込みにも対応する、③転送時の加工：フィールドのマッピング、フィルタ、連結、マスキングといった変換をフロー定義内で指定できる。またパブリックインターネットを経由せず PrivateLink 経由で通信する構成も取れる。誤答の理由：DataSync は NFS／SMB／オブジェクトストレージ間のファイル転送用、Transfer Family はマネージドな SFTP／FTPS エンドポイントの提供であり、いずれも SaaS の API からデータを引き出す機能は持たない。

正解: B. AWS Glue Workflow

正解の根拠・詳細解説

Glue Workflow が適する理由：①Glue コンポーネントの統合オーケストレーション：複数の ETL ジョブ、Crawler、トリガーを 1 つの有向グラフとして定義し、まとめて起動・監視できる。実行状況はコンソール上のグラフで可視化され、どのノードで失敗したかを追跡しやすい、②依存関係の表現：トリガーには「先行ジョブがすべて成功したら」「いずれかが完了したら」といった条件を設定でき、Crawler でパーティションを更新してから後続ジョブを走らせる、といった順序制御が宣言的に書ける、③ワークフロー実行プロパティ：同一実行内のジョブ間で値を共有でき、処理対象の日付などを引き渡せる。使い分け：Glue のリソースだけで完結するなら Workflow が最も簡潔。Lambda・EMR・Redshift・SNS など Glue 以外のサービスをまたぐ複雑なフローや、細かなリトライ／分岐制御が必要なら Step Functions を用いる。EventBridge 単体はイベントやスケジュールでの起動はできるが、ジョブ間の依存関係を管理する仕組みは持たない。

正解: C. Parquet

正解の根拠・詳細解説

Parquet が適する理由：①列指向レイアウト：データを列ごとにまとめて格納するため、SELECT で指定した列のブロックだけを読めばよく、不要な列の I/O が発生しない。分析クエリは全列のうち一部しか参照しないことが多いため効果が大きい、②高い圧縮効率：同じ列には同じ型・似た値が並ぶので、辞書エンコーディングやランレングス符号化が効きやすく、行指向形式より格段に小さくなる、③統計情報による絞り込み：行グループ／列チャンク単位で最小値・最大値などのメタデータを持つため、条件に合致しないブロックを読み飛ばすプレディケートプッシュダウンが働く。コスト面の効果：Athena や Redshift Spectrum はスキャンしたデータ量に対して課金されるため、Parquet 化はレイテンシ短縮と料金削減の両方に効く。誤答の理由：CSV や JSON は行指向で、1 列だけ欲しい場合でも行全体を読み込む必要がある。特に JSON はパース処理のオーバーヘッドも加わる。なお ORC も同様の特性を持つ列指向形式で、選択肢になり得る。

正解: A. DynamoDB Streams

正解の根拠・詳細解説

DynamoDB Streams が適する理由：①変更ログの提供：項目の挿入・更新・削除を時系列順のレコードとして 24 時間保持し、パーティションキー単位で順序が保証される。StreamViewType の設定により、キーのみ、変更前イメージ、変更後イメージ、その両方から必要な情報を選べるため、差分検知や監査にも使える、②Lambda との統合：イベントソースマッピングが Lambda に代わってストリームをポーリングし、バッチ単位で関数を呼び出す。関数内でフィルタや整形を行い、Kinesis Data Streams へ put することで後段の分析パイプラインに接続できる、③運用の容易さ：テーブル側の設定を有効にするだけで利用でき、アプリケーションのコード変更は不要。実務上の注意：エラー時の再試行でレコードが重複して届き得るため、下流の処理は冪等に設計する。より長い保持期間や複数コンシューマーが必要なら Kinesis Data Streams for DynamoDB を選ぶ。誤答の理由：Global Tables はリージョン間レプリケーション、DAX は読み取りキャッシュ、バックアップは復旧のための機能であり、いずれも変更ストリームの提供が目的ではない。

正解: A. シャード数を増やす（再シャーディング）

正解の根拠・詳細解説

再シャーディングが適する理由：①シャードが性能の単位：Kinesis Data Streams のプロビジョンドモードでは、1 シャードあたり書き込みが 1MB／秒かつ 1,000 レコード／秒、読み取りが 2MB／秒という上限がある。これを超えると ProvisionedThroughputExceededException が発生し、PutRecord がスロットリングされる。したがってシャードを分割（split）するか UpdateShardCount でシャード数を増やせば、総スループットが比例して拡大する、②運用の選択肢：トラフィック変動が読みにくい場合はオンデマンドモードにすると、需要に応じて容量が自動調整されるため手動の再シャーディングが不要になる。実務上の注意：全体では余裕があるのに特定シャードだけ詰まる場合、パーティションキーの偏り（ホットシャード）が原因なので、キーにハッシュやランダムなサフィックスを付けて分散させる。誤答の理由：保持期間の延長はデータを長く残すだけで書き込み容量には無関係。コンシューマーを減らしても読み取り側の話であり書き込みスロットリングは解消しない。暗号化の無効化はスループット上限を変えず、セキュリティを損なうだけである。

正解: B. 日付などのカラムでディレクトリをパーティション分割する（例: year=2026/month=06/）

正解の根拠・詳細解説

パーティション分割が適する理由：①パーティションプルーニング：year=2026/month=06/ のような Hive スタイルのキー＝値形式でプレフィックスを構成すると、Glue Data Catalog にパーティション列として登録され、WHERE 句で年月を指定したクエリはその配下のオブジェクトだけを読む。Athena や Redshift Spectrum はスキャン量に対して課金されるため、コストと実行時間の双方が直接的に削減される、②メンテナンス性：日付単位で区切られていれば、ライフサイクルルールでの古いパーティションの階層移動や、特定期間のみの再処理・削除も容易になる、③パーティション管理の効率化：Athena のパーティションプロジェクションを使えば、Crawler や MSCK REPAIR TABLE を都度実行せずにパーティションを解決できる。実務上の注意：粒度を細かくしすぎると小さなファイルが大量に生まれ、メタデータ管理とファイルオープンのオーバーヘッドで逆に遅くなる。誤答の理由：UUID だけのファイル名は絞り込みの手がかりにならず、巨大な単一ファイルや非圧縮での保存はスキャン量を増やして分散処理の並列度も下げる。

正解: A. AWS Step Functions

正解の根拠・詳細解説

AWS Step Functions が適する理由：①状態機械によるオーケストレーション：Amazon States Language でワークフローを宣言的に定義し、Lambda・Glue・EMR・Athena・ECS・SNS など多数のサービスを直接呼び出せる。処理の実体を持たず「順序と制御」に専念するため、各処理の疎結合を保てる、②可視化と追跡：Workflow Studio でドラッグ＆ドロップによる編集ができ、実行ごとにどのステートまで進んだか、どこで失敗したかがグラフと実行履歴で追える。長時間バッチの運用調査が容易になる、③堅牢な制御構文：Choice による分岐、Parallel と Map による並列展開、ステートごとの Retry／Catch によるリトライとエラー処理、Wait による待機を組み込みで持つ、④起動方法：EventBridge のルールから、スケジュールでも S3 などのイベントでも起動できる。誤答の理由：SQS は処理の非同期な受け渡しを担うキューであり、ワークフロー全体の状態管理はしない。Glue Crawler はメタデータ収集、Kinesis Data Analytics はストリーム処理であり、いずれもオーケストレーターではない。

正解: A. S3イベント通知＋Lambda（必要に応じてGlueジョブを起動）

正解の根拠・詳細解説

S3 イベント通知を使う構成が適する理由：①イベント駆動：バケットに s3:ObjectCreated:* の通知を設定すると、オブジェクト作成のたびに Lambda・SQS・SNS へ通知が飛ぶ。Lambda 側でオブジェクトキーを受け取り、必要に応じて Glue ジョブを StartJobRun で起動すれば、到着から処理開始までが自動化され、ポーリングの遅延もなくなる、②フィルタリング：プレフィックスとサフィックスで対象を絞れるため、raw/ 配下の .json だけを対象にする、といった制御ができる。EventBridge 経由に切り替えれば、より柔軟なパターンマッチや複数ターゲットへの配信も可能になる、③コスト効率：イベント発生時だけ課金対象の処理が動くため、常時稼働のサーバーが不要。実務上の注意：通知は少なくとも 1 回配信であり重複し得るので、処理は冪等に設計する。大量のファイルが一度に届く場合は Lambda と Glue の同時実行数上限に備え、SQS を挟んで流量を平準化すると安定する。誤答の理由：EC2 での定期ポーリングは常時稼働コストと検知遅延が発生し、手動起動や目視確認は自動化とは呼べない。

正解: A. AWS DataSync

正解の根拠・詳細解説

AWS DataSync が適する理由：①転送に特化した最適化：オンプレミスに配置したエージェントが、並列転送・圧縮・独自のネットワークプロトコルによってインターネットや Direct Connect 経由の転送を高速化する。NFS、SMB、HDFS、自己管理のオブジェクトストレージをソースにでき、宛先は S3、EFS、FSx などを選べる、②増分転送と整合性検証：2 回目以降は変更されたファイルだけを転送し、転送後にチェックサムでデータの整合性を検証する。これにより定期同期の転送量と時間を最小化できる、③運用機能：スケジュール実行、帯域幅の上限設定、ファイルのフィルタリング、CloudWatch へのメトリクスとログ出力を備え、独自スクリプトを書く必要がない。使い分けの観点：ネットワーク帯域が細く、ペタバイト級の初期移行を短期間で終えたい場合は Snowball 系のデバイスによるオフライン移送が現実的で、その後の継続的な差分同期を DataSync が担う、という組み合わせもよく採られる。誤答の理由：Firehose はストリーム配信、Glue は ETL、SQS はメッセージングであり、ファイルサーバーの一括同期を担う仕組みではない。

正解: A. DynamicFrame.resolveChoice()やfillna等のGlue/Sparkの変換API

正解の根拠・詳細解説

Glue／Spark の変換 API が適する理由：①DynamicFrame の柔軟なスキーマ：Glue の DynamicFrame は 1 つの列に複数の型が混在する状況を choice 型として保持でき、resolveChoice で「cast で特定の型に寄せる」「型ごとに別列へ分離する」「新しい構造体にまとめる」といった解決方法を選べる。半構造化データにありがちな型ゆらぎを、ジョブを落とさずに扱える点が大きな利点、②標準的な整形処理：ApplyMapping による列名と型の付け替え、DropNullFields による空列の除去、Filter や Map による行単位の加工が用意されている、③Spark との相互運用：toDF() で DataFrame に変換すれば fillna や dropna、withColumn といった Spark の API がそのまま使え、必要になったら fromDF() で DynamicFrame に戻せる。使い分け：スキーマが安定していて高度な最適化を効かせたいなら DataFrame、入力の形が揺れるなら DynamicFrame が扱いやすい。誤答の理由：WAF は Web アプリケーションの保護、Macie は機微データの検出、CloudWatch Logs Insights はログ分析であり、いずれも ETL の変換処理を担う機能ではない。

正解: A. AWS Glue Crawler

正解の根拠・詳細解説

Glue Crawler が適する理由：①スキーマの自動推定：指定したデータストア（S3 のパスや JDBC 接続先など）をスキャンし、組み込みまたはカスタムの分類子でファイル形式を判別したうえで、列名と型を推定して Data Catalog にテーブルを作成する。JSON のようなネストのある半構造化データも struct や array を含むスキーマとして登録できる、②パーティションの検出：year=/month=/day= のようなキー＝値形式のプレフィックスを認識し、パーティション列として自動登録する。新しい日付のデータが増えた場合も再実行すればパーティションが追加される、③運用機能：スケジュール実行や増分クロールに対応し、スキーマ変更時の挙動（新しい列を追加する、変更を無視する、など）もポリシーとして設定できる。実務上の注意：型の推定は常に意図どおりとは限らず（数値に見える ID が bigint になるなど）、確定したスキーマを使いたい場合はテーブルを手動定義するか、クローラの更新ポリシーを制限するのが安全。誤答の理由：Macie、Config、Inspector はそれぞれ機微データ検出、構成管理、脆弱性評価のためのサービスである。

正解: A. Amazon Kinesis Data Analytics（Managed Service for Apache Flink）

正解の根拠・詳細解説

Amazon Managed Service for Apache Flink（旧 Kinesis Data Analytics）が適する理由：①ストリームへの継続的クエリ：Kinesis Data Streams や MSK を入力とし、SQL や Flink の API を使って到着し続けるデータに対して継続的に集計・結合・パターン検出を行える。結果は別のストリームや Firehose 経由で S3 などに出力できる、②時間ウィンドウ処理：タンブリング、スライディング、セッションといったウィンドウで区切って集計でき、イベント時刻に基づく処理と遅延データの扱いもサポートされるため、時系列の異常検知や移動平均の算出に向く、③マネージドな実行基盤：チェックポイントとスナップショットにより障害時も状態を保ったまま復旧でき、処理容量のスケーリングもマネージドで行われる。誤答の理由：Athena は S3 上に既に保存されたデータへの対話型クエリであり、流れているデータをリアルタイムに処理する用途ではない（結果が出るのは書き出し後になる）。Glue Crawler はメタデータ収集、QuickSight は BI ダッシュボードのための可視化ツールである。

正解: A. S3クロスリージョンレプリケーション（CRR）

正解の根拠・詳細解説

S3 クロスリージョンレプリケーション（CRR）が適する理由：①非同期の自動複製：レプリケーションルールを設定すると、対象バケットに新しく書き込まれたオブジェクトが別リージョンのバケットへ自動的にコピーされる。プレフィックスやタグで対象を絞れるため、必要なデータだけを集約先に寄せられる、②要件と設定：ソースとレプリケーション先の双方でバージョニングを有効にし、S3 がオブジェクトを読み書きするための IAM ロールを指定する必要がある。複製時にストレージクラスを変更したり、所有者を宛先アカウントに移したりもできるため、分析用アカウントへの集約に向く、③補足機能：所定時間内の複製を求めるなら Replication Time Control を有効化し、ルール設定より前に存在していた既存オブジェクトは S3 バッチレプリケーションで別途複製する。誤答の理由：ライフサイクルルールはストレージクラスの移行や失効を扱う機能、S3 Select はオブジェクト内の部分取得、Transfer Acceleration はエッジ経由でのアップロード高速化であり、いずれもバケット間の複製は行わない。同一リージョン内での複製が目的なら SRR を用いる。

正解: B. フルロード＋CDC（変更データキャプチャ）

正解の根拠・詳細解説

フルロード＋CDC が適する理由：①二段構えの同期：まずソーステーブルの既存行をすべて読み出してターゲットへ書き込み（フルロード）、その最中に発生した変更はキャッシュしておいて完了後に適用する。以降はトランザクションログを読み続けて挿入・更新・削除を継続的に反映するため、初回移行から継続同期までを 1 つのタスクで完結できる、②切り替えのしやすさ：ソース側を止めずに同期を維持できるので、ターゲットが追いついたタイミングで参照先を切り替えるという最小停止時間の移行が可能になる。S3 をターゲットにする場合は初期データと変更レコードがファイルとして出力され、変更操作の種別を列として持たせる設定もできる。前提条件：CDC を機能させるにはソース側のログ設定（Oracle の補足ログ、MySQL の ROW 形式 binlog など）が必要で、これが未設定だと変更を捕捉できない。誤答の理由：フルロードのみでは初回以降の変更が反映されず、CDC のみでは開始時点より前の既存データが欠落する。スキーマ変換のみではデータ自体が移動しない。

正解: A. AWS Glue ETLジョブやAWS Batchを使う

正解の根拠・詳細解説

Lambda の制約と代替手段：Lambda の最大実行時間は 15 分で、これはタイムアウト設定の上限そのものなので「30 分に設定する」ことはできない。またメモリ設定を下げると割り当てられる CPU も比例して減り、処理はむしろ遅くなる。したがって処理時間が上限に迫る大規模 ETL は、実行時間の制約がないサービスに載せ替えるのが正しい解決策になる。①Glue ETL ジョブ：サーバーレスの Spark 環境で大量データを分散処理でき、ジョブブックマークによる増分処理も使える。ETL が主目的ならこれが第一候補、②AWS Batch：任意のコンテナイメージを実行できるため、Spark ではなく既存の Python や Java のバッチ処理をそのまま長時間動かしたい場合に向く、③EMR：Hive や Presto など Hadoop エコシステムを活用したい大規模処理向け。設計上の指針：どうしても Lambda を使いたい場合は、処理を分割して Step Functions の Map で並列に回す、あるいは S3 Select などで扱うデータ量そのものを削るといった分割統治が現実的な選択肢になる。

正解: A. Glueジョブでファイルをコンパクション（結合）して大きなファイルにまとめる

正解の根拠・詳細解説

スモールファイル問題とコンパクション：Athena（Presto/Trino ベース）は S3 上のオブジェクトを 1 つずつ開いて読むため、ファイル数が多いほどリクエスト発行とファイルオープンのオーバーヘッドが積み上がり、実データ量に比して極端に遅くなる。Parquet の場合はファイルごとにフッターのメタデータを読む必要があり、小さすぎるファイルでは圧縮効率や統計情報によるスキップも効きにくい。改善策：①コンパクション：Glue ETL ジョブで対象パーティションを読み込み、coalesce や repartition で出力パーティション数を調整して書き直し、1 ファイルあたり数百 MB 程度にまとめる、②発生源の抑制：Firehose のバッファサイズを大きめにする、ストリーミング処理の出力間隔を延ばすなど、そもそも細かいファイルを作らない設計にする、③テーブル形式の活用：Apache Iceberg などを使うとコンパクションを運用手順として組み込みやすい。誤答の理由：さらに分割すれば問題は悪化し、パーティション削除はプルーニングを失ってスキャン量が増える。暗号化の有無はこの性能問題とは無関係。

正解: A. EventBridge（スケジュール）＋ Lambda

正解の根拠・詳細解説

EventBridge Scheduler／スケジュールルール＋Lambda が適する理由：①サーバーレスな定期実行：cron 式や rate 式で起動間隔を定義し、時刻になると EventBridge が Lambda を呼び出す。常時稼働するインスタンスが不要なため、実行時間分の課金だけで済み、OS のパッチ管理も発生しない、②可用性と再試行：EventBridge と Lambda はいずれもマネージドで冗長化されており、失敗時の再試行やデッドレターキューへの退避も設定で賄える。EC2 上の cron ではインスタンス障害がそのまま処理の停止につながる、③処理内容との相性：API から取得して変換し S3 に置く程度の軽量処理は、実行時間 15 分・メモリ上限の範囲に十分収まる。実務上の注意：外部 API の認証情報は Secrets Manager に置き、レート制限や一時的な失敗に備えて指数バックオフを実装する。処理が重くなってきたら Glue や Step Functions への移行を検討する。誤答の理由：RDS のストアドプロシージャは外部 API 取得の用途に向かず、Lambda@Edge は CloudFront のリクエスト処理を加工する仕組みで定期バッチ用途ではない。

正解: A. Firehoseのレコード形式変換機能（Data Format Conversion）

正解の根拠・詳細解説

Firehose のレコード形式変換（Data Format Conversion）が適する理由：①ストリームのまま列指向化：配信ストリームでこの機能を有効にすると、受信した JSON レコードを S3 へ書き出す直前に Parquet または ORC へ変換できる。後段で別途変換ジョブを走らせる必要がなくなり、パイプラインが単純になる、②スキーマの参照元：変換には Glue Data Catalog のテーブル定義を指定する。Firehose はその列名と型に従ってシリアライズするため、あらかじめカタログにテーブルを用意しておくことが前提になる、③効果：列指向かつ圧縮された状態で保存されるので、Athena や Redshift Spectrum のスキャン量が減り、クエリ料金と応答時間の両方が改善する。実務上の注意：入力が JSON であることが前提で、スキーマに存在しないフィールドの扱いには注意が必要。動的パーティショニングと併用すれば、パーティション分割された Parquet を直接生成できる。誤答の理由：Glacier はアーカイブ用ストレージクラス、オリジンシールドは CloudFront のキャッシュ最適化機能であり、いずれも形式変換とは無関係。Crawler はスキーマを登録するだけで変換は行わない。

正解: B. Spotインスタンス

正解の根拠・詳細解説

Spot インスタンスが適する理由：①コスト効率：AWS の余剰キャパシティを利用するため、オンデマンド価格より大幅に安い単価で計算リソースを確保できる。EMR の処理は失敗したタスクを別ノードで再実行できるため、中断が致命的にならない、②EMR での使いどころ：HDFS のデータを保持するコアノードではなく、計算のみを担うタスクノードに Spot を割り当てるのが定石。コアノードが失われるとデータブロックの再構成が必要になり、ジョブ全体が不安定になる、③中断への備え：インスタンスフリートで複数のインスタンスタイプと AZ を候補に挙げ、キャパシティ最適化の割り当て戦略を使うと中断確率を下げられる。中断は事前通知を伴うが、猶予は短いため冪等な処理設計が前提になる。誤答の理由：オンデマンドのみでは中断リスクを避けられる代わりに単価が高い。専用ホストはライセンス要件などで物理サーバーを占有したい場合の選択肢。Savings Plans は一定の利用量を約束して割引を得る購入方法で、中断可能なワークロード向けの最適解というわけではない（EMR ではむしろ長期安定稼働に向く）。

正解: B. データ変換（トランスフォーメーション）

正解の根拠・詳細解説

データ変換（Transformation）とは：ETL／ELT の T にあたる工程で、異なるシステムから集めたデータを共通のスキーマと意味に揃える処理全般を指す。具体的には、①形式の統一：JSON・CSV・XML といったシリアライズ形式の差を吸収し、分析に適した Parquet などへ揃える、②構造の正規化：ネストの平坦化、列名の統一、データ型のキャスト、日付やタイムスタンプの表記とタイムゾーンの統一、③品質の担保：欠損値の補完や除外、重複排除、コード値のマスタとの突合、ビジネスルールに基づく集計や導出列の追加。AWS での実装：Glue ETL（PySpark）、Glue DataBrew（ノーコードでのデータ準備）、EMR、Redshift 内での SQL 変換（ELT）などが選択肢となる。誤答との違い：データガバナンスは品質・カタログ・アクセス制御など管理の枠組み、レプリケーションはデータの複製、マスキングは機微情報の秘匿であり、いずれも形式や構造を共通化する処理そのものを指す言葉ではない。

正解: A. AWS Transfer Family

正解の根拠・詳細解説

AWS Transfer Family が適する理由：①既存プロトコルの維持：SFTP、FTPS、FTP、さらに AS2 に対応したマネージドエンドポイントを提供するため、取引先や既存システムのファイル転送手順を変更せずに移行できる。相手側から見れば従来どおり SFTP でファイルを置くだけでよい、②保存先が AWS ストレージ：転送されたファイルはそのまま S3 または EFS に格納されるので、到着をトリガーに Lambda や Glue を起動し、データレイクの取り込みパイプラインへ直結できる、③認証方式の柔軟性：サービス管理のユーザー、Active Directory との連携、Lambda や API Gateway を使ったカスタム ID プロバイダーを選択でき、既存の認証基盤と統合できる。誤答の理由：DataSync は自分たちのストレージ間で大量ファイルを同期するためのサービスで、外部からの SFTP 受け入れ口にはならない。Transfer Acceleration は S3 へのアップロードをエッジ経由で高速化する機能、Direct Connect は専用線接続であり、いずれもプロトコル互換の提供が目的ではない。

正解: A. 各イベントに一意のIDを付与し、書き込み時に重複排除（Idempotent処理）を行う

正解の根拠・詳細解説

冪等（Idempotent）な書き込みが適する理由：①At-Least-Once の現実：Kinesis や SQS、Lambda のイベントソースマッピングは「少なくとも 1 回」の配信を保証するモデルであり、再試行やコンシューマーの再起動によって同じレコードが複数回届くことを前提に設計する必要がある。プロデューサー側の再送でも重複は起き得る、②対策の考え方：イベントごとに一意のキー（発生元 ID とタイムスタンプの組み合わせなど）を持たせ、下流ではそのキーを基準に重複を排除する。Redshift や Iceberg などトランザクションを扱えるテーブルなら MERGE による upsert、S3 に直接書くなら決定論的なオブジェクトキーで上書きする、あるいは後段の集計時に DISTINCT や row_number で最新のみ残す、といった実装になる。誤答の理由：順序を無視することは重複対策にならない。Firehose のバッファリングを最小にしても重複配信自体は防げず、むしろ小さいファイルが増えて性能が悪化する。暗号化キーの共有はセキュリティの話でデータ品質とは無関係。

正解: A. 前回処理済みのデータを記録し、増分のみを次回処理対象にする

正解の根拠・詳細解説

ジョブブックマークが適する理由：①増分処理の実現：Glue はジョブ実行ごとに、どこまで処理したかを示す状態（S3 なら処理済みオブジェクトの情報、JDBC ならブックマークキーとして指定した列の最大値など）を保存する。次回実行時はその続きから読み込むため、同じデータを二重に処理せず、実行時間とコストを抑えられる、②実装上の要件：スクリプト内で各データソースやシンクに transformation_ctx を指定し、ジョブ設定でブックマークを有効化する必要がある。これが抜けていると状態が正しく記録されない、③運用：全量を作り直したいときはブックマークをリセットでき、一時的に無視して実行することもできる。実務上の注意：JDBC ソースでは、単調増加するキー列でないと更新行を取りこぼす可能性があるため、更新の反映が必要なら CDC やタイムスタンプ列を用いた設計を検討する。誤答の理由：ログの暗号化、IAM 権限の更新、ライフサイクルルールの適用は、いずれもジョブブックマークとは別の機能が担う領域である。

正解: B. Kinesis Data Streams ＋ Kinesis Data Analytics ＋ QuickSight

正解の根拠・詳細解説

ニアリアルタイム構成が適する理由：①取り込み：Kinesis Data Streams が複数ソースからのイベントを継続的に受け付け、シャード上に保持する。複数の下流アプリが同じストリームを並行して読めるため、リアルタイム集計と生データの保管を同時に行える、②処理：Kinesis Data Analytics（Managed Service for Apache Flink）が時間ウィンドウで集計し、数秒から数分の粒度で結果を出力する。イベント時刻に基づくウィンドウ処理により、多少の到着遅延があっても正しい集計を保てる、③可視化：集計結果を S3 や Redshift、あるいは QuickSight が参照できるデータストアに書き出し、ダッシュボードで表示する。設計上の注意：QuickSight の SPICE は更新間隔に下限があるため、秒単位の更新が必要なら直接クエリや OpenSearch Dashboards の併用を検討する。誤答の理由：日次バッチや手動アップロードでは遅延が数時間から 1 日単位になり要件を満たさない。Glacier はアーカイブ目的のストレージクラスで、ダッシュボードのデータソースには適さない。

正解: B. S3ライフサイクルルールでGlacier Deep Archiveへ自動移行

正解の根拠・詳細解説

S3 ライフサイクル＋Glacier Deep Archive が適する理由：①コスト最適化：Deep Archive は S3 のストレージクラスの中で最も保管単価が低く、ほとんど参照されない長期保管データに向く。ライフサイクルルールでオブジェクトの経過日数に応じて自動的に移行させれば、運用者が手を動かす必要がない、②段階的な移行：作成直後は標準、一定期間後に Standard-IA や Glacier Flexible Retrieval、さらに時間が経てば Deep Archive、というように複数段のルールを組める。7 年後に失効（Expiration）させるルールも同じ仕組みで設定できる、③規制対応：改ざん防止が求められるなら S3 Object Lock を併用し、保持期間中の削除・上書きを禁止できる。トレードオフ：Deep Archive は取り出しに時間がかかり（標準取り出しで数時間規模）、復元リクエストの料金と最低保管期間の課金が発生するため、たまに素早く参照する必要があるデータには不向き。誤答の理由：標準クラスのまま 7 年保持すると保管料が過大になり、DynamoDB や EBS スナップショットはログの長期アーカイブとして単価・用途の両面で適さない。

正解: B. DISTRIBUTION KEY（DISTSTYLE KEY）

正解の根拠・詳細解説

分散キー（DISTKEY）が適する理由：①Redshift の分散アーキテクチャ：テーブルの行は複数のコンピュートノードのスライスに分散して格納される。JOIN する 2 つのテーブルで結合列を DISTKEY に指定すると、同じ値の行が同じスライスに配置されるため、結合時にノード間でデータを再配布（シャッフル）する必要がなくなり、ネットワーク転送が大幅に減る、②分散スタイルの選び方：大きなファクトテーブル同士の結合には KEY 分散、小さなディメンションテーブルは全ノードに複製する ALL 分散、特に偏りがなければ EVEN、判断を任せるなら AUTO が使える。DISTKEY はカーディナリティが高く値の偏りが少ない列を選ばないと、特定スライスにデータが集中して逆効果になる。誤答の理由：SORTKEY は物理的な並び順を決めてゾーンマップによるブロックスキップを効かせる機能で、範囲条件の絞り込みには効くがノード配置は変えない。圧縮エンコーディングはストレージと I/O の削減、VACUUM は削除行の回収とソート順の再構成であり、いずれもデータ配置による JOIN 最適化とは目的が異なる。

正解: B. オンデマンドキャパシティモード

正解の根拠・詳細解説

オンデマンドキャパシティモードが適する理由：①容量計画が不要：読み書きしたリクエスト数に対して課金され、トラフィックの増減にテーブルが自動で追従する。ピークを見積もって RCU／WCU を設定し、外れたら調整するという運用サイクルから解放される、②急激な変動への耐性：直近のピークを基準にした範囲であれば即座にスケールし、スパイク時のスロットリングを避けやすい。新規サービスやキャンペーンなど、需要が読めない場面に向く。トレードオフ：単位リクエストあたりの単価はプロビジョンドより高いため、トラフィックが安定して予測できるワークロードでは、プロビジョンド＋Auto Scaling（さらに長期利用ならリザーブドキャパシティ）のほうが総コストは安くなる。両モードは後から切り替えられるので、まずオンデマンドで運用して傾向を掴み、安定したらプロビジョンドへ移すという進め方も現実的。誤答の理由：固定のプロビジョニングや Auto Scaling なしの構成は、変化するアクセスパターンに対して過剰プロビジョニングかスロットリングのどちらかを招く。

正解: A. パーティションキーの設計を見直し、より分散性の高いキーにする

正解の根拠・詳細解説

パーティションキー設計の見直しが適する理由：①ホットパーティションの仕組み：DynamoDB はパーティションキーのハッシュ値でデータを物理パーティションに振り分ける。特定のキー値にアクセスが集中すると、テーブル全体の容量に余裕があっても、そのパーティションの上限に阻まれてスロットリングが起きる、②有効な対策：キーの値域が広く分布が均一になるよう設計を改める。例えば日付だけをキーにしていると当日分に集中するので、ID との複合キーにする、あるいは書き込み分散のためにキーへ計算可能なサフィックスを付け、読み取り時は全サフィックスに対してクエリを投げる（書き込みシャーディング）といった手法が使われる。アクセスパターン別に GSI を用意して負荷を分ける方法も有効、③補足：アダプティブキャパシティが偏りをある程度吸収するが、単一キーへの極端な集中までは救えない。誤答の理由：テーブルの作り直しはキー設計を変えなければ同じ問題が再発する。強整合性読み取りは消費キャパシティが増えて悪化し、TTL は期限切れ項目の削除機能で負荷分散とは無関係。

正解: A. AWS Lake Formation

正解の根拠・詳細解説

AWS Lake Formation が適する理由：①きめ細かなアクセス制御：Glue Data Catalog のデータベース・テーブルに対して、列単位、行単位（データフィルタ）、さらにセル単位の権限を定義できる。IAM ポリシーで S3 プレフィックスごとに制御する方式に比べ、分析利用者から見た「テーブル」の単位で権限を表現できるため管理が現実的になる、②一貫した適用：付与した権限は Athena、Redshift Spectrum、EMR、Glue といった対応サービスから同じように評価されるため、経路によって権限が食い違う事故を防げる、③クロスアカウント共有：AWS RAM を通じてカタログのリソースを別アカウントへ共有でき、受け取り側はリソースリンク経由で参照する。LF-Tag を使えば「機密度: 高」のようなタグ単位でまとめて権限を管理でき、テーブル数が増えても運用が破綻しにくい。誤答の理由：Macie は S3 内の個人情報などを検出・分類するサービス、Organizations はアカウント統制、GuardDuty は脅威検知であり、いずれもテーブルの行・列レベルの権限付与を行う機能ではない。

正解: A. OLTPデータベース（Aurora等）でトランザクション処理、OLAPデータウェアハウス（Redshift等）で分析

正解の根拠・詳細解説

OLTP と OLAP の使い分けが適する理由：①ワークロード特性の違い：トランザクション処理は「少数行の高頻度な読み書き」が中心で、行指向ストレージとインデックス、ACID トランザクションに最適化された Aurora や RDS が向く。一方で分析処理は「多数行の少数列に対する集計スキャン」が中心で、列指向・MPP アーキテクチャの Redshift が圧倒的に効率的、②負荷の分離：分析クエリを本番の OLTP データベースに直接投げると、重いスキャンが業務トランザクションのレイテンシを悪化させる。基盤を分けることで互いの性能干渉を避けられる、③連携方法：DMS の CDC、Glue の ETL ジョブ、あるいは Aurora と Redshift のゼロ ETL 統合などで、トランザクションデータを分析基盤へ継続的に反映する構成が一般的。誤答の理由：DynamoDB の単一テーブル設計は事前に定義したアクセスパターンには強いが、アドホックな集計や結合には向かない。Glacier はアーカイブ用でクエリ基盤にならず、RDS 単体に両方を担わせると相互の性能問題とスケール限界に突き当たる。

正解: C. RA3ノード

正解の根拠・詳細解説

RA3 ノードが適する理由：①ストレージとコンピュートの分離：RA3 は Redshift Managed Storage（RMS）を採用しており、データの実体は S3 に置かれ、各ノードのローカル SSD はホットデータのキャッシュとして働く。そのため「データ量が増えたからノードを追加する」必要がなくなり、必要な計算能力だけでノード数を決められる、②コスト効率：計算リソースとストレージ容量を独立に増減できるため、データは多いがクエリ負荷は中程度、といったケースで無駄が出にくい。ストレージは実使用量に応じた課金となる、③関連機能：データ共有（Data Sharing）による他クラスターへの読み取り提供や、クロスアカウントでの共有も RA3 世代の機能として利用できる。誤答の理由：DC2 はノードのローカル SSD にデータを置く構成で、容量を増やすにはノードを増やすしかない。DS2 は HDD ベースの旧世代で新規採用は推奨されない。EC2 上に自前で構築する選択肢は、Redshift のマネージドな最適化を放棄することになる。なお運用負荷をさらに下げたいなら Redshift Serverless も検討対象になる。

正解: A. グローバルセカンダリインデックス（GSI）

正解の根拠・詳細解説

グローバルセカンダリインデックス（GSI）が適する理由：①別のキー設計での検索：GSI はベーステーブルとは異なる属性をパーティションキー（および任意でソートキー）として持つ、実体を伴うインデックスである。これにより「ユーザー ID で分割したテーブルを、メールアドレスやステータスで引く」といった、本来のキーでは表現できないクエリが Scan なしで実行できる、②射影の設計：インデックスに持たせる属性を KEYS_ONLY、INCLUDE、ALL から選ぶ。必要な属性だけを射影すればストレージと書き込みコストを抑えられるが、射影外の属性が必要になるとベーステーブルへの追加読み取りが発生する、③特性：GSI への反映は非同期のため結果整合性となり、強整合性読み取りはできない。またプロビジョンドモードでは GSI 自身のキャパシティを消費する点にも注意が必要。LSI との違い：LSI はベーステーブルと同じパーティションキーでソートキーだけを変えるもので、テーブル作成時にしか定義できない。誤答の理由：TTL は項目の自動削除、Streams は変更捕捉、PITR は復旧のための機能である。

正解: A. Workload Management（WLM）

正解の根拠・詳細解説

Workload Management（WLM）が適する理由：①キューによるリソース配分：WLM はクエリを複数のキューに振り分け、キューごとに同時実行数やメモリの割合を設定する仕組みである。ユーザーグループやクエリグループを条件にキューを割り当てられるため、経営レポートのような優先度の高いクエリと、重いバッチ集計を分離し、前者が後者に待たされる状況を避けられる、②自動と手動：自動 WLM では同時実行数とメモリを Redshift が動的に調整し、クエリ優先度（priority）で相対的な重み付けを指定できる。細かく制御したい場合は手動 WLM でキュー構成を明示する、③クエリ監視ルール（QMR）：実行時間や返却行数などの閾値を超えたクエリを中断したり別キューへ移したりでき、暴走クエリからクラスターを守れる。関連機能：短時間クエリを優先する Short Query Acceleration、同時実行の急増に一時的なクラスターを追加する Concurrency Scaling も併用できる。誤答の理由：VACUUM やスナップショットは保守・バックアップの操作であり、Concurrency Scaling の無効化はむしろ混雑時の待ちを増やす。

正解: A. S3バージョニング

正解の根拠・詳細解説

S3 バージョニングが適する理由：①上書き・削除からの保護：バージョニングを有効にしたバケットでは、同じキーに書き込むたびに新しいバージョン ID が採番され、以前のバージョンも保持される。削除操作は実データを消さず削除マーカーを付けるだけなので、マーカーを取り除けば元のオブジェクトが復活する。誤操作やアプリの不具合による破壊的な変更から回復できる、②強化オプション：MFA Delete を設定すればバージョンの完全削除に多要素認証を要求でき、S3 Object Lock を併用すれば一定期間の変更・削除を禁止する WORM 保護になる。またレプリケーション機能はバージョニングの有効化が前提となる。コスト面の注意：過去バージョンもストレージ料金の対象になるため、非現行バージョンを一定日数後に安価なクラスへ移行、あるいは失効させるライフサイクルルールを併せて設定するのが定石。誤答の理由：Transfer Acceleration は転送高速化、Requester Pays は転送料金の請求先変更、Intelligent-Tiering はアクセス頻度に応じた自動階層化であり、いずれも過去バージョンの保持は行わない。

正解: B. S3 Intelligent-Tiering

正解の根拠・詳細解説

S3 Intelligent-Tiering が適する理由：①アクセス監視と自動階層化：オブジェクトごとのアクセス状況を S3 が監視し、一定期間参照されないものを高頻度アクセス階層から低頻度アクセス階層へ、さらに設定次第でアーカイブ用の階層へ自動的に移動する。再びアクセスされれば高頻度階層に戻るため、利用者側でルールを組み替える必要がない、②取り出し料金がない：低頻度アクセス階層に落ちたオブジェクトを読んでも取り出し料金は発生せず、アクセスが増減してもコストが跳ね上がらない。この点が「予測できないアクセスパターン」に強い理由である、③運用負荷：モニタリングとオートメーションの少額な月額料金がオブジェクト単位でかかるだけで、ライフサイクル設計の見直し作業から解放される。誤答の理由：S3 標準は階層化を行わず、参照されないデータにも高い単価がかかり続ける。One Zone-IA は単一 AZ 保存で可用性が低く、アクセス頻度が判明していて再作成可能なデータ向け。Glacier Instant Retrieval は明確にアクセス頻度が低いと分かっているデータ向けで、頻繁に読むと取り出し料金が嵩む。

正解: A. Redshiftデータ共有（Data Sharing）

正解の根拠・詳細解説

Redshift のデータ共有（Data Sharing）が適する理由：①コピーを作らない共有：プロデューサー側のクラスターがデータシェアを作成し、コンシューマー側がそれを参照する形で、ライブデータに対して直接読み取りクエリを実行できる。ETL でデータを複製して配る運用が不要になり、鮮度の遅れやコピー間の不整合が生じない、②ワークロードの分離：BI 用、データサイエンス用、ETL 用といった目的別のクラスターやサーバーレスワークグループを分けつつ、同じデータを見られる。計算リソースが独立するため互いの負荷が干渉しない、③範囲：同一アカウント内はもちろん、別アカウントや別リージョンとの共有も可能で、AWS Data Exchange と組み合わせれば外部組織への提供もできる。前提として RA3 系のノードタイプまたは Serverless が必要になる。誤答の理由：Spectrum は S3 上の外部データを参照する機能でクラスター間共有とは目的が異なる。スナップショットからの復元はその時点のコピーができるだけでライブ共有にならず、Concurrency Scaling は同一クラスターの同時実行性を上げる機能である。

正解: A. クラスターエンドポイント（書き込み用）とリーダーエンドポイント（読み取り用）を使い分ける

正解の根拠・詳細解説

エンドポイントの使い分けが適する理由：①クラスターエンドポイント（ライターエンドポイント）：常に現在のプライマリインスタンスを指す。フェイルオーバーが発生して別インスタンスが昇格しても同じ名前で新プライマリに追従するため、書き込みはこれを使うのが原則、②リーダーエンドポイント：登録されているリードレプリカに対して接続を分散する。読み取り専用の処理をここへ向けることで、プライマリの負荷を下げつつレプリカを増やすだけでスループットを拡張できる、③カスタムエンドポイント：特定のインスタンス群だけをまとめた独自のエンドポイントを定義でき、「大きな分析クエリは高性能なレプリカ群へ」といった振り分けが可能。設計上の注意：Aurora のレプリカ反映はごく短時間ながら非同期であり、書き込み直後に読み取りレプリカを参照すると古い値が返り得る。整合性が必要な読み取りはライターに向けるか、アプリ側で考慮する。誤答の理由：すべてをクラスターエンドポイントに向けるとプライマリに負荷が集中し、インスタンスエンドポイントの直指定はフェイルオーバー時に接続先が不正になる。

正解: A. TTL（Time To Live）

正解の根拠・詳細解説

TTL（Time To Live）が適する理由：①自動的な期限管理：項目に UNIX エポック秒を値とする属性を持たせ、その属性名を TTL として指定すると、DynamoDB が期限を過ぎた項目をバックグラウンドで自動削除する。セッション情報やログ、キャッシュのような有効期間が決まったデータのストレージ料金を継続的に抑えられる、②書き込みキャパシティを消費しない：TTL による削除は通常の DeleteItem と異なりスループットを消費せず、追加料金もかからない。自前で期限切れ項目をスキャンして削除するバッチを組むより、コストと運用の両面で有利、③下流への通知：TTL 削除も DynamoDB Streams にレコードとして流れるため（userIdentity で TTL 由来と判別できる）、削除前にアーカイブへ退避するといった処理を後段で実装できる。実務上の注意：削除は即時ではなく通常は期限後しばらくしてから行われるため、厳密に期限後の読み取りを防ぎたい場合はクエリ側でも期限を条件に加える。誤答の理由：バックアップは復旧用、DAX はキャッシュ、Transactions は複数項目の原子的更新のための機能である。

正解: A. DynamoDB Accelerator（DAX）

正解の根拠・詳細解説

DynamoDB Accelerator（DAX）が適する理由：①専用のインメモリキャッシュ：DynamoDB の前段に置くフルマネージドのクラスターで、通常は 1 桁ミリ秒である読み取りをキャッシュヒット時にマイクロ秒レベルまで短縮する。API が DynamoDB 互換なので、アプリケーションは DAX クライアントに差し替えるだけで済み、キャッシュの整合や失効ロジックを自前で書く必要がない、②2 種類のキャッシュ：GetItem などの結果を保持するアイテムキャッシュと、Query／Scan の結果を保持するクエリキャッシュを持つ。読み取りが支配的で更新が少ないワークロードほどヒット率が高くなり効果が大きい、③書き込み：ライトスルー方式で、DAX 経由の書き込みは DynamoDB に反映されると同時にキャッシュも更新される。注意点：DAX が返すのは結果整合性のある読み取りであり、強整合性読み取りはキャッシュを経由せず DynamoDB に直接向かうため高速化されない。また DAX を経由しない直接書き込みがあるとキャッシュが古くなり得る。誤答の理由：Streams は変更捕捉、Global Tables はリージョン間複製、バックアップは復旧のための機能である。

正解: A. DynamoDB Global Tables

正解の根拠・詳細解説

DynamoDB Global Tables が適する理由：①マルチアクティブなレプリケーション：複数リージョンにレプリカテーブルを作成すると、どのリージョンでも読み書きが可能になり、書き込みは自動的に他リージョンへ非同期に伝播する。利用者に近いリージョンで処理できるためレイテンシが下がり、リージョン障害時の継続性も確保できる、②仕組み：内部的には DynamoDB Streams による変更伝播を利用しており、テーブル側でストリームの有効化が必要になる。伝播は通常は 1 秒程度だが非同期であるため、直後に別リージョンで読むと反映前の値が返り得る、③競合解決：同じ項目が複数リージョンでほぼ同時に更新された場合、最終書き込み優先（last writer wins）で収束する。そのため、リージョンをまたいだ厳密な排他制御が必要な処理には向かない。誤答の理由：Streams 単体は変更を取り出せるだけで複製そのものは行わない。S3 のクロスリージョンレプリケーションはオブジェクトストレージの機能、Aurora グローバルデータベースはリレーショナルデータベースの機能で、いずれも DynamoDB のテーブルには適用できない。

正解: A. Redshift Spectrum または Athena ＋ Glue Data Catalog

正解の根拠・詳細解説

スキーマオンリードの構成が適する理由：①事前ロード不要のクエリ：Athena も Redshift Spectrum も、S3 上のファイルをそのままの場所で読み、Glue Data Catalog に登録された外部テーブル定義を「読み取り時のスキーマ」として適用する。データウェアハウスへ取り込む ETL を経ずに SQL で分析を始められるため、探索的な分析や到着したばかりの生データの確認に向く、②多様な形式への対応：CSV や JSON、Parquet、ORC、Avro など複数の形式を SerDe によって扱え、ネストした構造も struct や array として参照できる。スキーマを後から変更しても、既存ファイルを書き換える必要がない、③使い分け：完全サーバーレスで従量課金のアドホック分析なら Athena、既存の Redshift のテーブルと結合して分析したいなら Spectrum が適する。実務上の注意：スキャン量に対する課金であるため、パーティション設計と列指向フォーマット化がコストに直結する。誤答の理由：RDS や DynamoDB は自身のストレージにデータを取り込む必要があり、EC2 上のローカル処理は分散スケールと運用性の点で分析基盤として成り立たない。

正解: A. DISTKEYの選択（分散キーの偏りがないか）

正解の根拠・詳細解説

DISTKEY の偏りを確認すべき理由：①分散スキューの発生：Redshift は DISTKEY の値をハッシュしてスライスへ行を割り当てる。もしその列の値が特定値に集中していたり、NULL が大半を占めていたりすると、一部のスライスにだけデータが偏って格納され、そのノードだけが長時間処理を続けることになる。MPP では最も遅いスライスが全体の完了時間を決めるため、クラスター全体の性能が落ちる、②見直しの観点：カーディナリティが高く値の分布が均一で、かつ主要な JOIN や GROUP BY で使われる列を選ぶ。適当な列がなければ EVEN 分散にする、小さなディメンションテーブルなら ALL 分散で全ノードに複製する、判断に迷う場合は AUTO に任せる、③確認方法：システムビュー（テーブルごとのスライス単位の行数やスキュー率を示すもの）で偏りを点検し、実行計画で再配布（DS_BCAST_INNER や DS_DIST_BOTH）が多発していないかを見る。誤答の理由：暗号化方式、スナップショット保持期間、IAM 権限はいずれもデータ配置とは無関係で、ノード間の負荷不均衡を解消しない。

正解: C. SSE-C（カスタマー提供キー）

正解の根拠・詳細解説

SSE-C（お客様提供の暗号化キー）が適する理由：①キーを AWS に預けない：オブジェクトの PUT／GET のたびにリクエストヘッダーで暗号化キーを渡し、S3 はそのキーで暗号化・復号を行った後にキー自体を保持しない（検証用のハッシュ値のみ保存する）。鍵素材が AWS 側に残らないため、キー管理を完全に自組織の責任範囲に置きたい規制要件に応えられる、②前提条件：キーが平文で送られるため HTTPS での通信が必須となる。またマネジメントコンソールからの単純なダウンロードはできず、キーを添えた API 呼び出しが必要になる。トレードオフ：キーを紛失するとデータは二度と復号できず、ローテーションやアクセス監査もすべて自前で仕組みを用意しなければならない。実務では、鍵の完全な自己管理までは不要で「鍵の利用を監査したい・IAM で鍵の使用権限を制御したい」という要件であれば、カスタマー管理キーを使う SSE-KMS のほうが運用しやすい。誤答の理由：SSE-S3 は AWS が完全に管理する鍵を使い、SSE-KMS も鍵素材は KMS が保持するため、いずれも「AWS に鍵を渡さない」という条件を満たさない。

正解: B. 強整合性のある読み取り（Strongly Consistent Read）

正解の根拠・詳細解説

強整合性のある読み取りが適する理由：①仕組み：DynamoDB は各項目を複数の AZ にレプリケーションしており、既定の結果整合性読み取りは任意のレプリカから返すため、書き込み直後だと古い値が返ることがある。強整合性読み取りを指定すると、書き込みが確定したレプリカから読むため、それ以前に成功したすべての書き込みが反映された値が保証される、②指定方法：GetItem、Query、Scan などで ConsistentRead を true にする。トレードオフ：消費するキャパシティが結果整合性読み取りの 2 倍になり、レイテンシもわずかに増える。すべての読み取りに適用するのではなく、在庫数や残高のような「最新値でなければ困る」場面に絞るのが定石、③制約：グローバルセカンダリインデックスからの読み取りは常に結果整合性であり、強整合性は指定できない（同じキー構成の LSI なら可能）。また DAX 経由やグローバルテーブルの別リージョンからの読み取りでも強整合性は保証されない。誤答の理由：結果整合性読み取りは最新値を保証せず、DAX の既定はキャッシュからの結果整合性読み取りである。

正解: C. S3 Glacier Instant Retrieval

正解の根拠・詳細解説

S3 Glacier Instant Retrieval が適する理由：①即時取り出し可能なアーカイブ：Glacier 系のストレージクラスでありながら、S3 標準や Standard-IA と同じくミリ秒単位で GET できる。復元リクエストを出して待つ必要がないため、医療画像やニュースアーカイブのように「めったに見ないが、見るときはすぐ必要」というデータに適する、②コスト構造：保管単価は Standard-IA よりさらに安い一方、GB あたりの取り出し料金は高めに設定されている。最低保管期間（90 日相当）の課金もあるため、頻繁に読むデータや短期間で消すデータに使うと逆に割高になる。使い分けの整理：数分から数時間の待ち時間を許容できるなら Glacier Flexible Retrieval、数時間から半日規模でよく最安を狙うなら Deep Archive、単一 AZ でよく再生成可能なデータなら One Zone-IA、というように「取り出しに許容できる時間」と「参照頻度」で選ぶ。誤答の理由：Deep Archive と Flexible Retrieval はいずれも復元に時間を要するためミリ秒の要件を満たさず、One Zone-IA はアーカイブ用途としては保管単価が高く耐久性の設計も異なる。

正解: A. SORT KEY

正解の根拠・詳細解説

SORTKEY（ソートキー）が適する理由：①ゾーンマップによるブロックスキップ：Redshift は列データを 1MB のブロック単位で保存し、各ブロックの最小値・最大値をゾーンマップとしてメモリに保持する。SORTKEY を指定した列はその順序で物理的に並ぶため、WHERE 句の範囲条件に合致しないブロックを丸ごと読み飛ばせる。結果としてディスク I/O が激減し、クエリが高速化する、②選び方：日付やタイムスタンプのように範囲で絞り込むことが多い列が最有力候補。複数列を指定する複合ソートキーでは先頭列の絞り込み効果が最も大きいため、順序の設計が重要になる。複数の異なる列で均等に絞り込まれるならインターリーブソートも選択肢だが、再構成のコストが高い、③維持：大量のロードや更新が続くとソート順が崩れるため、VACUUM（現在は自動バキュームソートも動作する）で並びを整える必要がある。誤答の理由：暗号化キーはデータ保護、VPC エンドポイントはネットワーク経路、IAM ポリシーは権限制御の話であり、いずれもスキャン量の削減には寄与しない。

正解: A. Database per Service（サービスごとのデータベース）パターン

正解の根拠・詳細解説

Database per Service パターンとは：マイクロサービスアーキテクチャにおいて、各サービスが自分専用のデータストアを持ち、他サービスのデータには直接アクセスせず API やイベントを通じてやり取りする設計方針を指す。利点：①疎結合と自律性：あるサービスのスキーマ変更が他サービスを壊さないため、チームごとに独立して開発・デプロイできる、②技術選定の自由：注文サービスはリレーショナル、商品カタログは検索エンジン、セッション管理は DynamoDB、というようにアクセスパターンに最適なストアを選べる（ポリグロットパーシステンス）、③障害の局所化：1 つのデータベースの障害が全サービスに波及しにくい。データエンジニアリング上の含意：サービス間でデータが分断されるため、横断的な分析にはデータレイクやデータウェアハウスへの集約が必須になる。その際は CDC（DMS や DynamoDB Streams）やイベント連携で各ストアの変更を吸い上げる構成が採られ、複数ストアにまたがる整合性は Saga パターンなどで結果整合的に扱う。誤答の理由：共有データベースパターンはこれと対極でサービス間の結合を強め、モノリシックやシングルテナントは別の観点の分類である。

正解: A. AWS Glue Data Catalog

正解の根拠・詳細解説

Glue Data Catalog が中心となる理由：①統一されたメタデータ層：データベース・テーブル・列・パーティションといった論理定義と、S3 上の物理的な位置、ファイル形式や SerDe の情報を一元的に保持する。データレイクは実体が S3 上のファイル群にすぎないため、「どこに何があるか」を表すこのカタログがなければ SQL による分析は成立しない、②幅広いサービスからの参照：Athena は既定のメタストアとしてこれを使い、Redshift Spectrum は外部スキーマとして、EMR の Spark／Hive はメタストアとして、Glue ETL や SageMaker のデータ準備からも同じ定義を参照できる。定義の重複がなくなり、サービスごとの食い違いを防げる、③運用機能：Crawler による自動登録とパーティション検出、スキーマバージョンの管理、Lake Formation と組み合わせた権限制御、Hive メタストア互換のインターフェースなどを備える。誤答の理由：CloudWatch Logs は運用ログの収集、Secrets Manager は資格情報の保管、SES はメール送信のサービスであり、いずれもデータのカタログ管理を担わない。

正解: A. 削除済み領域の回収とクエリプランの統計情報更新によるパフォーマンス維持

正解の根拠・詳細解説

VACUUM と ANALYZE の目的：①VACUUM：Redshift の DELETE や UPDATE は行を物理的に消さず削除マークを付けるだけなので、放置するとディスクを無駄に消費し、スキャン対象のブロックも増える。VACUUM は削除済み領域を回収し、あわせて SORTKEY 順への物理的な並び替えを行う。ソート順が保たれることでゾーンマップによるブロックスキップが再び効くようになる、②ANALYZE：テーブルの行数や列値の分布といった統計情報を更新する。クエリオプティマイザはこの統計を基に結合順序や結合方式、分散方法を決めるため、統計が古いままだと不適切な実行計画（例えば巨大テーブルのブロードキャスト）を選び、性能が大きく劣化する、③運用：現在の Redshift はクラスターの負荷が低いときに自動バキュームソートと自動 ANALYZE を実行するため常時の手動運用は不要だが、大量ロードやバックフィルの直後は明示的に実行して統計と並びを整えるのが安全。誤答の理由：キーのローテーション、IAM 更新、リサイズはいずれも別の管理操作であり、これらのコマンドの役割ではない。

正解: A. EFSは汎用ファイル共有向け、FSx for LustreはHPC/機械学習などの高スループット処理向け

正解の根拠・詳細解説

EFS と FSx for Lustre の違い：①Amazon EFS：NFS プロトコルで複数の EC2 やコンテナから同時マウントできる汎用の共有ファイルシステム。容量は自動で伸縮し、複数 AZ にまたがって高い可用性を持つ。Web コンテンツの共有、アプリケーションのホームディレクトリ、Lambda や ECS からの共有ストレージなど、汎用的な用途に向く、②FSx for Lustre：HPC や機械学習の学習ジョブ向けに設計された分散並列ファイルシステムで、数百 GB／秒級のスループットと極めて低いレイテンシを狙える。S3 バケットとリンクして、S3 のオブジェクトをファイルとして遅延ロードし、結果を S3 に書き戻すことができるため、データレイク上の大規模データを高速に読み込む前処理層として使える。使い分けの指針：汎用的な共有と運用の手軽さなら EFS、計算ノード群から同一データセットへ高スループットで読み書きする必要があるなら FSx for Lustre。誤答の理由：どちらもファイルストレージであり、ブロックストレージは EBS、オブジェクトストレージは S3 という別カテゴリになる。

正解: B. ポイントインタイムリカバリ（PITR）

正解の根拠・詳細解説

ポイントインタイムリカバリ（PITR）が適する理由：①継続的バックアップ：有効化するとテーブルの変更が継続的に記録され、直近 35 日以内であれば秒単位の任意の時点を指定して復元できる。誤った一括更新や削除、アプリのバグによるデータ破損に対して「事故の直前」に戻せる点が最大の価値になる、②復元の挙動：復元は既存テーブルを上書きするのではなく新しいテーブルとして作成される。そのため切り戻しの判断を落ち着いて行えるが、アプリの参照先切り替えや、インデックス・TTL・Auto Scaling 設定の再構成は別途必要になる点は押さえておきたい、③運用：テーブル単位で有効化するだけで、スケジュール設計もスクリプトも不要。追加のストレージ料金は発生する。使い分け：規制対応などで 35 日を超える長期保管が必要な場合は、オンデマンドバックアップや AWS Backup と組み合わせる。誤答の理由：オンデマンドバックアップは取得した時点にしか戻せず、Streams は変更の伝播用、Global Tables は可用性とレイテンシのためのリージョン間複製であり、任意時点への復元機能ではない。

正解: A. Redshift Spectrum

正解の根拠・詳細解説

Redshift Spectrum が適する理由：①クラスターに取り込まないクエリ：外部スキーマとして Glue Data Catalog を参照し、S3 上のファイルに対して直接 SQL を実行する。大量の履歴データを Redshift のマネージドストレージへロードせずに済むため、クラスター側のストレージ費用と ETL の負荷を抑えられる、②ローカルテーブルとの結合：クラスター内のテーブルと外部テーブルを 1 つのクエリで結合できる。直近の高頻度データはクラスター内に持ち、参照頻度の低い過去データは S3 に置く、というホット／コールドの階層化が自然に実現できる、③処理の仕組み：フィルタや集計の一部が Spectrum レイヤーで実行され、必要なデータだけがクラスターへ返るため、クラスターのリソース消費も抑えられる。コストと性能の注意：課金はスキャンしたデータ量に基づくため、S3 側を Parquet などの列指向形式にし、適切にパーティション分割することが料金と応答時間に直結する。誤答の理由：WLM はワークロードの優先制御、スナップショットはバックアップ、Concurrency Scaling は同時実行性の拡張であり、いずれも S3 上のデータへ直接クエリする機能ではない。

正解: A. AWS Lake Formationの権限管理

正解の根拠・詳細解説

Lake Formation の権限管理が適する理由：①分析サービスに合った権限モデル：S3 のバケットポリシーや IAM でプレフィックス単位に制御しようとすると、テーブルが増えるほどポリシーが複雑化し、経路によって権限が食い違う事故が起きやすい。Lake Formation は Glue Data Catalog のデータベース・テーブル・列（さらに行やセル）に対して SELECT や ALTER といった権限を付与するため、利用者から見える単位そのままで分離できる、②横断的な適用：付与した権限は Athena、Redshift Spectrum、EMR、Glue など対応サービスから共通に評価されるので、どの分析ツールを使っても同じ制御が効く、③スケールする運用：LF-Tag（タグベースのアクセス制御）を使えば、「部門: 営業」「機密度: 高」といったタグをテーブルに付け、タグに対してプリンシパルへ権限を与えられる。テーブルが増えても付与ルールを増やさずに済み、チーム単位の権限設計を維持しやすい。誤答の理由：Cognito はアプリケーション利用者の認証、WAF は Web アプリケーションの防御、Detective はセキュリティ調査のためのサービスである。

正解: B. Amazon DynamoDB

正解の根拠・詳細解説

DynamoDB が適する理由：①スキーマレスな構造：テーブル作成時に必須なのはパーティションキー（と必要ならソートキー）だけで、それ以外の属性は項目ごとに自由に持てる。新しいフィールドが増えても ALTER TABLE 相当の作業やマイグレーションが不要なため、スキーマが頻繁に変わる半構造化データを受け止めやすい、②柔軟な値の型：文字列や数値に加え、リストやマップといったネストした構造をそのまま格納でき、JSON に近い形のドキュメントを保持できる、③スケーラビリティ：パーティション分散により水平方向にスケールし、オンデマンドモードなら容量計画も不要。設計上の注意：柔軟である反面、DynamoDB はアクセスパターンを先に決めてキーとインデックスを設計する必要があり、アドホックな集計や複雑な結合には向かない。分析が必要な場合は Streams や DynamoDB のエクスポート機能で S3 のデータレイクへ出し、Athena で分析する構成が定石になる。誤答の理由：RDS for PostgreSQL や Redshift はスキーマ定義が前提（JSONB などの型はあるが変更の運用は必要）で、EBS はブロックストレージでありデータベースではない。

正解: A. CloudWatch Events（EventBridge）でGlueジョブの状態変化を検知し、SNSへ通知

正解の根拠・詳細解説

EventBridge＋SNS が適する理由：①イベント駆動の検知：Glue はジョブ実行の状態が変わるたびに「Glue Job State Change」イベントを EventBridge に発行する。ルールの条件で state を FAILED や TIMEOUT に絞れば、失敗したときだけ通知が飛ぶ構成になり、ポーリングや目視確認が不要になる、②通知先の柔軟性：ターゲットに SNS トピックを指定すればメールやチャット連携へ配信でき、Lambda を挟めば Slack への整形投稿や自動リトライ、Systems Manager によるインシデント起票なども組める、③網羅性：ジョブ単位ではなくアカウント全体のルールとして書けるため、新しいジョブを追加しても通知設定を作り直す必要がない。補完的な手段：ジョブのログに現れる特定のエラーメッセージを拾いたい場合は、CloudWatch Logs のメトリクスフィルターでパターンを検出しアラームを鳴らす方法を併用する。誤答の理由：CloudTrail の日次目視は検知が遅く運用が属人化する。バケットポリシーはアクセス制御、パスワードポリシーは IAM の認証設定であり、いずれもジョブの失敗検知とは無関係である。

正解: A. AWS Step Functions（実行履歴とビジュアルワークフロー）

正解の根拠・詳細解説

Step Functions が適する理由：①実行履歴の自動記録：ステートマシンの実行ごとに、各ステートの入力・出力・開始終了時刻・発生したエラーの種類とメッセージがイベント履歴として保存される。どのステップで何が起きたかを後から時系列で追えるため、複数サービスをまたぐパイプラインの障害調査が容易になる、②ビジュアルな追跡：コンソールのグラフビューで、成功したステート、失敗したステート、スキップされた分岐が色分けで表示される。ログを横断的に読み解かなくても失敗箇所を即座に特定できる、③運用との統合：実行状態の変化は EventBridge のイベントとして発行できるため、失敗時の通知や自動復旧処理につなげられる。CloudWatch Logs へ実行履歴を出力する設定を有効にすれば、長期保管や横断検索も可能になる。補足：各サービス側の詳細ログ（Glue のドライバーログ、Lambda の関数ログなど）と組み合わせることで、原因の切り分けが完結する。誤答の理由：SES はメール送信、Direct Connect は専用線接続、Cognito は認証のサービスであり、パイプラインの実行追跡機能は持たない。

正解: A. Amazon MWAA（Managed Workflows for Apache Airflow）

正解の根拠・詳細解説

Amazon MWAA が適する理由：①Airflow をそのまま利用：オープンソースの Apache Airflow をマネージドで動かすため、Python で書かれた既存の DAG、カスタムオペレーター、豊富なプロバイダーパッケージ（各種データベースや SaaS 向けのフック）をほぼそのまま持ち込める。オンプレミスや他クラウドで Airflow を運用してきた資産を活かした移行に向く、②運用のマネージド化：スケジューラーやウェブサーバー、ワーカーのプロビジョニングとパッチ適用を AWS が担い、ワーカーは負荷に応じてオートスケールする。DAG ファイルや requirements.txt、プラグインは S3 のバケットに置くだけで反映される、③統合：IAM による認証、VPC 内での実行、CloudWatch へのログ出力に対応する。使い分け：Airflow の資産や複雑な依存グラフ、豊富なオペレーターが必要なら MWAA、AWS サービスの呼び出しを中心とした軽量なワークフローをサーバーレスかつ従量課金で組みたいなら Step Functions が適する。誤答の理由：Glue Workflow は Glue 内のジョブ／クローラー向け、SWF と Data Pipeline はいずれも Airflow 互換ではない旧世代のオーケストレーションサービスである。

正解: A. Amazon Redshift Query Editorのシステムビュー（STL/SVL）やCloudWatchメトリクス

正解の根拠・詳細解説

システムビューと CloudWatch メトリクスが適する理由：①クエリ単位の詳細分析：Redshift は実行されたクエリの情報をシステムビューとして公開しており、クエリごとの実行時間、キューでの待ち時間、実行計画のステップ、スキャンした行数やディスクへの書き出し（中間結果のスピル）などを SQL で調べられる。長時間クエリの特定だけでなく、遅い原因が待ち時間なのか実処理なのかまで切り分けられる、②クラスター全体の傾向：CloudWatch のメトリクスでは CPU 使用率、ディスク使用量、同時実行数、クエリ実行時間の分布などが時系列で確認でき、負荷が高まった時間帯の把握やアラーム設定に使える、③コンソールの支援：マネジメントコンソールのクエリモニタリング画面でも、実行中および完了したクエリの一覧と所要時間を確認できる。改善へのつなぎ方：特定できたボトルネックに応じて、SORTKEY や DISTKEY の見直し、WLM のキュー設計、統計情報の更新（ANALYZE）などの対策を選ぶ。誤答の理由：Config は構成変更の記録、Macie は機微データ検出、Artifact はコンプライアンス文書の入手窓口であり、クエリ性能分析には使えない。

正解: A. DPU使用率・ジョブ実行時間などのCloudWatchメトリクス

正解の根拠・詳細解説

Glue のメトリクスを参照すべき理由：①リソースの過不足を数値で判断：Glue ジョブは CloudWatch に、割り当てた DPU に対する実際の使用状況、エグゼキューターの稼働数、メモリ使用率、ジョブの実行時間といったメトリクスを出力する。ワーカーが余っている（並列度に対して処理が少ない）のか、逆にメモリ不足でディスクへのスピルが起きているのかを、推測ではなくデータで判断できる、②調整の指針：使用率が低いままならワーカー数やワーカータイプを下げてコストを削減し、メモリ不足が疑われるなら G.2X のような大きなワーカータイプに変更する。並列度が上がらない場合は、入力ファイルの分割状況やパーティション数がボトルネックになっていることも多い、③関連機能：Glue のオートスケーリングを使えば処理量に応じてワーカー数が自動調整され、急ぎでないジョブは Flex 実行にすることで単価を抑えられる。誤答の理由：IAM ポリシーのバージョン、S3 の暗号化設定、Route 53 のヘルスチェックは、いずれもジョブの計算リソース消費と無関係で、チューニングの判断材料にならない。

正解: A. AWS CodeCommit/CodePipeline/CodeBuild

正解の根拠・詳細解説

Code シリーズによる CI/CD が適する理由：①バージョン管理：Glue のジョブスクリプト、Step Functions の定義、CloudFormation や CDK のテンプレートをすべてリポジトリで管理することで、変更履歴とレビューの記録が残り、問題発生時に以前の状態へ戻せる。データパイプラインもアプリケーションと同様にコードとして扱うのが現在の標準的な考え方である、②自動化：CodePipeline がソースの変更を検知してステージを進め、CodeBuild が単体テストや静的解析、成果物のパッケージングを実行する。デプロイは CloudFormation スタックの更新として行えば、環境間の差異を最小化できる、③段階的な適用：開発、ステージング、本番とステージを分け、承認アクションを挟むことで、本番反映前に人による確認を組み込める。補足：ソース管理は CodeCommit に限らず、GitHub などの外部リポジトリを CodePipeline のソースに指定する構成も一般的である。誤答の理由：SES はメール送信、Polly は音声合成、Snowmobile は大規模なデータ物理移送であり、いずれも CI/CD を構成する要素ではない。

正解: A. AWS Glue Data Quality

正解の根拠・詳細解説

AWS Glue Data Quality が適する理由：①宣言的なルール定義：DQDL（Data Quality Definition Language）で「この列に NULL があってはならない」「値が指定した範囲に収まる」「一意性が保たれる」「行数が想定の範囲にある」といったルールセットを記述し、データに対して評価できる。既存データからルール候補を推奨させることもでき、ゼロから書き起こす負担が小さい、②パイプラインへの組み込み：Glue ETL ジョブの中に評価ステップとして配置でき、結果に応じて処理を止める、あるいは合格したレコードと違反したレコードを分けて出力し、後者を隔離用のバケットへ退避するといった制御ができる。Data Catalog のテーブルに対してスケジュール評価することも可能、③可視化と通知：評価結果はメトリクスやイベントとして出力できるため、CloudWatch や EventBridge を通じて品質劣化を検知し通知につなげられる。実務上の意義：品質チェックを下流の分析担当者任せにせず取り込み時点で行うことで、誤った集計やダッシュボードの信頼低下を防げる。誤答の理由：Macie は機微データ検出、Trusted Advisor は構成のベストプラクティス診断、Inspector は脆弱性評価のサービスである。

正解: A. Lambdaのリトライ設定（非同期呼び出しの再試行回数）またはStep Functionsのリトライポリシー

正解の根拠・詳細解説

リトライ設定が適する理由：①一時的な障害の性質：スロットリングや下流サービスの短時間の不調は、少し待って再実行すれば成功することが多い。こうした過渡的エラーには、時間を置いた再試行が最も効果的な対策になる、②Lambda 側の仕組み：非同期呼び出しでは Lambda が既定で自動的に再試行し、再試行回数やイベントの最大保持期間を設定で調整できる。それでも失敗したイベントは、失敗時の送信先（オンフェイラー destination）やデッドレターキューへ退避させて取りこぼしを防ぐ。イベントソースマッピング経由の場合も、再試行回数や分割再試行などの制御が用意されている、③Step Functions 側の仕組み：ステートの Retry フィールドで対象エラー、初回待機時間、最大試行回数、バックオフ倍率を宣言的に指定でき、指数バックオフによる再試行が容易に組める。設計上の前提：再試行は同じ処理が複数回走ることを意味するため、処理は冪等に作る必要がある。誤答の理由：メモリの最大化はコスト増を招くだけ、VPC エンドポイントの削除は経路を壊し、タイムアウト 1 秒はむしろ失敗を増やす。

正解: A. Amazon CloudWatchダッシュボード＋アラーム

正解の根拠・詳細解説

CloudWatch ダッシュボード＋アラームが適する理由：①指標の集約表示：Glue のジョブ実行時間、Step Functions の実行成否、DMS のレプリケーション遅延、Kinesis の反復子の遅れなど、各サービスが出すメトリクスを 1 つのダッシュボードにまとめて時系列で表示できる。パイプライン全体の健全性を一目で把握でき、複数のコンソールを行き来する必要がなくなる、②SLA 違反の検知：「日次ジョブが所定の時刻までに成功していない」「処理遅延が閾値を超えた」といった条件をアラームとして定義し、SNS を通じて通知する。複数条件を組み合わせる複合アラームや、通常の変動幅から外れたときに発火する異常検知も利用できる、③独自指標：ジョブ内から PutMetricData でカスタムメトリクス（処理件数、鮮度を示す遅延秒数など）を送れば、ビジネス視点の SLA も監視対象にできる。実務上の勘所：失敗の検知だけでなく「動くはずのジョブが動いていない」欠測の検知も設定しておくことが重要。誤答の理由：Artifact は監査文書、Pinpoint は顧客向けメッセージング、License Manager はライセンス管理のサービスである。

正解: B. データガバナンス・監査証跡の確保

正解の根拠・詳細解説

CloudTrail の役割はガバナンスと監査証跡：①記録される内容：AWS API の呼び出しについて、いつ、どのプリンシパル（IAM ユーザーやロール）が、どのリージョンのどのリソースに対して、どの送信元 IP から操作を行い、結果がどうだったかをイベントとして記録する。これにより「誰が本番テーブルを削除したのか」「権限設定を変更したのは誰か」を事後に追跡できる、②2 種類のイベント：バケット作成やポリシー変更のような管理イベントは既定で記録される一方、S3 オブジェクトの GET／PUT のようなデータイベントは量が膨大になるため、必要な範囲を指定して有効化する（追加料金が発生する）、③活用方法：証跡を S3 に長期保管し、Athena でクエリして調査したり、CloudTrail Lake で分析したりできる。EventBridge と組み合わせれば、特定の危険な操作をリアルタイムに検知して通知することも可能。誤答の理由：コスト最適化は Cost Explorer や Budgets、データ変換の高速化は Glue や EMR、ストリーミング処理は Kinesis や MSK が担う領域であり、CloudTrail の目的ではない。

正解: A. Spark UIやYARNのログでステージごとの処理時間・データスキューを確認する

正解の根拠・詳細解説

Spark UI と YARN ログの確認が適する理由：①ステージ単位の可視化：Spark UI ではジョブ、ステージ、タスクの階層で実行状況が表示され、各ステージの所要時間、読み書きしたデータ量、シャッフルの量が分かる。特定のステージだけが極端に遅い場合、そのステージで何が起きているかを直接確認できる、②データスキューの発見：ステージ内のタスクごとの実行時間や入力レコード数を見て、大半のタスクが数秒で終わるのに一部だけが数十分かかっているなら、特定のキーにデータが偏っている典型的なスキューである。対策としては、結合キーにランダムなサフィックスを付ける salting、小さい側のテーブルのブロードキャスト結合、パーティション数の見直しなどが定石になる、③その他の観点：ログにメモリ不足やディスクへのスピル、GC の多発が現れていれば、エグゼキューターのメモリ設定やパーティション粒度が原因と判断できる。補足：Glue ジョブでも Spark UI を有効化して同様の分析ができる。誤答の理由：バケットポリシーや IAM ロールはアクセス権限の話であり、権限エラーでなければ性能劣化の原因にならない。クラスターの即時削除は調査手段を失う行為である。

正解: A. Glue Crawlerの定期実行とスキーマバージョニング

正解の根拠・詳細解説

Crawler の定期実行とスキーマ管理が適する理由：①変更の検知：Crawler をスケジュール実行すると、対象のデータストアを再スキャンして現在のスキーマを推定し、Data Catalog のテーブル定義と比較する。列の追加や型の変化を検出してカタログを更新できるため、上流のスキーマ変更に人手で追随する必要がなくなる、②更新ポリシーの制御：スキーマ変更時に「カタログを更新する」「変更を無視する」、削除されたオブジェクトに対して「パーティションを削除する」「非推奨としてマークする」といった挙動を選べる。下流の ETL を壊したくない場合は、勝手な更新を避ける設定にしてレビューを挟む運用も取れる、③バージョン管理：Data Catalog はテーブル定義の版を保持するため、いつどう変わったかを追跡でき、問題があれば以前の定義と比較できる。関連機能：ストリーミングデータの Avro や JSON については Glue Schema Registry を使うと、互換性ルールに基づいてスキーマ進化を検証し、非互換な変更を配信前に弾ける。誤答の理由：S3 バージョニングはオブジェクトの世代管理、DynamoDB Streams は項目変更の捕捉、Secrets Manager は資格情報管理であり、スキーマ定義の追随は行わない。

正解: A. Catchフィールド（エラーハンドリング）

正解の根拠・詳細解説

Catch フィールドが適する理由：①エラー時の分岐：ステートに Catch を定義すると、指定したエラー種別（サービス固有のエラー名、States.TaskFailed、あるいはすべてを捕捉する States.ALL など）が発生したときに、処理を異常終了させずに指定した別のステートへ遷移させられる。通知の送信、部分的なロールバック、代替ロジックの実行といったフォールバックを宣言的に組み込める、②エラー情報の受け渡し：ResultPath を指定すれば、発生したエラーの内容を後続ステートの入力に含められるため、通知メッセージに原因を載せる、といった実装が容易になる、③Retry との併用：同じステートに Retry と Catch を併記した場合、まず Retry による再試行が行われ、それでも解消しなければ Catch の遷移先へ進む。一時的な障害は再試行で吸収し、恒久的な失敗だけを代替経路に流す、という二段構えが基本形になる。誤答の理由：Parallel は複数分岐の同時実行、Wait は待機、Map は配列要素に対する反復処理を担うステートであり、いずれもエラーを捕捉して分岐させる機能ではない（ただしそれぞれのステートに Catch を付けることはできる）。

正解: A. ジョブのタイムアウト設定

正解の根拠・詳細解説

ジョブのタイムアウト設定が適する理由：①暴走の抑止：Glue のジョブ課金は、消費した DPU の量と実行時間に基づく。想定外の入力データ量やスクリプトの無限ループ、外部システムの応答待ちなどで実行が長引くと、そのまま課金が積み上がる。ジョブ定義でタイムアウト（分単位）を指定しておけば、上限に達した時点で強制終了され、被害を一定額で頭打ちにできる、②早期の異常検知：正常時の実行時間から見て明らかに長い値をタイムアウトに設定しておくと、それに達したこと自体が異常のシグナルになる。EventBridge で TIMEOUT 状態を検知して通知する運用と組み合わせると効果的、③関連する制御：ジョブの最大再試行回数を絞る、同時実行数の上限を設ける、ワーカータイプと数を過剰にしない、急ぎでない処理は Flex 実行にする、といった設定もコスト管理に効く。実務上の注意：タイムアウトを短くしすぎると正常なジョブが途中で落ちるため、実績値に余裕を持たせた値にする。誤答の理由：暗号化キーの長さ、IAM ポリシーのバージョン、VPC の CIDR はいずれも実行時間や課金と関係がない。

正解: A. Amazon CloudWatch Logs（必要に応じてOpenSearch Serviceと連携）

正解の根拠・詳細解説

CloudWatch Logs を軸にした集約が適する理由：①標準の集約先：Lambda、Glue、Step Functions、EMR、API Gateway、VPC フローログなど多くの AWS サービスが CloudWatch Logs を出力先として標準サポートしており、追加のエージェント構築なしにログが 1 か所へ集まる。EC2 やオンプレミスからも CloudWatch エージェントで送信できる、②検索と分析：CloudWatch Logs Insights を使えば専用のクエリ言語で複数ロググループを横断的に検索・集計でき、エラー件数の推移や特定リクエスト ID の追跡が行える。メトリクスフィルターでパターンを数値化してアラームにつなげることも可能、③高度な分析への拡張：全文検索やダッシュボードでの多角的な可視化、長期のログ分析が必要になったら、サブスクリプションフィルターから Firehose を経由して OpenSearch Service や S3 へ転送する。S3 に置いたログは Athena で分析でき、保管コストも抑えられる。誤答の理由：Pinpoint は顧客向けメッセージング、Certificate Manager は証明書管理、WorkSpaces は仮想デスクトップのサービスであり、ログ基盤としての機能を持たない。

正解: A. Concurrency Scaling

正解の根拠・詳細解説

Concurrency Scaling が適する理由：①一時クラスターの自動追加：同時実行クエリが増えてキューでの待ちが発生すると、Redshift が一時的なクラスターを自動で起動し、待機しているクエリをそちらへ振り向ける。需要が収まると自動的に解放されるため、ピークに合わせて常時大きなクラスターを維持する必要がなくなる、②利用者への透明性：接続先やクエリを変更する必要はなく、利用者からは単に待ち時間が短くなったように見える。有効化は WLM のキュー単位で行い、対象を特定のワークロードに絞ることもできる、③コスト：一定量の無料利用枠（クラスターの稼働に応じて付与されるクレジット）があり、それを超えた分が秒単位で課金される。常時逼迫しているならクラスター自体のサイズ見直しのほうが妥当で、突発的なピークにこそ効果的。誤答の理由：Elastic Resize はノード数を変更する操作で、手動かつ一時的な急増への即応には向かない。WLM キューの削除は待ち行列の制御を失うだけで悪化を招き、スナップショットの自動作成はバックアップ機能であり同時実行性には無関係である。

正解: A. メトリクスフィルター（特定パターンを検出してアラーム発火）

正解の根拠・詳細解説

メトリクスフィルターが適する理由：①ログのメトリクス化：CloudWatch Logs のメトリクスフィルターは、ロググループに届くログイベントを指定したパターン（特定の文字列、あるいは JSON ログの条件式）で照合し、一致した件数をカスタムメトリクスとして publish する。ログという非構造の情報を、アラームで扱える数値に変換する橋渡しの役割を果たす、②アラームへの接続：生成したメトリクスに対して「5 分間に 1 件以上」といった閾値のアラームを設定すれば、特定のエラーパターンが現れた瞬間に SNS 経由で通知できる。ジョブが失敗ステータスにならない部分的なエラーや、警告レベルの兆候も検知対象にできるのが利点、③補完的な手段：ジョブの成否そのものは EventBridge の状態変化イベントで捉えるほうが確実で、原因調査には Logs Insights のアドホッククエリが向く。これらを役割分担させると監視が過不足なく組める。誤答の理由：S3 イベント通知はオブジェクト操作の通知、DynamoDB Streams は項目変更の捕捉、Lake Formation はデータアクセス制御であり、いずれもログ文字列の監視には使えない。

正解: A. 開発・ステージング・本番の環境分離とCI/CDによる段階的デプロイ

正解の根拠・詳細解説

環境分離と段階的デプロイが適する理由：①影響範囲の限定：開発・ステージング・本番でアカウントまたは少なくとも環境を分離し、それぞれ独立したデータストアと権限を持たせることで、検証中の不具合が本番データを壊す事故を防げる。ステージングには本番に近い構成とマスキング済みの代表データを用意すると、性能やスキーマ起因の問題を事前に発見できる、②再現性：環境は CloudFormation や CDK、Terraform といった IaC で定義し、パラメータだけを変えて構築する。手作業の差異による「開発では動いたのに本番で失敗する」問題を減らせる、③段階的な反映：CI/CD パイプラインで自動テスト（変換ロジックの単体テスト、データ品質ルールの検証）を通過したものだけを次の環境へ進め、本番反映前に承認を挟む。問題があれば以前のバージョンへ切り戻せる状態を保つ。誤答の理由：本番での直接テストは障害を利用者に直撃させ、テストの省略は不具合の検出を遅らせるだけ。全ユーザーへの管理者権限付与は最小権限の原則に反し、誤操作と侵害の被害を最大化する。

正解: A. ソース・ターゲットのCDC遅延メトリクス（CDCLatencySource/Target）

正解の根拠・詳細解説

CDC 遅延メトリクスの確認が適する理由：①遅延の切り分け：DMS は CDCLatencySource と CDCLatencyTarget という 2 つのメトリクスを出力する。前者はソース側でコミットされた変更を DMS が取り込むまでの遅れ、後者は取り込んだ変更をターゲットへ適用し終えるまでの遅れを表す。どちらが大きいかを見れば、原因がソース側（トランザクションログの読み取りが追いつかない、長時間トランザクションの存在、ソース DB の負荷）にあるのか、ターゲット側（書き込みが追いつかない、インデックスや制約による負荷、ネットワーク）にあるのかを切り分けられる、②対処の方向性：ターゲット側が原因なら、バッチ適用モードの利用、ターゲットの不要なインデックスの削減やスペックの見直しを検討する。ソース側が原因なら、ソース DB の負荷軽減やレプリケーションインスタンスのサイズアップ、テーブルの分割（複数タスク化）が有効。補足：LOB 列の扱いは特に負荷が高いため、設定の見直しが効くことが多い。誤答の理由：S3 のバージョニング、IAM ロールの作成日時、Route 53 のレコードタイプはいずれもレプリケーション性能と無関係である。

正解: A. AWS Budgets＋Cost Explorer

正解の根拠・詳細解説

Cost Explorer＋AWS Budgets が適する理由：①実績の分析：Cost Explorer ではサービス別、リージョン別、リンクされたアカウント別、そしてコスト配分タグ別に費用を分解し、時系列で推移を確認できる。パイプラインの構成要素（Glue、EMR、Redshift、S3、データ転送）のどれが費用を押し上げているかを特定でき、フィルタと粒度を変えながら原因を掘り下げられる、②予算による予防：Budgets でコストや使用量の予算額を設定すると、実績が閾値を超えたときや、このままでは月末に超過すると予測されたときにアラート通知を出せる。事後の請求書で気付くのではなく、期中に手を打てるようになる、③前提となる準備：タグ別の分析を行うには、リソースにタグ（環境名、チーム名、パイプライン名など）を付与したうえで、請求設定でコスト配分タグを有効化しておく必要がある。有効化以降のデータが対象となる点に注意する。補足：予期しない急増は Cost Anomaly Detection で検知できる。誤答の理由：Detective はセキュリティ調査、Shield は DDoS 防御、Cognito は認証のサービスである。

正解: A. コストアロケーションタグ

正解の根拠・詳細解説

コストアロケーションタグが適する理由：①タグによる費用の分解：Glue ジョブや Redshift クラスター、S3 バケットといったリソースに「チーム名」「プロジェクト」「環境」などのキーと値を付与し、請求設定でそのタグキーをコスト配分タグとして有効化すると、Cost Explorer やコストと使用状況レポートでタグ別に費用を集計できるようになる。共有アカウント上で誰がどれだけ消費したかを可視化でき、チャージバックや利用状況の説明責任に使える、②タグの種類：利用者が自由に定義するユーザー定義タグのほか、AWS が自動付与するタグ（作成者情報など）も有効化できる、③運用上の注意：有効化した時点以降のデータが対象で、過去に遡って集計されるわけではないため、早い段階でタグ設計と有効化を済ませておくのが望ましい。またタグの付け忘れを防ぐには、IaC のテンプレートに標準タグを組み込み、Organizations のタグポリシーで表記ゆれを抑える運用が有効。誤答の理由：IAM ロールの信頼関係は誰がロールを引き受けられるかの定義、バケットポリシーはアクセス制御、VPC ピアリングはネットワーク接続であり、いずれも費用の分類には使えない。

正解: A. コンシューマー側の処理を強化する、または拡張ファンアウトを利用して並列処理を増やす

正解の根拠・詳細解説

コンシューマー側の増強が適する理由：①ボトルネックの所在：バックログ（IteratorAge の増大）はレコードが取り込めていないのではなく、読み取って処理する速度が到着速度に追いついていない状態を示す。したがって対策は読み取り・処理側の能力を上げることになる、②拡張ファンアウト：通常の共有スループットではシャードあたり 2MB／秒を全コンシューマーで分け合うが、拡張ファンアウトを使うとコンシューマーごとに専用の 2MB／秒が割り当てられ、HTTP/2 のプッシュ配信によりレイテンシも下がる。複数のアプリが同じストリームを読む構成で特に効果が大きい、③処理の並列化：Lambda を使う場合は、シャードあたりの並列化係数を上げる、バッチサイズを調整する、関数内の重い処理を非同期化するなどで消費速度を高められる。シャードを増やせば並列度の上限自体も上がる。誤答の理由：シャード数を減らすと読み取り可能な並列度が下がり悪化する。保持期間の短縮は未処理データを失うだけで処理速度は変わらない。プロデューサーの停止はデータ欠損を招く最後の手段であり、根本解決にならない。

正解: A. S3に配置したPythonライブラリをジョブのパラメータ（–extra-py-files等）で指定する

正解の根拠・詳細解説

S3 上のライブラリをジョブパラメータで指定する方式が適する理由：①共通ライブラリの再利用：社内共通の変換ロジックやユーティリティを .zip や .whl にまとめて S3 に置き、各 Glue ジョブの --extra-py-files に S3 パスを指定すれば、複数のジョブから同じライブラリを読み込める。ジョブごとにコードを複製しないため、修正が一箇所で済み、実装のばらつきを防げる、②外部パッケージの導入：PyPI で配布されているモジュールを使いたい場合は、--additional-python-modules パラメータにパッケージ名を指定してジョブ実行時にインストールさせる方法もある。ネイティブ拡張を含むものなど制約はあるため、事前にビルドした wheel を S3 に置く方式のほうが確実な場合もある、③バージョン管理：ライブラリの成果物は CI でビルドし、バージョン付きのオブジェクトキーで S3 に配置すると、どのジョブがどの版を使っているかを明確にでき、切り戻しも容易になる。誤答の理由：Lambda レイヤーは Lambda 専用の仕組みで Glue のジョブでは利用できない。IAM ポリシーは権限定義、CloudFront は配信のためのサービスであり、依存関係の管理手段ではない。

正解: A. Cost Explorerの日次コストグラフとサービス別ブレークダウンを確認する

正解の根拠・詳細解説

Cost Explorer による切り分けが適する理由：①時間軸での特定：日次（必要なら時間単位）の粒度でコストの推移を表示し、どの日から急増が始まったかを特定できる。増加の起点が分かれば、その前後に行ったデプロイや設定変更、データ量の変化と突き合わせて原因を絞り込める、②サービス別・要素別の内訳：サービス別に分解すれば、Glue の DPU 時間なのか、Redshift のノード稼働なのか、Athena のスキャン量なのか、S3 のリクエストやデータ転送なのかがすぐに分かる。さらに使用タイプやリージョン、タグ、リソース単位でフィルタを重ねれば、特定のジョブやクラスターまで辿り着ける、③補助的な仕組み：Cost Anomaly Detection を設定しておけば、通常の変動範囲を外れた支出を自動で検知して通知でき、気付くまでの時間そのものを短縮できる。データエンジニアリング特有の典型例：パーティションが効かずスキャン量が膨れ上がった Athena クエリ、終了漏れの EMR クラスター、想定外に大きくなった Glue のワーカー数などが挙げられる。誤答の理由：1 か月待つのは損失を拡大させ、全リソース削除や IAM ユーザー削除は原因究明にならず業務を停止させるだけである。

正解: A. Parallelステート（またはMapステート）

正解の根拠・詳細解説

Parallel／Map ステートが適する理由：①Parallel ステート：互いに独立した異なる処理を同時に走らせたい場合に使う。ブランチごとに別々の処理系列を定義でき、すべてのブランチが完了した時点で結果が配列としてまとめられ次のステートへ渡る。例えば「集計ジョブ」「品質チェック」「通知準備」を並行させて全体の所要時間を短縮できる、②Map ステート：入力配列の各要素に対して同じ処理を繰り返し適用する場合に使う。処理対象のファイル一覧やパーティション一覧を渡して並列に処理でき、同時実行数の上限を指定して下流サービスへの負荷を制御できる。大量データを扱うなら、S3 上のオブジェクトを直接入力として大規模に並列展開する分散マップも利用できる、③注意点：並列度を上げるほど Lambda の同時実行数や下流 API のレート制限に当たりやすくなるため、上限設定とリトライ方針をあわせて設計する。誤答の理由：Wait は一定時間待機するだけ、Pass は入力を加工して通過させるだけ、Fail は実行を失敗として終了させるステートであり、いずれも並列実行の手段ではない。

正解: A. CloudWatchアラーム→SNS→Lambda（Slack Webhook連携）

正解の根拠・詳細解説

CloudWatch アラーム→SNS→Lambda の構成が適する理由：①検知：ジョブの失敗回数、実行時間、遅延メトリクスなどにアラームを設定し、閾値を超えた時点で自動的に発火させる。人が画面を見張る必要がなくなり、検知の遅れをなくせる、②配信の分岐点：アラームの通知先を SNS トピックにすると、1 つのイベントを複数の購読者へ同時に配信できる。メールで運用チームに知らせつつ、Lambda で外部連携し、さらに別のキューへ流して記録する、といった拡張が容易になる、③外部サービス連携：Lambda 関数でアラームの JSON を受け取り、対象のジョブ名や発生時刻、原因のログへのリンクを整形して Slack の Incoming Webhook へ POST する。単なる通知にとどまらず、Systems Manager の Automation を呼び出して再実行する、インシデント管理システムにチケットを起票する、といった自動対応まで組み込める。実務上の注意：Webhook の URL は Secrets Manager などに保管し、通知の多発を防ぐためアラームの評価期間や複合アラームを調整する。誤答の理由：他の選択肢はいずれも通知の仕組みを構成しない無関係な操作である。

正解: A. ジョブのスケジュールや出力パスを分離し、書き込みの競合を避ける設計にする

正解の根拠・詳細解説

書き込み先とスケジュールの分離が適する理由：①S3 の特性：S3 はディレクトリ単位のロックやトランザクションを持たないため、複数のジョブが同一プレフィックスへ同時に書き込むと、中途半端なファイル群が読み取り側から見えたり、上書きモードのジョブが他方の出力を消してしまったりする。整合性の問題は権限や暗号化ではなく設計で解決する必要がある、②具体的な対策：出力先をジョブごと、あるいは実行日時やパーティション単位で分離し、書き込みが完了してから読み取り側に見せる（一時プレフィックスに書いてから正式なパスへ切り替える）。オーケストレーターで依存関係を定義して同時実行そのものを避ける、Glue ジョブの同時実行数を 1 に制限する、といった方法も有効、③トランザクション対応のテーブル形式：Apache Iceberg や Hudi といったテーブル形式を採用すると、スナップショット分離と原子的なコミットが提供され、同時書き込みや更新・削除を安全に扱える。近年のデータレイク設計ではこれが標準的な解になりつつある。誤答の理由：暗号化の無効化やタイムアウトの変更は競合と無関係で、IAM ロールの分離は権限の話であり同時書き込みそのものは防げない。

正解: A. ジョブ実行ログ・メタデータをS3やDynamoDBに保存し、Athenaなどで分析する

正解の根拠・詳細解説

実行メタデータの永続化が適する理由：①分析可能な形での保存：各ジョブ実行の開始・終了時刻、処理件数、入力データのサイズ、成否、エラー内容といったメタデータを構造化して S3（JSON や Parquet）や DynamoDB に蓄積すると、Athena で SQL 分析できるようになる。実行時間の推移からの性能劣化の検知、失敗の傾向分析、データ鮮度の SLA 遵守状況の報告などが可能になる、②保持期間の問題への対処：CloudWatch Logs や Step Functions の実行履歴には保持期間や参照の制約があり、長期のトレンド分析には向かない。独自にメタデータを残しておけば、数か月から数年単位の比較ができる、③運用への活用：処理済みパーティションの記録として使えば再実行時の重複を防げるし、データリネージ（どの入力からどの出力が生成されたか）の記録にもなり、障害時の影響範囲の特定が速くなる。誤答の理由：ログを削除すれば後追い調査が不可能になる。CloudTrail は API 呼び出しの監査記録であり、処理件数や業務的な結果までは分からない。パイプラインの再構築は調査手段ではない。

正解: A. DPU使用率やメモリ使用状況など、ジョブのパフォーマンスを詳細に可視化するため

正解の根拠・詳細解説

ジョブメトリクスを有効化する目的：①性能の可視化：有効化すると Glue が実行中のジョブについて、割り当てた DPU に対する実際の使用状況、アクティブなエグゼキューター数、必要とされている最大エグゼキューター数、ドライバーとエグゼキューターのメモリ使用率、シャッフルで読み書きしたデータ量などを CloudWatch に送信する。ジョブの内部で何が起きているかを、ログを読み解かずに時系列のグラフとして把握できる、②チューニングへの活用：エグゼキューターが常に余っていればワーカー数を減らしてコストを下げられる。逆にメモリ使用率が高くディスクへのスピルが多いなら、より大きなワーカータイプへ変更するか、パーティション数や処理ロジックを見直す判断ができる。並列度が上がらない場合は入力ファイルの分割状況を疑う、③運用監視：これらのメトリクスにアラームを設定すれば、データ量増加に伴う性能劣化の兆候を早期に捉えられる。補足：より深い分析が必要な場合は Spark UI を有効化してステージ単位の内訳を確認する。誤答の理由：暗号化キーの生成は KMS、IAM ロールやバケットの作成は別の管理操作であり、メトリクス機能とは関係がない。

正解: A. スタックの変更セット（Change Set）とロールバック機能

正解の根拠・詳細解説

変更セットとロールバックが適する理由：①事前の影響確認：変更セットを作成すると、テンプレートの更新を実際に適用する前に「どのリソースが追加・変更・削除されるか」「置換（replacement）が発生してリソースが作り直されるか」が一覧で示される。データベースやクラスターのように再作成が致命的なリソースについて、意図しない置換を実行前に発見できる点が最大の価値になる、②失敗時の自動復旧：スタック更新中にエラーが発生すると、CloudFormation は原則として更新前の状態へ自動的に巻き戻す。手作業で中途半端な状態を修復する必要がなく、本番環境の変更を安全に行える、③さらなる安全策：更新の途中経過を監視して条件を満たさなければ巻き戻すロールバック設定や、スタックポリシーによる重要リソースの保護、リソースの削除ポリシーとして Retain を指定してデータストアを守る、といった手段を組み合わせられる。実務上の指針：テンプレートはリポジトリで管理し、CI/CD の中で変更セットの作成と承認を挟むと、レビュー可能な変更管理が成立する。誤答の理由：S3 バージョニングやフローログはインフラ変更の管理機能ではない。

正解: A. IAMポリシーでResource条件にプレフィックスを指定する

正解の根拠・詳細解説

IAM ポリシーでリソースを限定する方式が適する理由：①最小権限の原則：ポリシーの Action に s3:GetObject を、Resource にバケットのプレフィックスまで含めた ARN（末尾にワイルドカードを付けた形）を指定することで、そのパス配下のオブジェクトだけに読み取りを限定できる。バケット全体や他部門のデータには一切触れられないため、事故と情報漏洩のリスクを最小化できる、②一覧取得の扱い：オブジェクトの一覧を取得させたい場合は、バケット自体を対象にした s3:ListBucket が別途必要になり、その際は条件キーで対象プレフィックスを制限するのが定石。これを忘れるとバケット全体の一覧が見えてしまう、③管理の効率：個々のユーザーに直接付けるのではなく、IAM グループやロールにポリシーを紐づけて運用すると、人事異動や担当変更に強い構成になる。アカウントをまたぐ場合はバケットポリシーとの併用も検討する。誤答の理由：全員への管理者権限付与は最小権限に真っ向から反し、バケットの公開設定は不特定多数に情報を晒す重大な誤り、ルートユーザーでの日常運用は監査性と安全性の両面で避けるべき運用である。

正解: B. SSE-KMS

正解の根拠・詳細解説

SSE-KMS が適する理由：①鍵利用の監査：暗号化・復号のたびに AWS KMS の API（GenerateDataKey や Decrypt）が呼び出され、その記録が CloudTrail に残る。どの ID がいつどの鍵を使ってデータへアクセスしたかを事後に追跡でき、監査要件やインシデント調査に応える証跡になる、②アクセス制御の二重化：キーポリシーや IAM ポリシー、付与（グラント）によって鍵の使用権限を制御できるため、たとえ S3 のオブジェクトを読む権限があっても鍵の使用を許可されていなければ復号できない。権限設計に多層防御を組み込める、③運用機能：カスタマー管理キーであれば、自動ローテーションの設定、無効化、削除のスケジュールといった鍵ライフサイクルの管理を自分で行える。コスト・性能上の注意：大量の小さなオブジェクトを扱うと KMS の API 呼び出し料金とスロットリングが問題になり得るため、S3 バケットキーを有効にして呼び出し回数を削減するのが実務上の定石。誤答の理由：SSE-S3 は AWS が完全に管理する鍵で、鍵単位の詳細な利用監査や権限制御はできない。SSE-C は鍵の管理責任をすべて自組織が負う方式である。

正解: A. Amazon Macie

正解の根拠・詳細解説

Amazon Macie が適する理由：①機微データの自動検出：S3 バケット内のオブジェクトを対象に、機械学習とパターンマッチングを用いて氏名、住所、メールアドレス、クレジットカード番号、各種識別番号といった個人情報や認証情報を検出する。組織固有の書式については、正規表現によるカスタムデータ識別子を定義して検出対象に加えられる、②レポートと通知：検出結果は重要度付きの「検出結果（findings）」として出力され、コンソールで確認できるほか、EventBridge や Security Hub と連携して通知や自動対応につなげられる。詳細な結果を S3 に保存して後から分析することも可能、③バケットの棚卸し：機微データの検出とあわせて、公開設定になっているバケットや暗号化されていないバケットの可視化も行うため、データレイクのガバナンス点検に有用。コスト面の注意：スキャン対象のデータ量に応じた課金となるため、対象バケットやサンプリング範囲、実行頻度を設計して無駄を抑える。誤答の理由：Shield は DDoS 防御、WAF は Web アプリケーションへの攻撃防御、GuardDuty は不審なアクティビティの脅威検知であり、いずれも保存データの内容分類は行わない。

正解: A. 列レベルセキュリティ（Column-level permissions）

正解の根拠・詳細解説

列レベルセキュリティが適する理由：①同じテーブルで見せ方を変える：Lake Formation ではテーブルの SELECT 権限を付与する際に対象列を限定でき、許可されていない列は問い合わせ結果に現れない（SELECT * でも返らない）。氏名やメールアドレスといった個人情報を含むテーブルを、分析チームには非個人情報の列だけ見せる、といった制御が 1 つのテーブルのまま実現できる、②運用上の利点：列を除いたビューや、マスキング済みのコピーテーブルを別途作る必要がなくなる。コピーを作る方式は実体が増えるほど同期漏れや権限設定漏れの温床になるため、権限層で解決できることの価値は大きい、③一貫した適用：この制御は Athena、Redshift Spectrum、EMR、Glue といった対応サービスから共通に効くため、経路によって見える情報が異なる事故を防げる。行レベルのデータフィルタと組み合わせれば、「担当地域の行だけ、かつ個人情報列は除く」といった条件も表現できる。誤答の理由：バケットポリシーはオブジェクト単位までしか制御できず列は扱えない。VPC エンドポイントポリシーは通信経路の制御、Crawler のスケジュールはメタデータ収集の設定である。

正解: A. AWS Organizations＋Service Control Policies（SCP）

正解の根拠・詳細解説

Organizations＋SCP が適する理由：①組織全体への一貫した制御：SCP は組織単位（OU）やアカウントに適用する権限の上限（ガードレール）で、そのアカウント内の IAM ユーザーやロールがどれだけ強い権限を持っていても、SCP で拒否された操作は実行できない。「特定リージョン以外の利用を禁止する」「CloudTrail の証跡を無効化させない」「暗号化されていない S3 への書き込みを禁じる」といった組織方針を、各アカウントの管理者の設定に依存せず強制できる、②注意点：SCP はあくまで許可の上限を定めるものであり、それ自体が権限を付与するわけではない。実際のアクセス許可は各アカウントの IAM ポリシーで別途与える必要がある。また管理アカウントには適用されない点にも留意する、③補完する仕組み：構成の逸脱検知には AWS Config のルール、組織全体の初期設定や継続的な統制には Control Tower、セキュリティ検出結果の集約には Security Hub を組み合わせるのが一般的な構成になる。誤答の理由：Cognito はアプリ利用者の認証、Direct Connect は専用線接続、Pinpoint は顧客向けメッセージングのサービスであり、組織統制の手段ではない。

正解: A. AWS Secrets Manager

正解の根拠・詳細解説

AWS Secrets Manager が適する理由：①シークレットの安全な保管：データベースの接続情報や API キーを KMS で暗号化して保管し、アプリケーションは実行時に API で取得する。コードや設定ファイル、環境変数に平文で書く必要がなくなり、リポジトリへの誤コミットによる漏洩を防げる。取得権限は IAM で制御し、アクセス履歴は CloudTrail に残る、②自動ローテーション：RDS や Redshift、DocumentDB などについては、Lambda によるローテーション処理が用意されており、指定した間隔でパスワードを自動更新できる。更新後の値はアプリが次回取得時に自然に受け取るため、パスワード変更のたびに設定を配り直す運用がなくなる、③データパイプラインでの使いどころ：Glue の接続定義や Lambda、EMR の処理から参照して、ソース DB や外部 SaaS の資格情報を安全に扱う。使い分け：ローテーションが不要で単純な設定値なら、より低コストな Systems Manager パラメータストア（SecureString）で足りる場合もある。誤答の理由：SNS は通知、Cognito はアプリ利用者の認証のサービス。CloudHSM は専用ハードウェアで鍵を管理する仕組みで、資格情報の保管とローテーションを担うサービスではない。

正解: A. VPCエンドポイント（Gateway型）

正解の根拠・詳細解説

Gateway 型 VPC エンドポイントが適する理由：①経路の閉域化：S3 と DynamoDB については Gateway 型エンドポイントを作成し、サブネットのルートテーブルにエンドポイント向けのルートを追加することで、通信が AWS のネットワーク内で完結する。インターネットゲートウェイや NAT ゲートウェイを経由しないため、プライベートサブネットのままセキュアに S3 へアクセスできる、②コスト面の利点：Gateway 型エンドポイント自体には時間課金やデータ処理料金がかからない。NAT ゲートウェイ経由で大量のデータを S3 とやり取りしていた場合、処理料金が丸ごと削減できるため、データパイプラインでは効果が大きい、③アクセス制御：エンドポイントポリシーで、そのエンドポイント経由で到達できるバケットや操作を制限でき、バケット側でも条件キーを使って特定 VPC エンドポイント以外からのアクセスを拒否できる。補足：多くのサービスは Interface 型（PrivateLink）を使うが、S3 は Gateway 型と Interface 型の両方に対応する。誤答の理由：インターネットゲートウェイやパブリックサブネット化は閉域の要件に反し、NAT ゲートウェイはインターネット経由の通信を前提とする。

正解: A. キーポリシーやローテーション設定など、より詳細な制御が可能

正解の根拠・詳細解説

カスタマーマネージドキー（CMK）の利点：①キーポリシーによる細かな制御：鍵ごとにポリシーを定義し、誰が暗号化・復号でき、誰が鍵を管理できるかを明示的に指定できる。アカウントをまたいだ利用の許可や、条件キーによる利用元の制限も可能で、データの機密度に応じて鍵を分けるといった設計が成り立つ、②ライフサイクル管理：自動ローテーションの有効化、鍵の無効化、待機期間を設けたうえでの削除スケジュールなど、鍵の状態を自分で管理できる。監査要件で鍵の管理主体や運用手順を示す必要がある場合に重要になる、③素材の持ち込み：要件によっては外部で生成した鍵素材のインポートや、専用の CloudHSM キーストアの利用も選べる。AWS マネージドキーとの違い：AWS マネージドキーは自動で作られ運用も自動化されている代わりに、キーポリシーの編集やローテーション周期の変更ができない。誤答の理由：CMK だから常に高速ということはなく、暗号化処理の性能は鍵の種別で決まるものではない。CMK には鍵ごとの月額と API 呼び出しの料金が発生するため無料でもなく、IAM による権限管理は依然として必要である。

正解: A. データ分類（タグ付け）を行い、分類ごとにポリシーを設計する

正解の根拠・詳細解説

データ分類を最初に行うべき理由：①統制の前提：どのデータがどの機密度に属するかが定義されていなければ、暗号化方式もアクセス権限も保持期間も決めようがない。分類は、後続のあらゆるセキュリティ設計が依拠する共通言語になる。まず「公開」「部内限定」「機密」といったレベルを定め、判断基準と責任者（データオーナー）を明確にする、②実装への落とし込み：分類結果はリソースのタグ、S3 のプレフィックス設計、Glue Data Catalog のテーブル属性、Lake Formation の LF-Tag として表現する。これにより「機密レベルのタグが付いたテーブルには特定のロールしかアクセスできない」といった規則を、テーブルが増えても破綻しない形で自動的に適用できる、③検出との連携：分類の網羅性を担保するには、Macie による個人情報のスキャン結果を突き合わせ、想定外の場所に機密データが混入していないかを継続的に点検する。誤答の理由：すべてを公開バケットに置くのは論外で、IAM ユーザーを 1 つに集約すると誰の操作か判別できず監査が成立しない。暗号化の無効化は運用を簡略化する代わりに保護を放棄する行為である。

正解: A. S3 Block Public Access（アカウントレベル設定）

正解の根拠・詳細解説

S3 Block Public Access のアカウントレベル設定が適する理由：①上位からの一括抑止：4 つの設定（新規のパブリックな ACL の拒否、既存のパブリック ACL の無視、新規のパブリックなバケットポリシーの拒否、パブリックなポリシーを持つバケットへのクロスアカウントアクセスの制限）をアカウント単位で有効にすると、個々のバケットの設定内容にかかわらずパブリック公開が抑止される。担当者が誤ってバケットポリシーを緩めたり、ACL を public-read にしたりしても、実際に公開されることはない、②事故の性質に合った対策：S3 の情報漏洩事故の多くは設定ミスに起因するため、個別の正しさに依存せず全体を塞ぐ「安全側に倒れる」設計が有効になる、③公開が必要な場合：静的コンテンツを配信したいなら、バケットは非公開のまま CloudFront のオリジンアクセスコントロール経由で配信する構成が推奨される。バケットを公開する必要はない。誤答の理由：バケットの削除はデータを失うだけ、CloudFront の無効化や VPC ピアリングの削除はいずれも S3 の公開設定と無関係で、パブリックアクセスの防止にはならない。

正解: A. セキュリティグループのインバウンドルール

正解の根拠・詳細解説

セキュリティグループのインバウンドルールが適する理由：①ネットワーク層での制御：Redshift クラスターは VPC 内に配置され、関連付けたセキュリティグループが仮想ファイアウォールとして働く。インバウンドルールで Redshift のポートに対する送信元を特定の CIDR（社内 NAT の固定 IP や VPN の出口など）に限定すれば、そもそも許可されていないネットワークからは接続要求すら届かない、②多層防御の考え方：IAM や Redshift のデータベースユーザー権限は「認証されたうえで何ができるか」を決めるものであり、接続元を絞る役割は持たない。ネットワーク制御と認証・認可を組み合わせることで、資格情報が漏れた場合でも接続元の制限が最後の防波堤になる、③関連する設定：クラスターを公開アクセス不可（パブリックアクセシビリティ無効）にしてプライベートサブネットに置き、必要な経路のみを許可するのが基本形。他のセキュリティグループを送信元として指定すれば、特定のアプリケーションサーバー群からのみ許可することもできる。誤答の理由：IAM ポリシー、KMS キーポリシー、S3 バケットポリシーはいずれも別レイヤーの権限制御であり、送信元 IP による接続制限を担うものではない。

正解: A. 最小権限の原則（Principle of Least Privilege）

正解の根拠・詳細解説

最小権限の原則（Principle of Least Privilege）とは：主体（IAM ユーザー、ロール、サービス）に対して、その業務を遂行するのに必要な操作とリソースだけを許可し、それ以外は与えないという設計原則である。①効果：認証情報の漏洩や設定ミス、悪意ある操作が起きたとしても、被害はその権限の範囲に限定される。データ基盤では、権限過剰なロールが本番テーブルを消す、機密データを別アカウントへ流出させるといった事故に直結するため特に重要になる、②実践方法：ワイルドカードでの Action や Resource の指定を避け、必要な API と特定の ARN に絞る。IAM Access Analyzer で実際の利用実績からポリシーを生成・精査し、未使用の権限を継続的に削る。長期のアクセスキーではなく、一時的な認証情報を返す IAM ロールを使う。条件キーで送信元 VPC エンドポイントやタグによる制約を加える、③組織的な補強：SCP や permissions boundary で権限の上限を定め、個別のポリシー付与が行き過ぎないようにする。誤答の理由：全許可は原則に反し、ゼロトラストは関連する考え方ではあるが「必要最小限の権限のみを付与する」という原則そのものを指す名称ではない。

正解: A. データのトレーサビリティ（どこに個人データが格納されているかの追跡）とデータ削除フローの整備

正解の根拠・詳細解説

トレーサビリティと削除フローの整備が必要な理由：①削除は「場所を特定できること」が前提：個人データはデータレイクの生データ、変換後のテーブル、データウェアハウス、バックアップ、ログ、キャッシュ、分析用の抽出ファイルなど多数の場所へ複製されていく。どこに何が存在するかを追跡できなければ、削除の網羅性を証明できず「忘れられる権利」に応えたことにならない、②実装の要点：データカタログに個人データを含むテーブルと列を登録し、Lake Formation の LF-Tag などで分類を明示する。データリネージを記録して派生先を辿れるようにし、個人を横断的に特定できる識別子（マスタ ID）を設計しておくと削除対象の抽出が確実になる、③削除の実行手段：S3 上の Parquet などは 1 行だけの削除が難しいため、Apache Iceberg や Hudi のような行レベルの削除に対応したテーブル形式を採用するか、対象パーティションを再生成する方式を用意する。削除の実施記録を残し、監査に対して証跡を示せるようにすることも要件になる。誤答の理由：暗号化キーの削除は復号不能にする手段としては議論があるが個々のユーザー単位の削除には使えず、バックアップの停止やアクセスログの削除は要件を満たさないばかりか監査性を損なう。

正解: A. Lake Formationでデータレイクの管理者（Data Lake Administrator）を設定する

正解の根拠・詳細解説

データレイク管理者の設定が最初に必要な理由：①権限委任の起点：Lake Formation はカタログのリソースに対する権限を自ら管理する仕組みであり、その権限を他のプリンシパルへ付与できるのはデータレイク管理者として登録された IAM プリンシパルである。管理者を設定しないと、誰も Lake Formation 経由の権限付与を開始できず、運用が始まらない、②移行の考え方：既定では従来どおり IAM ベースの制御も併用される状態から始まり、S3 の場所を Lake Formation に登録（データロケーションの登録）し、既定で付与されている広い権限を整理していくことで、Lake Formation を権限の一元的な管理点へ移していく。この移行手順を主導するのが管理者の役割になる、③運用上の注意：管理者は強い権限を持つため、対象を限定し、日常の分析利用者とは分離する。設定変更は CloudTrail で追跡できるようにしておく。補足：Lake Formation の権限は Athena、Redshift Spectrum、EMR、Glue といった対応サービスから共通に評価されるため、経路ごとの設定差異をなくせる点が導入の主目的になる。誤答の理由：IAM ユーザーやバケットの削除、暗号化の無効化は Lake Formation の利用開始とまったく関係がない。

正解: A. DynamoDB用のVPCエンドポイント（Gateway型）＋エンドポイントポリシー

正解の根拠・詳細解説

VPC エンドポイント＋エンドポイントポリシーが適する理由：①経路の限定：DynamoDB は Gateway 型の VPC エンドポイントに対応しており、これを作成してルートテーブルに関連付けると、VPC 内からの DynamoDB 宛通信が AWS ネットワーク内で完結する。NAT ゲートウェイやインターネットゲートウェイを経由しないため、プライベートサブネットのままアクセスでき、NAT の処理料金も削減できる、②アクセス元の制限：エンドポイントポリシーで、そのエンドポイント経由で操作できるテーブルやアクションを絞れる。さらにテーブル側（IAM ポリシー）で aws:sourceVpce や aws:SourceVpc といった条件キーを使い、指定した VPC エンドポイント以外からのリクエストを拒否すれば、「この VPC 内のリソースからのみアクセス可能」という要件を確実に満たせる、③設計上の意義：認証情報が外部に漏れたとしても、ネットワーク条件を満たさないため利用できない、という多層防御が成立する。誤答の理由：パブリック IP の割り当ては公開範囲を広げるだけで制限にならない。NAT ゲートウェイの削除は単に外向き通信を断つだけで許可元の限定にはならず、Route 53 のプライベートホストゾーンは名前解決の仕組みでありアクセス制御機能ではない。

正解: A. S3バケットポリシーでのクロスアカウント許可、またはIAMロールのAssumeRole

正解の根拠・詳細解説

バケットポリシーまたは AssumeRole が適する理由：①バケットポリシーによる直接許可：バケットポリシーの Principal に相手アカウントの ARN（アカウントや特定のロール）を指定し、必要な Action とプレフィックスに限定して許可する。相手側でもその IAM プリンシパルに対応する権限を付与する必要があり、双方の許可が揃って初めてアクセスできる、②ロールの引き受け：バケット所有者側にクロスアカウントの信頼関係を持つ IAM ロールを用意し、相手アカウントのプリンシパルが AssumeRole で一時的な認証情報を取得して操作する方式。権限の入口が 1 つのロールに集約されるため、監査と失効が容易で、外部 ID の指定によって不正な引き受けも防げる、③見落としやすい点：オブジェクトが SSE-KMS で暗号化されている場合、S3 の権限だけでは復号できず、KMS キーポリシー側でも相手プリンシパルに復号の使用を許可する必要がある。また別アカウントが書き込んだオブジェクトの所有権については、バケットの所有者強制設定を使うと扱いが単純になる。誤答の理由：パブリックアクセスの全許可は不特定多数への公開であり「安全な共有」に反する。KMS キーの削除はデータを復号不能にし、CloudFront は配信の仕組みである。

正解: A. スナップショットの共有設定（パブリック共有が無効になっているか）

正解の根拠・詳細解説

スナップショットの共有設定を確認すべき理由：①復元の起点はスナップショット：クラスター本体のネットワークやデータベース権限をどれだけ厳格にしても、スナップショットが第三者のアカウントから復元できる状態になっていれば、そこから独立したクラスターを立ち上げてデータを読み取られてしまう。したがって「どのアカウントに対して復元が認可されているか」を点検し、不要な共有が残っていないかを確認することが最優先になる、②暗号化との組み合わせ：スナップショットが KMS のカスタマー管理キーで暗号化されていれば、そのキーの使用を許可されていない相手は復元できない。共有の可否を鍵側でも二重に制御できるため、機密データを扱うクラスターは暗号化を有効にしたうえで鍵ポリシーを厳格に保つのが定石、③運用：共有の追加や削除は API 操作として CloudTrail に記録されるため、意図しない共有を検知するルールを用意しておくと変更を早期に把握できる。誤答の理由：ノードタイプは性能とストレージ構成、WLM キューの数はワークロード制御、VACUUM の頻度は保守処理の設定であり、いずれもスナップショットからの復元可否に影響しない。

正解: A. 自動キーローテーション（年次）の有効化

正解の根拠・詳細解説

自動キーローテーションが適する理由：①鍵素材の定期更新：カスタマー管理の対称キーで自動ローテーションを有効にすると、AWS KMS が定期的（既定では年に一度）に新しい鍵素材を生成し、以後の暗号化にはその新しい素材が使われる。長期間同じ鍵素材を使い続けるリスクを抑えられ、多くのコンプライアンス基準が求める鍵の更新要件に運用負荷ゼロで応えられる、②透過性：鍵 ID と ARN は変わらず、過去の鍵素材も保持され続けるため、古い素材で暗号化された既存データはそのまま復号できる。アプリケーションの設定変更やデータの再暗号化は不要で、これが「運用負荷を下げる」最大の理由になる、③適用範囲：自動ローテーションの対象は KMS が鍵素材を生成した対称キーであり、外部からインポートした鍵素材やカスタムキーストアの鍵などは対象外となるため、その場合は新しい鍵を作って切り替える手動の運用設計が必要になる。誤答の理由：鍵の削除予定を設定すると待機期間後に復号不能になり、キーポリシーの全削除は鍵を利用できなくする。マルチリージョンキーの無効化はローテーションとは無関係な設定である。

正解: A. 匿名化（Anonymization）

正解の根拠・詳細解説

匿名化（Anonymization）とは：個人を識別できる情報を、元の値へ戻せない形へ不可逆的に変換し、他の情報と照合しても個人を再識別できない状態にする処理を指す。具体的な手法には、識別子の削除、値の一般化（生年月日を年代に丸める、住所を都道府県までにする）、集計値への置き換え、ノイズの付与、k-匿名性などの基準を満たすようなグループ化がある。仮名化との違い：仮名化（Pseudonymization）は氏名を ID に置き換えるなど、対応表や鍵を持つ者は元に戻せる可逆的な処理であり、法規制上は依然として個人データとして扱われることが多い。分析基盤では「個人単位で追跡は必要だが氏名は不要」という場面で仮名化を使い、統計分析や外部提供のように再識別の必要がない場面で匿名化を選ぶ。AWS での実装：Glue の ETL 処理で列をハッシュ化・一般化する、Glue DataBrew の変換で処理する、Macie で対象となる個人情報の所在を特定してから処理設計を行う、といった流れが一般的。誤答の理由：暗号化は鍵があれば復元できるため不可逆な匿名化とは異なり、圧縮はデータ量の削減、レプリケーションは複製であって秘匿化処理ではない。

正解: A. AWS Config（マネージドルールによる継続的評価）

正解の根拠・詳細解説

AWS Config が適する理由：①継続的なコンプライアンス評価：Config はリソースの設定変更を記録し、あらかじめ定義したルールに照らして継続的に評価する。バケットのサーバーサイド暗号化の有効化やパブリックアクセスの禁止などはマネージドルールとして用意されており、自前で検査スクリプトを書かずに導入できる、②非準拠の検知と通知：評価結果は準拠／非準拠として一覧化され、EventBridge や SNS を通じて通知できる。さらに修復アクション（Systems Manager Automation）を紐づければ、非準拠を検出した際に自動で設定を是正することも可能、③組織全体への展開：コンフォーマンスパックとしてルール一式をまとめ、Organizations 経由で全アカウントへ配布できるため、アカウントが増えても統制水準を保てる。関連する仕組みとの違い：CloudTrail は「誰が何をしたか」という操作の記録、Config は「今どういう設定状態か、いつどう変わったか」という状態の記録であり、両者を併用することで監査が完成する。誤答の理由：Translate は翻訳、Snowcone はエッジ向けのデータ転送デバイス、Lex は会話ボットの構築サービスであり、構成監査の機能を持たない。

正解: A. ジョブが必要とする最小限のリソースへのアクセス権のみを持つ専用ロールを作成する

正解の根拠・詳細解説

ジョブ専用の最小権限ロールが適する理由：①影響範囲の限定：Glue ジョブに渡す IAM ロールは、そのジョブが実行するスクリプトの権限そのものになる。スクリプトの不具合や誤ったパスの指定があっても、権限が必要な範囲に限定されていれば他チームのデータを壊したり読み出したりする事故には至らない、②設計の具体例：入力用の S3 プレフィックスには読み取りのみ、出力用のプレフィックスには書き込みを許可し、Data Catalog は対象データベースのみ、RDS への接続に使う資格情報は Secrets Manager の特定のシークレットのみ取得可、CloudWatch Logs への書き込みは必要な範囲、といった形で個別に絞る。KMS で暗号化しているなら該当キーの使用許可も明示的に与える、③運用：ジョブ単位（あるいは用途が同じジョブ群の単位）でロールを分けることで、権限の棚卸しや削除がしやすくなる。IAM Access Analyzer で実際の利用実績を確認し、使われていない権限を継続的に削るとよい。誤答の理由：全リソースへのフルアクセスを持つ共通ロールは事故時の被害を最大化する。アクセスキーのコード直書きは漏洩リスクが高く、ルートユーザーの利用は日常運用として決して行ってはならない。

正解: A. リージョンごとにデータストアを分離し、クロスリージョン転送を制限する

正解の根拠・詳細解説

リージョン単位での分離が適する理由：①データレジデンシーの本質：規制は「データが物理的にどの国・地域に保存され処理されるか」を問う。AWS のリージョンは地理的に独立しているため、対象国に対応するリージョンへデータストア（S3、Redshift、DynamoDB など）を配置し、その中で処理を完結させることが要件充足の基本になる、②越境の制御：意図しない持ち出しを防ぐため、クロスリージョンレプリケーションやバックアップのコピー先を制限し、SCP や IAM の条件キー（aws:RequestedRegion など）で許可されないリージョンでの操作自体を禁止する。監査目的で CloudTrail や Config により構成を継続的に点検する、③運用上の課題：同じパイプラインをリージョンごとに展開することになるため、IaC でテンプレート化して構成の一貫性を保ち、横断的な分析が必要な場合は各リージョンで匿名化・集計した結果のみを共有する、といった設計上の工夫が要る。誤答の理由：グローバルに集約する構成はデータレジデンシー要件に真っ向から反する。暗号化や IAM ポリシーはデータ保護とアクセス制御には有効だが、保存場所そのものを規定する手段ではないため単独では要件を満たさない。

正解: A. S3 Object Lock（コンプライアンスモード）

正解の根拠・詳細解説

S3 Object Lock のコンプライアンスモードが適する理由：①WORM の実現：オブジェクトバージョンに保持期間を設定すると、その期間中は上書きも削除もできなくなる。コンプライアンスモードでは、アカウントのルートユーザーを含め誰も保持期間を短縮したり解除したりできないため、金融や医療などの規制が求める改ざん防止（Write Once Read Many）の要件を、運用ルールではなく仕組みとして担保できる、②2 つのモードの違い：ガバナンスモードは特別な権限を持つプリンシパルであれば保持設定を上書き・解除できるため、社内の誤削除防止には十分だが、規制対応としての強制力は弱い。要件に応じて使い分ける、③前提と補足：Object Lock を使うにはバケットのバージョニングが有効である必要がある。個別の保持期間に加えて、法的保持（リーガルホールド）を掛ければ期間を定めずに保護でき、解除するまで削除できない。運用上の注意：一度設定すると期間満了まで消せないため、保持期間の設計を誤ると不要なストレージ費用を長期間支払い続けることになる。誤答の理由：バージョニングだけでは新しいバージョンや過去バージョンの削除自体は可能で、ライフサイクルやレプリケーションは保護の仕組みではない。

正解: A. データリネージ（Data Lineage）

正解の根拠・詳細解説

データリネージ（Data Lineage）とは：あるデータがどのソースシステムから取り込まれ、どの処理を経て、どのテーブルやレポートに至ったかという来歴と依存関係を記録・可視化する仕組みを指す。①なぜ重要か：ダッシュボードの数値が誤っていたとき、上流のどの取り込みや変換に原因があるかを遡って特定できる。逆に、あるソースの障害やスキーマ変更が発生したとき、影響を受ける下流のテーブルと利用者を洗い出せる（影響波及分析）。個人データの削除要求に対して、どこまで派生が広がっているかを示す根拠にもなる、②粒度：テーブル単位のリネージに加え、列単位で「この集計列はどの入力列から計算されたか」まで追跡できると、監査や品質調査の精度が上がる、③実装：Glue のジョブ定義や Data Catalog のメタデータ、Step Functions や Airflow の DAG 定義から依存関係を抽出する、あるいは実行時のメタデータを独自に S3 や DynamoDB へ蓄積して可視化する構成が採られる。誤答の理由：データマイニングはデータから知見を抽出する分析手法、データウェアハウジングは分析用にデータを統合・蓄積する仕組み、データマートは特定部門向けに切り出した分析用データセットを指す用語である。

正解: A. IAMポリシーの変数（${aws:username}等）を使ったプレフィックス制御

正解の根拠・詳細解説

IAM ポリシー変数によるプレフィックス制御が適する理由：①ポリシーの共通化：Resource の ARN に ${aws:username} のような変数を埋め込むと、リクエストを行った主体に応じて実際の対象パスが動的に解決される。「home/<ユーザー名>/ 配下のみ操作できる」という 1 本のポリシーを全員に適用すれば、ユーザーが増減してもポリシーを書き足す必要がない。管理対象が線形に増えないため、運用の破綻を防げる、②実装上の注意：オブジェクト操作の許可に加え、一覧取得（s3:ListBucket）はバケットを対象にした権限になるため、条件キーで対象プレフィックスを自分のパスに限定しないとバケット全体の一覧が見えてしまう。この設定漏れは典型的な落とし穴である、③応用：ロールを使った運用では、タグの値を参照する条件キーを用いた属性ベースのアクセス制御（ABAC）にすると、部門タグやプロジェクトタグに応じたアクセス範囲を同じ考え方で表現できる。誤答の理由：ユーザーごとにバケットを無制限に作る方式はアカウントあたりのバケット数や管理コストの面で現実的でない。全員への管理者ポリシー付与は分離になっておらず、バケットの削除はデータを失うだけである。

正解: A. VPCエンドポイントの活用

正解の根拠・詳細解説

VPC エンドポイントの活用が適する理由：①通信経路の保証：VPC エンドポイントを使うと、対象の AWS サービス宛の通信が AWS のネットワーク内で処理され、パブリックインターネットを経由しなくなる。S3 と DynamoDB はルートテーブルに経路を追加する Gateway 型、それ以外の多くのサービス（KMS、Secrets Manager、Glue、Kinesis、CloudWatch Logs など）は VPC 内に ENI を作成する Interface 型（PrivateLink）を使う、②付随する利点：エンドポイントポリシーで到達できるリソースや操作を制限でき、サービス側のリソースポリシーでも「特定の VPC エンドポイント経由のみ許可」という条件を課せる。データ持ち出しの経路を絞れるため、機密データを扱う基盤で有効。加えて NAT ゲートウェイ経由の大量転送に伴う処理料金を削減できる、③設計上の注意：Interface 型はエンドポイントごとに時間課金とデータ処理料金が発生するため、必要なサービスを見極めて配置する。プライベート DNS を有効にすると通常のサービスエンドポイント名のまま利用できる。誤答の理由：インターネットゲートウェイの追加やパブリック IP の付与はむしろインターネット経路を前提とし、NAT インスタンスも外部経由の通信である。

正解: A. 動的データマスキング（Dynamic Data Masking）

正解の根拠・詳細解説

動的データマスキング（DDM）が適する理由：①問い合わせ時のマスキング：Redshift の動的データマスキングは、列に対してマスキングポリシーを定義し、ロールやユーザーに紐づけて適用する。実データはそのまま保持されたまま、権限のない利用者が SELECT したときに値が伏せ字や部分表示、ハッシュ化された形で返る。データを複製・加工することなく、同じテーブルを見せ方だけ変えて共有できる点が最大の利点、②柔軟な表現：完全な置き換えだけでなく、下 4 桁のみ表示するといった部分マスクや、ロールごとに異なるマスク結果を返す設定ができるため、業務要件に合わせた粒度で調整できる、③運用上の効果：マスク済みのビューやコピーテーブルを別途作る方式は、対象が増えるほど同期漏れや権限設定漏れの温床になる。ポリシー側で一元管理できることで、監査時にも制御内容を説明しやすい。補足：列そのものを見せない制御が必要なら列レベルの権限、行を絞るなら行レベルセキュリティと、目的に応じて機能を使い分ける。誤答の理由：クラスターの再起動、WLM の優先度変更、スナップショットの削除はいずれもデータの表示制御とは無関係な操作である。

正解: A. AWS Security Hub

正解の根拠・詳細解説

AWS Security Hub が適する理由：①検出結果の集約：GuardDuty の脅威検知、Macie の機微データ検出、Inspector の脆弱性評価、IAM Access Analyzer の外部公開検出、さらにサードパーティ製品の結果までを、共通のフォーマット（AWS Security Finding Format）に正規化して 1 か所に集める。サービスごとに画面を回る必要がなくなり、対応の抜け漏れを防げる、②優先度付け：検出結果に重要度と関連リソースの情報が付与され、フィルタやインサイトによって「本番アカウントの重大な検出結果」といった観点で絞り込める。限られた対応リソースをリスクの高いものへ集中させられる、③継続的なチェック：CIS ベンチマークや AWS 基礎的セキュリティのベストプラクティスといったセキュリティ標準に対する自動チェックを有効化すると、構成の逸脱を継続的に評価してスコアとして把握できる、④自動化：検出結果は EventBridge のイベントとして扱えるため、通知やチケット起票、Lambda による自動修復に接続できる。Organizations と連携すれば全アカウントの結果を管理アカウントへ集約できる。誤答の理由：Comprehend は自然言語処理、Outposts はオンプレミス向けインフラ、Chime はコミュニケーションサービスである。

正解: A. AWS CloudTrail

正解の根拠・詳細解説

AWS CloudTrail が適する理由：①管理イベントの記録：IAM ポリシーの作成・変更・削除（CreatePolicy、PutRolePolicy、AttachRolePolicy、DeletePolicy など）はいずれも AWS API の呼び出しであり、CloudTrail に管理イベントとして記録される。イベントには実行時刻、呼び出し元のプリンシパル（IAM ユーザーやロール、引き受け元の情報）、送信元 IP、リクエストパラメータ、成否が含まれるため、「誰が・いつ・どのポリシーを・どう変更したか」を後から正確に追跡できる、②証跡の保全：証跡（トレイル）を作成して S3 に長期保管し、バケットには適切な権限とライフサイクル、必要なら Object Lock を設定して改ざん・削除から守る。ログファイルの整合性検証を有効にすれば、後から改変されていないことを確認できる、③活用：保管したログは Athena でクエリして調査でき、CloudTrail Lake を使えば SQL による分析が容易になる。EventBridge と組み合わせれば、特権的な変更をリアルタイムに検知して通知できる。関連：現在の設定状態やその変遷を評価したい場合は AWS Config を併用する。誤答の理由：CloudFront は配信、X-Ray は分散トレーシング、Kinesis Video Streams は映像データの取り込みサービスである。

正解: A. 設計の初期段階からセキュリティとガバナンスを組み込む「Security by Design」の徹底

正解の根拠・詳細解説

Security by Design が最も重要である理由：①手戻りコストの非対称性：暗号化方式、アカウントとネットワークの分離、権限モデル、データ分類、保持期間といった要素は、パイプラインの構造そのものに影響する。稼働後に変更しようとすると、既存データの再暗号化や移行、権限の再設計、下流システムへの影響調査が必要になり、費用も停止リスクも跳ね上がる。設計段階で織り込めば、追加コストはごくわずかで済む、②具体的な実践：保管時・転送時の暗号化を既定とし、最小権限のロールを用途ごとに用意する。データを分類したうえで Lake Formation の権限や列レベル制御を設計に組み込み、CloudTrail と Config で監査証跡と構成監視を最初から有効化する。インフラは IaC で定義し、CI/CD の中で静的解析やポリシーチェックを通す（いわゆるシフトレフト）、③組織的な担保：SCP によるガードレール、Security Hub による継続的な評価、インシデント対応手順の整備を組み合わせ、個々の担当者の注意力に依存しない仕組みにする。誤答の理由：後付け対応は是正コストと露出期間を増やし、コスト優先でのセキュリティ省略や暗号化の任意化は、規制違反と情報漏洩による損失を招く典型的なアンチパターンである。