AWS データ分析スペシャリティ (DAS-C01) 模擬試験 65問

A) Kinesis Data Firehose B) Kinesis Data Streams C) SQS FIFOキュー D) Amazon MSK

答え: B

解説: Kinesis Data Streamsはパーティションキーに基づく順序保証、最大7日間（デフォルト24時間）のデータ保持、リアルタイム再処理が可能です。Firehoseは再処理不可、SQS FIFOはスループット制限があります。

A) シャード数を増やす B) Enhanced Fan-Outを有効にする C) Provisionedモードに切り替える D) GetRecords APIの呼び出し頻度を下げる

答え: B

解説: Enhanced Fan-Outは、登録された各コンシューマーにシャードあたり2MB/sの専用スループットを提供します。標準のGetRecordsはシャードあたり2MB/sをすべてのコンシューマーで共有しますが、Enhanced Fan-Outは各コンシューマーに専用の帯域幅を割り当てます。

A) Lambdaトランスフォーム + プレフィックス式 B) フォーマット変換 + Dynamic Partitioning C) Glue ETLジョブの統合 D) S3 Object Lambdaの使用

答え: B

解説: Kinesis Data FirehoseのFormat Conversion機能でJSONをParquet/ORCに変換し、Dynamic Partitioningでレコードのフィールドをjqまたはインラインパーシングで抽出してS3プレフィックスを動的に設定します。

A) AWS Glue ETLで定期的にテーブル全体をコピー B) AWS DMS + 継続的レプリケーションタスク C) Kinesis Data Streams + Lambda D) Snowball Edgeで初期ロード後にDirect Connect

答え: B

解説: AWS DMSはソースデータベースのトランザクションログを読み取りCDCを実装します。初期フルロード後、継続的レプリケーションタスクで変更のみをリアルタイム同期します。OracleからRedshiftへの異種マイグレーションではSCT（Schema Conversion Tool）も使用します。

A) AWS Direct Connect専用線を構築する B) Snowball Edge Storage Optimizedを複数注文する C) AWS Snowmobileを使用する D) S3 Transfer Accelerationを有効にする

答え: C

解説: ペタバイト規模（100PB以上）のデータ転送にはSnowmobileが適切です。各Snowmobileは最大100PBを保存できます。この規模ではインターネットやDirect Connectでの転送は時間がかかりすぎてコストが高くなります。

A) Kinesis Data Streams — スケーラビリティが高い B) Amazon MSK — Kafka互換性と長い保持期間をサポート C) Kinesis Data Firehose — 完全マネージド D) SQS — メッセージ保持が長い

答え: B

解説: Amazon MSKは完全マネージドのApache Kafkaサービスで、既存のKafkaクライアントコードをそのまま使用できます。保持期間を無期限に設定でき、長期保存に有利です。KinesisはKafka APIと互換性がありません。

A) シャード数を2倍にする B) パーティションキーにランダムプレフィックスを追加してシャードを均等分散させる C) Enhanced Fan-Outを有効にする D) KPL Aggregationを無効にする

答え: B

解説: ホットシャード（特定のパーティションキーへの書き込み集中）問題は、パーティションキーを分散させることで解決します。パーティションキーの先頭にランダムなプレフィックス（例：0〜Nの数値）を付けて複数のシャードに均等分配します。

A) Tumbling Window B) Sliding Window C) Session Window D) Global Window

答え: B

解説: Sliding Windowは固定サイズのウィンドウが一定間隔でスライドします。例えば、30分サイズのウィンドウを1分間隔で移動させると、常に最新の30分間のデータを基準に計算できます。Tumbling Windowは重複しない固定区間です。

A) 単一パーティション: year/month/day B) 複合パーティション: year/month/day/region C) パーティションなしでAthena Partition Projectionを使用 D) すべてのデータを単一プレフィックスに保存して圧縮

答え: B

解説: クエリパターンに合わせて日付とリージョンコードを組み合わせてパーティション化すると、Athenaがスキャンするデータを最小化できます。year/month/day/region構造の階層的パーティション化により、両方のフィルター条件でパーティションプルーニングを活用できます。

A) S3バケットポリシーで特定のプレフィックスへのアクセスを制限 B) Glueカタログのリソースベースポリシーでテーブルレベルの制限 C) Lake Formation列レベルセキュリティ（Column-level security）の設定 D) Athenaワークグループごとにクエリフィルターを設定

答え: C

解説: Lake Formationはテーブル、列、行レベルの細粒度アクセス制御をサポートします。列レベルセキュリティを使用すると、特定のIAMロール/ユーザーに特定の列のみを表示するよう制限できます。S3バケットポリシーはファイルレベルのみで列単位の制御が不可能です。

A) 両テーブルともEVEN分散 B) 両テーブルともALL分散 C) 大きなファクトテーブルはKEY分散（結合キー）、小さなディメンションテーブルはALL分散 D) 両テーブルともAUTO分散

答え: C

解説: 大型ファクトテーブル間の結合では、同じ結合キーでKEY分散を適用すると、データが同じノードに配置されローカルで結合でき、ネットワーク転送が最小化されます。小規模なディメンションテーブルはALL分散ですべてのノードにコピーし、ブロードキャスト結合のオーバーヘッドを削減します。

A) FilterExpressionを使用したScan操作 B) KeyConditionExpressionにUserIDとOrderDateの範囲条件を指定したQuery操作 C) GSIを作成してQueryを実行 D) DynamoDB Streams + Lambdaでインデックスを維持

答え: B

解説: テーブルの主キー（UserIDパーティションキー、OrderDateソートキー）を使用したQueryが最も効率的です。KeyConditionExpressionに「UserID = :uid AND OrderDate >= :date」の条件を設定して、特定ユーザーの特定日付以降の注文を効率的に取得します。Scanはテーブル全体を読み取るため非効率です。

A) コンピューティングとストレージを独立してスケールするため B) インメモリキャッシュによる最高のクエリパフォーマンス達成のため C) クエリを自動的に並列処理するため D) S3のデータに直接アクセスするため

答え: A

解説: Redshift RA3ノードはコンピューティングとストレージを分離し、それぞれ独立してスケールできます。頻繁にアクセスされるデータはローカルNVMe SSDにキャッシュされ、残りはS3ベースのRedshift Managed Storage（RMS）に保存されます。データの増加に伴いコンピューティングコストを増加させずにストレージだけを拡張できます。

A) すべてのデータをHotストレージで保持 B) Hot → UltraWarm → Coldストレージへの階層移動 C) 30日以降のデータをS3にエクスポート D) Index State Managementで30日後にデータを削除

答え: B

解説: OpenSearch ServiceはHot（高速SSD、頻繁アクセス）、UltraWarm（S3ベース、低コスト、たまにアクセス）、Cold（さらに低コスト、まれにアクセス）のストレージ階層を提供します。Index State Management（ISM）で自動階層移動ポリシーを設定するとコスト最適化とアクセスパターンのバランスを管理できます。

A) 自動ファイル圧縮によるストレージコスト削減 B) ACIDトランザクションサポートと自動データコンパクション C) リアルタイムストリーミングデータの取り込み D) 列レベル暗号化の自動適用

答え: B

解説: Lake Formation Governed TablesはS3データにACIDトランザクション（原子性、一貫性、独立性、耐久性）をサポートし、同時読み書き操作でデータの一貫性を保証します。自動コンパクションで小さなファイル問題を解決し、行レベルセキュリティもサポートします。

A) S3データをCSV形式で保存 B) S3データをParquet形式で保存してパーティション化を適用 C) Redshiftクラスターのノード数を最大化 D) Spectrumスライスあたりのファイル数を1つに制限

答え: B

解説: Redshift SpectrumはParquetやORCなどの列指向形式で最高のパフォーマンスを発揮します。列プルーニング（必要な列のみ読み取り）とパーティションプルーニング（必要なパーティションのみ読み取り）の組み合わせでスキャンデータを大幅に削減できます。CSVはファイル全体を読む必要があります。

A) マスター、コア、タスクノードすべてにSpotを使用 B) マスターとコアはOn-Demand、タスクノードのみSpotを使用 C) マスターはOn-Demand、コアとタスクはSpotを使用 D) すべてのノードをReservedインスタンスで構成

答え: B

解説: EMRでマスターノードはクラスター管理を担い、コアノードはHDFSデータを保存します。マスターとコアノードをOn-Demandで安定性を確保し、タスクノード（追加コンピューティング専用）のみSpotで使用することで、Spot中断時もデータ損失なくコストを削減できます。

A) DynamicFrameはスキーマがなくすべてのデータ型を処理できる B) DynamicFrameはスキーマの不一致（choiceタイプ）を許容し、relationalizeなどAWS固有の変換を提供する C) DataFrameが常に速いのでDynamicFrameは使わない方がよい D) DynamicFrameは構造化ストリーミングのみサポートする

答え: B

解説: AWS Glue DynamicFrameは列内に複数の型が混在する場合をchoiceタイプで表現します。resolveChoice()、relationalize()などのAWS特化変換メソッドを提供します。パフォーマンスが重要な場合はDynamicFrameをDataFrameに変換して処理後、DynamicFrameに戻すことができます。

A) Glueクローラーを毎分実行するようにスケジュールする B) AthenaのMSCK REPAIR TABLEまたはADD PARTITIONコマンドを使用 C) Lake Formation blueprintsで自動パーティション管理 D) S3イベント通知でLambdaをトリガーしてGlueカタログのパーティションを更新

答え: D

解説: S3 ObjectCreatedイベントでLambdaをトリガーしてglue:BatchCreatePartition APIを呼び出すと、新しいパーティションのみを効率的に追加できます。AthenaのMSCK REPAIR TABLEも可能ですが、パーティションが多いほど遅くなります。Lambdaを通じた自動パーティション登録が最も効率的です。

A) EMR Serverlessは永続的なクラスターを維持し、EMR on EC2は一時的なクラスターを使用 B) EMR Serverlessはクラスタープロビジョニングなしで自動スケールし、アイドル時にコストが発生しない C) EMR ServerlessはHiveのみサポートし、Sparkはサポートしない D) EMR on EC2が常にコスト効率が高い

答え: B

解説: EMR Serverlessはジョブを送信するだけでクラスターを自分で管理する必要なくリソースが自動的にプロビジョニングされます。ジョブがない時はコストが発生しません。Spark、Hiveなどをサポートし、断続的なバッチワークロードに最適です。

A) 大規模分散Spark ETL処理 B) コードなしのビジュアルデータ準備とクレンジング C) リアルタイムストリーミングデータの変換 D) データカタログメタデータ管理

答え: B

解説: AWS Glue DataBrewはコードを書かずにビジュアルインターフェースでデータの探索、クレンジング、正規化ができるサービスです。250以上のあらかじめ構築された変換を提供し、データ品質ルールの定義やプロファイリングもサポートします。データアナリストやデータサイエンティストに適しています。

A) Lambdaでポーリングして失敗時に再起動 B) Step Functionsの状態定義にRetryブロックを追加 C) CloudWatch AlarmでEMRの失敗を検出してSNS通知 D) Glue WorkflowでEMRジョブをラップ

答え: B

解説: Step Functionsの各タスク状態にRetryブロックを追加すると、指定したエラータイプに対して自動リトライを行います。リトライ回数、間隔、バックオフ比率を設定できます。Catchブロックで最終的な失敗時の代替パスも設定できます。

A) Glueジョブのワーカー数を減らす B) coalesce()またはrepartition()で書き込み前の出力パーティション数を調整する C) S3 Lifecycleポリシーで小さなファイルを自動削除 D) Kinesis Firehoseでファイルをマージ

答え: B

解説: Sparkでcoalesce(N)でシャッフルなしにパーティション数を減らすか、repartition(N)で均等に再分配してから書き込むと出力ファイル数を制御できます。coalesceはシャッフルなしにパーティションを減らしますが不均等になる可能性があり、repartitionは均等ですがシャッフルコストが発生します。

A) Lambda関数のメモリを増やす B) シャードあたりの並列化係数（Parallelization Factor）を増やす C) バッチサイズ（Batch Size）を減らす D) Lambdaの予約済み同時実行数を増やす

答え: B

解説: Kinesis-Lambdaイベントソースマッピングの並列化係数（1〜10）を増やすと、各シャードから同時に複数のLambda呼び出しを処理できます。デフォルト値1はシャードごとに1つの同時Lambda実行です。並列化係数を10にすると同じシャードから最大10個のLambdaが並列実行されます。

A) Athenaクエリ結果の再利用（Query Result Reuse） B) Athena連合クエリ（Federated Query） C) CTASで結果を保存 D) Athenaワークグループのクエリキュー

答え: A

解説: AthenaのQuery Result Reuse機能を有効にすると、同じクエリに対して指定した期間（最大7日）内の以前の結果を再利用します。スキャンコストが発生しないため、繰り返しクエリのコストを大幅に削減できます。データが変更されない場合に効果的です。

A) 毎時MSCK REPAIR TABLEを実行 B) Athena Partition Projectionを設定 C) 毎時ALTER TABLE ADD PARTITIONを実行 D) Lake Formationでパーティションを自動管理

答え: B

解説: Athena Partition Projectionを使用するとパーティションメタデータをGlueカタログに保存せずにテーブル定義のルールでパーティションを動的に計算します。規則的なパターン（日付、数値範囲）のパーティションに特に効果的で、パーティション登録の管理オーバーヘッドがありません。

A) 両テーブルがKEY分散で結合が効率的 B) 一方のテーブルがALL分散ですべてのノードにコピーされているため結合が効率的 C) EVEN分散でデータの再分配が必要 D) 分散キーがなくブロードキャスト結合不可

答え: B

解説: DS_DIST_ALL_NONEは結合の一方のテーブルがALL分散（すべてのノードにコピー）されているため、データの再分配（redistribution）が不要であることを意味します。これは効率的な結合パターンです。DS_DIST_ALL_INNERは再分配コストがあることを示します。

A) Direct QueryモードでRedshiftに直接接続 B) SPICEにデータをインポートしてスケジュール更新を設定 C) AthenaでS3データに直接クエリ D) QuickSight Paginated Reportsを使用

答え: B

解説: SPICE（Super-fast Parallel In-memory Calculation Engine）はQuickSightのインメモリストレージで、数億行でも超高速なクエリと可視化をサポートします。スケジュール更新でデータを定期的に更新できます。Direct Queryはリアルタイムですが大容量では応答が遅くなる場合があります。

A) クラスターにノードを追加する B) 短いクエリ優先処理（Short Query Acceleration）を有効にする C) すべてのクエリに同じ優先度を付ける D) 長時間クエリを夜間のみ実行するようスケジュールする

答え: B

解説: RedshiftのShort Query Acceleration（SQA）は機械学習を使用して短時間クエリを予測し、専用のキューで優先処理します。別のWLMキューの設定なしで、短時間と長時間クエリが混在する環境を最適化できます。

A) 各営業担当者ごとに別々のデータセットを作成 B) QuickSight RLS（Row-Level Security）ルールをデータセットに適用 C) IAMポリシーでS3データへのアクセスを制限 D) Athenaビューでユーザーごとにデータをフィルタリング

答え: B

解説: QuickSight RLSはユーザー/グループとフィルター値をマッピングしたルールファイル（CSVまたは別のデータセット）をデータセットに連結します。ログインしたユーザーに応じてデータが自動フィルタリングされます。単一のデータセットで複数のユーザーに各自のデータのみを表示できます。

A) S3データレイクとRDS、DynamoDBなどの異種データソースを単一SQLで結合 B) RedshiftとS3データを一緒にクエリ C) 複数のAWSアカウントのS3バケットを単一クエリで処理 D) リアルタイムストリーミングデータをSQLで分析

答え: A

解説: Athena Federated QueryはLambdaベースのデータソースコネクタを使用してS3以外のデータソース（RDS、DynamoDB、ElastiCache、CloudWatch、Redisなど）でSQLを実行します。複数の異種ソースを単一クエリで結合でき、データ統合分析に有用です。

A) Refresh Intervalを1秒に短縮する B) Bulk APIを使用してRefresh Intervalを延長する C) 各ドキュメントごとにIndex API呼び出しを行う D) シャード数を最大化する

答え: B

解説: OpenSearch/Elasticsearchで大量インデックス時にBulk APIで複数のドキュメントをバッチ処理するとネットワークオーバーヘッドを削減します。Refresh Intervalを延長する（デフォルト1秒から30秒以上に）とセグメント作成頻度が減りインデックス処理量が大幅に向上します。

A) S3バケットポリシーだけで細粒度のデータアクセス制御が可能 B) Lake Formationのデータ権限でテーブル/列/行レベルのアクセス制御 C) IAMポリシーでGlueカタログへのアクセスを制御 D) S3アクセスポイント（Access Points）でプレフィックスごとにアクセス制御

答え: B

解説: Lake FormationはGlueデータカタログと統合し、論理的なテーブル、列、行レベルの細粒度アクセス制御を提供します。物理的なS3ファイルパスではなく論理的なデータ構造に基づいて権限を付与します。S3バケットポリシーはファイル/プレフィックスレベルのみで列・行レベル制御が不可能です。

A) S3サーバー側暗号化（SSE-S3）を有効にする B) Kinesisストリームでサーバー側暗号化（SSE）を有効にし、aws/kinesis KMSキーを選択する C) KMSのカスタマー管理キー（CMK）を作成してKinesisに接続する D) クライアント側暗号化でデータを送信する

答え: B

解説: Kinesis Data Streamsはサーバー側暗号化（SSE）をサポートします。AWSマネージドキー（aws/kinesis）を選択すると追加設定なしでKMSによりすべてのストリームデータが暗号化されます。CMKを使用するとより細かいキーポリシー制御が可能ですが追加設定が必要です。

A) RedshiftクラスターにパブリックIPを割り当てる B) NAT GatewayでS3にアクセスする C) S3用のVPCエンドポイント（ゲートウェイエンドポイント）を設定する D) Direct ConnectでAWSネットワークに接続する

答え: C

解説: S3ゲートウェイVPCエンドポイントをVPCに設定すると、RedshiftからS3へのCOPY/UNLOAD操作がAWSプライベートネットワーク経由で行われます。インターネットゲートウェイやNAT Gatewayなしにもアクセスでき、セキュリティが強化されデータ転送コストも削減されます。

A) S3サーバー側暗号化で自動的に処理される B) Glueセキュリティ構成（Security Configuration）でメタデータ暗号化を有効にする C) KMSキーをGlueカタログテーブルに直接接続する D) Lake Formationでメタデータへのアクセスを制御する

答え: B

解説: AWS Glue Security ConfigurationでGlueデータカタログのメタデータ暗号化を有効にするとKMSキーでメタデータを暗号化します。Glue ETLジョブのデータ暗号化（転送中、保存時）やジョブブックマーク暗号化もSecurity Configurationで設定します。

A) PIIを削除した別のS3バケットのコピーを分析チーム用に維持する B) Lake Formationの列レベルセキュリティ + S3 Object Lambdaで動的マスキング C) 分析チームのIAMロールでS3バケット全体のアクセスを拒否し特定プレフィックスのみ許可 D) Glue ETLで毎日PIIを削除したデータセットを生成

答え: B

解説: Lake Formationの列レベルセキュリティでPII列をブロックするか、S3 Object LambdaでLambda関数によりデータ読み取り時に動的にPIIをマスクできます。この方法はデータのコピーが不要で、マスキングロジックを一元管理できます。

A) CloudTrailでRedshift API呼び出しを記録する B) RedshiftのAudit LoggingをS3に対して有効にする C) VPC Flow LogsでRedshiftのネットワークトラフィックを記録する D) CloudWatch LogsでRedshiftの接続を記録する

答え: B

解説: Redshift Audit Loggingは接続ログ、ユーザーアクティビティログ、ユーザーログをS3に保存します。ユーザーアクティビティログは実行されたすべてのSQLクエリを記録します。コンプライアンス監査に必要なWho/What/Whenの情報を完全に提供します。CloudTrailはRedshift APIの呼び出しのみ記録します。

A) Kinesis Firehose → S3 → Athena（すべての要件を満たす） B) Kinesis Data Streams → Lambda（リアルタイム不正検知）+ Firehose → S3（バッチ）+ Glue + Redshift（レポート） C) MSK → Spark Streaming → DynamoDB D) SQS → Lambda → RDS → QuickSight

答え: B

解説: リアルタイム処理（100ms）のためにKinesis Data StreamsからLambdaで即座に処理し、同時にFirehoseでS3に保存します。バッチ処理はGlue ETLでS3データを加工してRedshiftにロードし、日次レポートを生成します。3年間のデータはS3 Intelligent-Tieringでコスト効率よく保管します。

A) S3サーバー側暗号化（KMS）を有効にする B) Redshiftの転送中暗号化（SSL/TLS）を強制する C) CloudFrontでデータを配布する D) パブリックS3バケットにデータを保存する E) 暗号化なしのKinesisストリームを使用する

答え: A、B

解説: HIPAA準拠には保存時の暗号化（S3 SSE-KMS）と転送中の暗号化（SSL/TLS）が必須です。VPC内デプロイ、アクセスログ、監査証跡も必要ですが、この選択肢ではAとBが核心です。オプションDとEはHIPAA違反です。

A) S3 DistCpでデータをコピーし、Glueクローラーでメタデータを再生成 B) Snowballファミリーで物理データ移行後、SCTでメタデータ変換 C) AWS DataSyncでデータをコピーし、GlueカタログへのインポートでHiveメタストアを移行 D) DMSで全体を移行

答え: C

解説: AWS DataSyncはオンプレミスHDFSからS3への大規模データ転送を並列転送と自動整合性検証で効率的に行います。GlueカタログはHiveメタストアと互換性があり、インポート機能でメタデータを移行できます。EMRは既存のHiveクエリをそのまま実行できます。

A) ファイルサイズを最小化してファイル数を増やす B) ファイルサイズを128MB〜1GBに最適化して分割可能（splittable）形式を維持する C) 圧縮を無効にしてファイル読み取り速度を向上させる D) より小さなパーティションに細分化する

答え: B

解説: Athenaはファイルを並列に読み取る際に各ファイルを分割します。Parquetファイルはデフォルトで分割可能ですが、最適サイズ（128MB〜1GB）に維持することで最大の並列処理が可能になります。SnappyやZSTD圧縮と組み合わせるのが最良です。

A) Glueジョブの実行履歴の追跡 B) すでに処理されたデータを追跡して増分処理を実現する C) Glueジョブのコスト最適化 D) データ品質チェックポイントの保存

答え: B

解説: Glue Job Bookmarksは以前の実行で処理されたデータを追跡します。次の実行時に新しく追加されたデータのみを処理し、重複処理を防ぎます。S3のファイル更新時刻とファイル名を基に処理状態を判断します。全データの再処理なしに効率的な増分ETLパイプラインを実現できます。

A) すべての参照データをFlinkメモリにロードする B) Flink Async I/Oで外部データベースに非同期ルックアップを行う C) 参照データをKinesisストリームとして送信して結合する D) Lambda関数でエンリッチメントして再度Kinesisに送信する

答え: B

解説: Flink Async I/Oは外部データベース（Redis、DynamoDBなど）へのルックアップを非同期で処理し、ストリーミング処理のレイテンシーを最小化します。同期ルックアップでは外部システムの応答待ちでスループットが大幅に低下しますが、Async I/Oは複数のリクエストを同時に処理します。

A) 各外部ユーザーにQuickSightの標準ユーザーアカウントを作成 B) QuickSight埋め込みURL API + 匿名埋め込みまたはリーダー（Reader）セッション C) QuickSightの公開ダッシュボードリンクを共有 D) S3にダッシュボード画像をエクスポートしてWebに表示

答え: B

解説: QuickSight Embedding APIを使用すると、外部ユーザーがQuickSightアカウントなしでダッシュボードを閲覧できます。匿名埋め込み（非認証アクセス）またはリーダーセッション（時間限定URL）を生成してWebアプリケーションに埋め込みます。アクセスあたりの料金モデルが適用されます。

A) すべてのレコードが削除される B) 処理失敗レコードは設定されたS3プレフィックス（処理失敗プレフィックス）に別途保存される C) Firehoseが自動的にリトライして成功するまで待機する D) 失敗レコードが元のソースに返される

答え: B

解説: Kinesis Data FirehoseのLambda変換で失敗したレコードは、処理失敗（processing-failed）プレフィックスのS3パスに保存されます。成功したレコードは指定されたS3の宛先に、失敗したレコードは別のパスに保存されるため、後で再処理やエラー分析に活用できます。

A) 各アカウントのS3データを中央アカウントにコピーする B) Lake Formationのクロスアカウントデータ共有機能を使用する C) S3クロスアカウントレプリケーションを設定する D) AWS Organizations SCPでデータアクセスを統合する

答え: B

解説: Lake Formationはクロスアカウントデータ共有をサポートします。データ所有アカウントから中央アカウントのIAMロール/ユーザーにLake Formationのデータ権限を付与します。中央アカウントからAthenaやRedshift Spectrumで他のアカウントのデータカタログをクエリできます。データ移動なしに中央集中型ガバナンスを実現します。

A) HiveクエリをSparkに自動変換する B) S3データのUPSERT/DELETEと増分処理のサポート C) EMRクラスターの自動スケーリング D) HDFSとS3間の自動データ同期

答え: B

解説: Apache HudiはS3などのデータレイクストレージにUPSERT（挿入/更新）、DELETE操作をサポートし、従来のデータレイクの不変性の制限を克服します。Copy-on-WriteとMerge-on-Readテーブルタイプを提供し、増分クエリで変更されたデータのみを効率的に処理できます。

A) Glue ETLジョブのメモリ不足問題を解決する B) 複数のデータソースのデータをほぼリアルタイムでレプリケート・統合するマテリアライズドビューを提供する C) Glueクローラーのスキーマ検出エラーを修正する D) Athenaクエリ結果を自動的にキャッシュする

答え: B

解説: AWS Glue Elastic ViewsはDynamoDB、Aurora、RDSなどのソースデータをOpenSearch、S3、Redshiftなどのターゲットに自動的にレプリケートし、マテリアライズドビューを維持します。SQLベースのビュー定義で複雑なETLパイプラインなしにデータ統合を実現します。

A) すべてのS3操作を自動的に暗号化する B) アクセスパターンを自動的にモニタリングして最もコスト効率の高いストレージ階層に自動移動する C) S3データの自動バックアップを作成する D) グローバルデータレプリケーションの自動化

答え: B

解説: S3 Intelligent-Tieringはアクセス頻度をモニタリングして、頻繁にアクセスされるデータをFrequent Access、30日以上未アクセスのデータをInfrequent Access、90日以上をArchive Instant Accessに自動移動します。アクセスパターンが予測不可能なデータレイクに特に適しており、モニタリング費用のみ追加されます。

A) 不要なデータベース接続を終了する B) 削除/更新された行を整理してソートキー順にデータを再整列する C) Redshiftクラスターのキャッシュを初期化する D) テーブル統計を更新する

答え: B

解説: Redshift VACUUMはDELETE/UPDATEでマークのみされた行を実際に削除し、ソートキー順にデータを再整列します。定期的なVACUUMでストレージを回収してクエリパフォーマンスを維持します。ANALYZEはテーブル統計を更新します。Redshift Serverlessと最新バージョンは自動VACUUMをサポートします。

A) 新しいコンシューマーグループを作成すると最初から自動的に再処理される B) GetShardIterator APIでAT_TIMESTAMPオプションを使用して特定の時刻から読み取りを開始する C) FirehoseでS3から再処理する D) 保持期間内のデータを新しいストリームにコピーする

答え: B

解説: Kinesis GetShardIterator APIのShardIteratorTypeをAT_TIMESTAMPに設定して希望のタイムスタンプを指定すると、そのタイミングからデータを読み取ることができます。KCL（Kinesis Client Library）を使用する場合は初期位置をタイムスタンプで設定できます。

A) 単一のメタデータレジストリで複数の分析エンジン間でスキーマを共有して一貫性を維持する B) データ処理速度の向上 C) S3ストレージコストの削減 D) 自動データ品質検証

答え: A

解説: GlueデータカタログはAWSの中央メタデータストアです。Athena、Redshift Spectrum、EMRが同じGlueカタログを参照するため、テーブル定義、パーティション情報、スキーマを一か所で管理します。スキーマ変更がすべての分析エンジンに自動反映されます。

A) CloudWatch AlarmsでS3ファイルサイズをモニタリングする B) AWS Glue Data Qualityルールで自動検証する C) Lambdaで手動のデータ検証スクリプトを実行する D) SNSでデータチームに手動レビューの通知を送る

答え: B

解説: AWS Glue Data Qualityはデータセットに品質ルール（完全性、一意性、参照整合性など）を定義し、ETLジョブ中に自動的に検証します。品質スコアとルールの合否結果を提供し、CloudWatchとの統合で品質低下時にアラートを送ることができます。

A) EMR on EC2よりも常にコストが低い B) 既存のKubernetesインフラを活用してSparkジョブを実行し、コンテナベースのワークロードを統合する C) HDFSストレージをEKSクラスターに設定できる D) GPU基盤のディープラーニング専用

答え: B

解説: EMR on EKSは既存のAmazon EKSクラスターでApache Sparkを実行します。すでにKubernetesベースのインフラを使用している組織が、別途EMRクラスターなしにデータ処理ワークロードを統合管理できます。コンテナの分離、リソース共有、既存のKubernetesツール（Helm、Argo Workflowsなど）との統合が利点です。

A) クラスターノードを自動的に追加して永続的に拡張する B) クエリの同時実行数がピーク時に追加のクラスターキャパシティを自動的にプロビジョニングしてSLAを維持する C) Redshiftクラスターを自動的にアップグレードする D) 夜間のバッチ処理を自動的にスケジュールする

答え: B

解説: Redshift Concurrency Scalingは同時クエリ数が増加してメインクラスターが飽和状態になると、追加の読み取りクラスターを自動的に起動します。1日あたり最初の24時間は無料で、以降は秒単位の料金が発生します。ユーザーは遅延なく一貫したクエリパフォーマンスを経験します。

A) いいえ、DMSがスキーマ変換を自動的に処理する B) はい、Aurora MySQLとRedshiftは異なるデータベースエンジンなのでSCTによるスキーマ変換が必要 C) いいえ、AuroraとRedshiftは同じAWSサービスなので不要 D) SCTはオンプレミスデータベースのみに必要

答え: B

解説: DMSはデータ移動を担当し、SCTはスキーマ（DDL、プロシージャ、関数など）の変換を担当します。Aurora MySQL（OLTP）からRedshift（OLAP）への異種マイグレーションはデータ型やテーブル構造などの変換が必要なため、SCTを先に実行してRedshift互換のDDLを生成する必要があります。

A) 各チームに別々のAWSアカウントを作成する B) Athenaワークグループ（Workgroup）でチーム別にクエリを分離、コストを追跡、データ使用量を制御する C) CloudWatchコストアラームでチーム別の予算をモニタリングする D) IAMタグでクエリコストを追跡する

答え: B

解説: Athenaワークグループはチーム/プロジェクト別にクエリを分離し、各ワークグループのクエリコストとデータスキャン量を別途追跡します。ワークグループ別のクエリあたりデータスキャン制限、結果保存場所の指定、CloudWatchメトリクス統合が可能です。コスト割り当てタグと組み合わせてチーム別のコスト請求ができます。

A) 機械学習モデルを直接訓練してデプロイする B) 時系列データの異常値検出、予測、自動ナラティブの生成 C) SageMakerモデルの結果をQuickSightに表示する D) A/Bテスト結果の分析

答え: B

解説: QuickSight ML Insightsはコードなしで時系列の異常検知（Anomaly Detection）、予測（Forecasting）、自動ナラティブ（Auto-narratives）機能を提供します。Amazon ForecastとRandom Cut Forestアルゴリズムを内部で使用し、データサイエンティストなしでもビジネスユーザーがMLベースのインサイトを得られます。

A) データレイクセキュリティポリシーのテンプレート B) 一般的なデータソース（RDS、DMSなど）からS3データレイクへのデータ取り込みワークフローを自動化する C) Glue ETLジョブのコードを自動生成する D) QuickSightダッシュボードのテンプレート

答え: B

解説: Lake Formation Blueprintsは一般的なデータ取り込みパターン（データベーススナップショット、増分データベース、ログファイル）のための事前設定されたワークフローを提供します。内部的にGlueクローラーとETLジョブを自動生成し、データレイク構築の複雑さを軽減します。

A) GlueジョブをPython Shellに切り替える B) groupFilesオプションで小さなファイルをグループ化し、ワーカー数を増やす C) データをまずRedshiftにロードしてからParquetにアンロードする D) Lambda関数チェーンで並列変換する

答え: B

解説: Glue ETLのgroupFiles設定で小さなファイルを論理的にグループ化して処理パーティション数を最適化し、ワーカー数（DPU）を増やして並列処理を向上させます。Sparkが内部的にデータを並列パーティションで処理するため、十分なDPUを割り当てることで並列性が活用されます。

A) CloudWatchメトリクスでCPUUtilizationを確認する B) STL_QUERY、STL_EXPLAIN、SVL_QUERY_SUMMARYシステムテーブルを分析する C) RedshiftのAudit LogでクエリIDを検索する D) CloudTrailでAPI呼び出しを追跡する

答え: B

解説: Redshiftのシステムテーブルでクエリパフォーマンスを分析します。STL_QUERYは完了したクエリの情報、STL_EXPLAINはクエリプラン、SVL_QUERY_SUMMARYは各ステップ別の実行統計を提供します。EXPLAINコマンドで実行計画を確認してデータ分散、結合戦略、ソートキーの効率性を分析します。

A) 両方の条件を満たす必要がある場合にS3にデータを送信する B) 2つの条件のうち先に満たされた条件に応じてS3にデータを送信する C) Buffer Sizeのみを基準に送信する D) Buffer Intervalのみを基準に送信する

答え: B

解説: Kinesis FirehoseはBuffer Size（MB）とBuffer Interval（秒）のどちらかが先に満たされた時にS3にデータを配信します。例えば5MB、60秒の設定時、5MBが蓄積されるか60秒が経過するか（いずれか先に到達した条件で）S3にフラッシュします。

A) テーブルのすべての読み取り（Read）操作 B) テーブルへの書き込み（Put、Update、Delete）変更を24時間保持 C) テーブルスキャン操作のみを記録する D) GSI/LSIの作成および削除イベント

答え: B

解説: DynamoDB Streamsはテーブルのアイテムレベルの変更（INSERT、MODIFY、REMOVE）をキャプチャします。変更前後のイメージを最大24時間保持します。Lambdaトリガーと組み合わせてイベント駆動アーキテクチャ、リアルタイム集計、他システムとの同期に活用します。

A) すべてのデータをRedshiftに移動して分析する B) AWS Glueカタログ + Athena連合クエリ + Lake Formationの統合ガバナンス C) 各ソースに適した別々の分析ツールを使用する D) すべてのデータをDynamoDBに統合する

答え: B

解説: AWS Glueカタログを中央メタデータストアとして、Athena連合クエリで異種ソースに単一SQLを実行し、Lake Formationで統合セキュリティとガバナンスを実装することが最も包括的なソリューションです。データ移動なしに現在位置で分析し、単一のアクセス制御ポリシーを適用できます。