模擬問題集一覧

DEA-C01 模擬問題集（練習問題）

AWS Data Engineer – Associate 合格に向けた本番形式の模擬問題集。すべての問題に詳しい解説と、ドメイン別の弱点分析つき。

4 練習テスト 200 問 合格ライン 70% 各 120 分

この模擬問題集で身につくこと

  • 本番と同じ形式・難易度の問題で実力を確認
  • 制限時間つきの試験モードで時間配分を体得
  • 演習モードで1問ずつ解説を読みながら学習
  • すべての問題に正解の根拠つきの詳しい解説
  • ドメイン別スコアで弱点分野をひと目で把握
  • 完了後も何度でも復習して本番前に仕上げ

練習テストの内容

4 テスト · 全 200 問
1
模擬問題集①先頭 15 問 無料
50 問 120 分 合格 70%
2
模擬問題集② プラン限定
50 問 120 分 合格 70%
3
模擬問題集③ プラン限定
50 問 120 分 合格 70%
4
模擬問題集④ プラン限定
50 問 120 分 合格 70%

説明

DEA-C01（AWS Data Engineer – Associate）の合格に向けた、本番形式の模擬問題集です。全 200 問を4 回の練習テストに分割し、 試験モード／演習モードで受験できます。各問題には正解の根拠と誤答の理由を記した詳しい解説が付き、受験後はドメイン別のスコアで弱点を把握できます。 各試験は先頭の問題から無料でお試しいただけます。

月額 ¥980 で全 200 問＋全解説が受け放題

模試プラン（¥980/月）なら、ロックされた練習テストと詳しい解説、ドメイン別の弱点分析がすべて使い放題。本番に向けて実力を仕上げましょう。

DEA-C01 の操作は、実機のハンズオンラボで身につける

問題集で覚えた知識を、本物の Azure・AWS 環境で手を動かして確かめられます。 Pro プランなら DEA-C01 対応のハンズオンラボ 3 本と、この問題集の全 200 問がすべて使えます。 ラボは会員登録だけで 1 本無料で試せます。

DEA-C01 の対応ラボを見る（3 本）ラボを 1 本無料で試す

DEA-C01 の出題範囲（カバーしている分野）

全 200 問を、本番の試験ガイドに沿った次の分野から出題しています。 受験後はドメイン別の正答率が表示され、弱点が特定できます。 難易度・学習時間・合格までの進め方はDEA-C01 の学習ガイドにまとめています。

DEA-C01 の無料練習問題（15 問・解説つき）

会員登録なしで、全 200 問のうち 15 問を正解と解説つきでご覧いただけます。 問題をクリックすると選択肢と解説が開きます。

問題 1これらの要件を満たすルールはどれですか？データ運用とサポート
問題
あるデータエンジニアは、複数の都市と州の売上情報を含む 2 つのデータセットを持っています。一方のデータセットは reference という名前で、もう一方は primary という名前です。 データエンジニアは、primary データセットの city 列と state 列に含まれる特定の値の集合が、reference データセットの同じ特定の値と完全に一致するかどうかを判定するソリューションを必要としています。データエンジニアは、AWS Glue Data Quality ジョブで Data Quality Definition Language (DQDL) ルールを使用したいと考えています。 これらの要件を満たすルールはどれですか？

選択肢と解説

  • 1
    DatasetMatch "reference" "city->ref_city, state->ref_state" = 1.0
  • ✓
    ReferentialIntegrity "city,state" "reference.{ref_city,ref_state}" = 1.0
  • 3
    DatasetMatch "reference" "city->ref_city, state->ref_state" = 100
  • 4
    ReferentialIntegrity "city,state" "reference.{ref_city,ref_state}" = 100

解説

【正解】B

【0からの解説】
AWS Glue Data Quality は、DQDL（Data Quality Definition Language）という宣言的なルール記述言語でデータ品質を検証する機能です。本問のように「primary データセットのある列の値の集合が、別の reference データセットの列の値の集合と一致しているか」を確認したいときに使うのが ReferentialIntegrity（参照整合性） ルールです。

ReferentialIntegrity は、primary 側の指定列に出現する値の集合のうち、どれだけの割合が reference 側の指定列に存在するかを「0.0〜1.0 の比率」で評価します。完全一致（100%）を要求する場合は = 1.0 と書きます。複数列を組にして比較する場合は primary 側を "city,state"、reference 側を "reference.{ref_city,ref_state}" のように波括弧で対応列をまとめて指定します。したがって正しいルールは B です。

判定の決め手は (1) 2 つのデータセット間で値の集合一致を見る → ReferentialIntegrity、(2) 一致度は比率 0.0〜1.0 で表す → 完全一致は 1.0、という DQDL の仕様です。

【誤りの選択肢】
A：DatasetMatch は 2 つのデータセットの行同士をキーで突き合わせて一致度を見るルールで、構文は "city->ref_city, ..." のようなマッピング形式ですが、本問の「特定の値の集合が一致するか」という参照整合性のユースケースには ReferentialIntegrity がより適合します。加えて、しきい値の与え方は両ルールとも比率で考えるのが基本で、本問の意図には B が合致します。
C：DatasetMatch である点に加え、しきい値を「100」としているのが誤りです。Glue Data Quality の一致系ルールのしきい値は割合（0.0〜1.0）で指定し、100% を表すのは 1.0 です。「= 100」は有効なしきい値になりません。
D：ルール種別（ReferentialIntegrity）は適切ですが、しきい値を「100」にしているのが誤りです。完全一致は「= 1.0」と表記する必要があります。

【参考】
ReferentialIntegrity ルール（AWS Glue DQDL）
Data Quality Definition Language (DQDL) リファレンス
この問題のページを開く →
問題 2最も短いクエリ時間（SHORTEST query times）でこれらの要件を満たすソリューションはどれですか？データの取り込みと変換
問題
ある e コマース企業は、毎日の顧客取引ログを CSV 形式で収集し、Amazon S3 に保存しています。同社は Amazon Athena を使用して、各ログを受信したその日のうちにログから属性のサブセット（一部の列）をスキャンします。 取引量の増加に伴いクエリ時間が長くなっています。同社はクエリパフォーマンスを改善したいと考えています。 最も短いクエリ時間（SHORTEST query times）でこれらの要件を満たすソリューションはどれですか？

選択肢と解説

  • ✓
    CSV ログを、Athena での並列性を高めるために複数の ORC ファイルに変換する。Amazon S3 で日付ごとにパーティション分割する。列指向プッシュダウンフィルタ（columnar pushdown filters）を使用する。
  • 2
    CSV ログを JSON に変換する。Amazon S3 で日付ごとにパーティション分割する。Athena で動的フィルタリング（dynamic filtering）を使用してスキャン量を削減する。
  • 3
    CSV ログを Avro に変換する。Amazon S3 で日付ごとにパーティション分割する。Athena で射影ベースのパーティショニング（projection-based partitioning）を使用する。
  • 4
    CSV ログを 1 日ごとに 1 つの Apache Parquet ファイルに変換する。Amazon S3 で日付ごとにパーティション分割する。Athena で述語プッシュダウンフィルタ（predicate pushdown filters）を使用する。

解説

【正解】A

【0からの解説】
Athena はサーバーレスのクエリサービスで、S3 からスキャンしたデータ量に応じて課金・処理されます。クエリを速くする鍵は「スキャンするデータ量を減らす」ことと「並列に読み取る」ことの 2 点です。

本問は「属性のサブセット（一部の列）だけをスキャンする」ワークロードなので、行指向の CSV/JSON/Avro よりも、列だけを読み出せる 列指向フォーマット（ORC や Parquet） が圧倒的に有利です（必要な列だけを読む列プルーニング）。さらに「日付ごとにパーティション分割」すれば対象日のデータだけをスキャンでき（パーティションプルーニング）、列指向プッシュダウンで不要なデータブロックの読み取りもスキップできます。

A と D はどちらも列指向＋日付パーティション＋プッシュダウンで似ていますが、決め手は「並列性」です。Athena は 1 つのクエリを多数のリーダーで分散処理するため、データが複数ファイルに分かれているほど並列度が上がり高速になります。A は「複数の ORC ファイル」にして並列性を高めると明記しているのに対し、D は「1 日 1 ファイルの単一 Parquet」にまとめてしまうため、その日のクエリを 1 ファイルしか並列に分割できず、並列度が下がってかえって遅くなる可能性があります。最短のクエリ時間という要件には A が最適です。

【誤りの選択肢】
B：JSON は行指向のテキスト形式で、一部の列だけを効率的に読めず、CSV と同様にスキャン量が大きくなります。「動的フィルタリング」はこの列サブセット高速化の本質ではありません。
C：Avro は行指向のバイナリ形式で、列サブセットのクエリ最適化には Parquet/ORC のような列指向形式が適します。「射影ベースのパーティショニング（partition projection）」はパーティション管理の手法であり、行指向のままでは列スキャン削減効果が得られません。
D：列指向 Parquet＋パーティション＋述語プッシュダウン自体は有効ですが、「1 日 1 つの単一ファイル」にまとめると Athena が並列に読み取れず並列度が下がります。最短クエリ時間を狙う本問では、複数ファイルで並列性を確保する A に劣ります。

【参考】
Amazon Athena のパフォーマンスチューニング Top 10 のヒント
Athena でのパフォーマンス調整
この問題のページを開く →
問題 3データエンジニアはどのようにしてステージメトリクスにアクセスできますか？データ運用とサポート
問題
ある企業は、AWS Glue の Apache Spark ジョブを使用して抽出・変換・ロード（ETL）ワークロードを処理しています。同社はすべての AWS Glue ジョブでロギングとモニタリングを有効にしています。 AWS Glue ジョブの 1 つが失敗し始めました。データエンジニアはエラーを調査しており、ジョブ内のすべての個別ステージのメトリクスを確認したいと考えています。 データエンジニアはどのようにしてステージメトリクスにアクセスできますか？

選択肢と解説

  • ✓
    Spark UI で AWS Glue のジョブおよびステージの詳細を確認する。
  • 2
    Amazon CloudWatch で AWS Glue のジョブおよびステージのメトリクスを確認する。
  • 3
    AWS CloudTrail ログで AWS Glue のジョブおよびステージのログを確認する。
  • 4
    ジョブの run insights（実行インサイト）機能を使用して AWS Glue のジョブおよびステージの詳細を確認する。

解説

【正解】A

【0からの解説】
AWS Glue の Spark ジョブは内部的に Apache Spark のエンジンで動いており、Spark のジョブは「ジョブ → ステージ → タスク」という階層で実行されます。各ステージ（シャッフルや集計などの単位）ごとの所要時間・入出力レコード数・データ量・タスクの分布といった詳細を可視化する公式ツールが Spark UI です。AWS Glue では Spark UI を有効化すると、ジョブ実行のイベントログが S3 に出力され、それを Spark History Server で開くことで「ジョブとステージの詳細メトリクス」をステージ単位で確認できます。スキューの特定や遅いステージのボトルネック分析にまさに使う機能なので、本問の「すべての個別ステージのメトリクスを確認したい」に直接合致するのは A です。

【誤りの選択肢】
B：Amazon CloudWatch には Glue ジョブ全体のメトリクス（ドライバー/エグゼキューターの CPU・メモリ、シャッフルバイト数など）は出ますが、これはジョブ全体や時系列の集約メトリクスであり、「Spark のステージ単位」の粒度でステージごとに分解して見る用途には Spark UI が適します。
C：AWS CloudTrail は AWS API 呼び出し（誰がいつどの操作をしたか）の監査ログを記録するサービスで、Spark のステージ実行メトリクスは記録しません。
D：Glue の job run insights は、エラーの根本原因の特定やリトライ・例外の要約といったトラブルシュート支援を行う機能で、エラー診断には有用ですが、本問が求める「すべての個別ステージのメトリクス」をステージ単位で網羅的に見る用途には Spark UI が適しています。

【参考】
AWS Glue ジョブの Apache Spark UI でのモニタリング
AWS Glue のモニタリング
この問題のページを開く →
問題 4（2 つ選択してください。データセキュリティとガバナンス
問題
ある金融会社はデータメッシュ（data mesh）を実装したいと考えています。このデータメッシュは、一元化されたデータガバナンス、データ分析、データアクセス制御をサポートする必要があります。同社は、データカタログと抽出・変換・ロード（ETL）操作に AWS Glue を使用することを決定しました。 データメッシュを実装する AWS サービスの組み合わせはどれですか？（2 つ選択してください。）

選択肢と解説

  • 1
    データストレージに Amazon Aurora を使用する。データ分析に Amazon Redshift プロビジョンドクラスターを使用する。
  • ✓
    データストレージに Amazon S3 を使用する。データ分析に Amazon Athena を使用する。
  • 3
    一元化されたデータガバナンスとアクセス制御に AWS Glue DataBrew を使用する。
  • 4
    データストレージに Amazon RDS を使用する。データ分析に Amazon EMR を使用する。
  • ✓
    一元化されたデータガバナンスとアクセス制御に AWS Lake Formation を使用する。

解説

【正解】B、E

【0からの解説】
データメッシュとは、データを「ドメイン（事業部門）」ごとに分散して所有・管理しつつ、横断的なカタログとガバナンスで安全に共有・発見できるようにするアーキテクチャの考え方です。AWS でこれを実現する標準的な構成は次のとおりです。

・ストレージ層は Amazon S3：スケーラブルで安価なデータレイクの基盤になります。各ドメインのデータを S3 に置き、分析は Amazon Athena（サーバーレス SQL）で行えば、サーバー管理なしに横断クエリができます（選択肢 B）。
・一元的なガバナンス／アクセス制御は AWS Lake Formation：S3 のデータレイクを登録し、データベース／テーブル／列／行レベルの権限を中央集権的に付与でき、アカウントをまたいだデータ共有（Lake Formation のクロスアカウント共有）にも対応します。これがデータメッシュの「中央ガバナンス」の核になります（選択肢 E）。

AWS Glue Data Catalog がメタデータの共有カタログ、Glue ETL が変換を担い、S3＋Athena＋Lake Formation が組み合わさってデータメッシュが成立します。よって B と E が正解です。

【誤りの選択肢】
A：Amazon Aurora や Redshift プロビジョンドクラスターはトランザクション DB／データウェアハウスとして有用ですが、Glue＋S3 を前提とするデータレイク型のデータメッシュにおける「ストレージ＋分析」の標準構成ではなく、また中央ガバナンス（Lake Formation）の要件を満たしません。
C：AWS Glue DataBrew はノーコードのデータ準備・クレンジングツールであり、「一元的なデータガバナンスとアクセス制御」を担うサービスではありません。アクセス制御は Lake Formation の役割です。
D：Amazon RDS は OLTP 向けのリレーショナル DB で、データメッシュのデータレイクストレージには適しません。EMR も分析に使えますが、本問のサーバーレスかつ低運用なデータメッシュ構成としては S3＋Athena が標準で、かつ中央ガバナンス要件を満たしません。

【参考】
AWS Lake Formation でのデータメッシュ構築
AWS Lake Formation とは
Amazon Athena とは
この問題のページを開く →
問題 5最も少ない運用上のオーバーヘッド（LEAST operational overhead）でこれらの要件を満たすソリューシ…データの取り込みと変換
問題
あるメディア企業は、ユーザーの行動や好みに基づいて顧客にメディアコンテンツを推薦するシステムを改善したいと考えています。推薦システムを改善するために、同社はサードパーティ（第三者）のデータセットから得られるインサイトを、自社の既存の分析プラットフォームに取り込む必要があります。 同社は、サードパーティのデータセットを取り込むために必要な労力と時間を最小限に抑えたいと考えています。 最も少ない運用上のオーバーヘッド（LEAST operational overhead）でこれらの要件を満たすソリューションはどれですか？

選択肢と解説

  • ✓
    AWS Data Exchange からサードパーティのデータセットにアクセスして統合するために API 呼び出しを使用する。
  • 2
    AWS DataSync からサードパーティのデータセットにアクセスして統合するために API 呼び出しを使用する。
  • 3
    Amazon Kinesis Data Streams を使用して、AWS CodeCommit リポジトリからサードパーティのデータセットにアクセスして統合する。
  • 4
    Amazon Kinesis Data Streams を使用して、Amazon Elastic Container Registry（Amazon ECR）からサードパーティのデータセットにアクセスして統合する。

解説

【正解】A

【0からの解説】
「サードパーティのデータセットを最小の労力で取り込みたい」という要件にぴったりのサービスが AWS Data Exchange です。Data Exchange は、データプロバイダーが提供するサードパーティデータセットをカタログから探して購読（サブスクライブ）し、API や S3 経由で自社環境に取り込めるデータマーケットプレイスです。データ提供者との個別契約・配信パイプラインの自作・ファイル受け渡しの仕組みづくりが不要になるため、運用オーバーヘッドが最小になります。よって A が正解です。

【誤りの選択肢】
B：AWS DataSync は、オンプレミスや他ストレージと AWS ストレージ（S3、EFS、FSx など）の間でファイルを高速に移動・同期するサービスです。サードパーティが提供するデータセットをカタログから購読する用途ではなく、本問の「第三者データの調達・統合」には合いません。
C：Amazon Kinesis Data Streams はリアルタイムのストリーミングデータ取り込み基盤で、AWS CodeCommit は Git ソースコードリポジトリです。どちらもサードパーティの分析用データセットを調達する仕組みではなく、組み合わせも不適切です。
D：Kinesis Data Streams はストリーミング用途、Amazon ECR は Docker コンテナイメージのレジストリです。サードパーティのデータセットを取り込む用途とは無関係で、要件を満たしません。

【参考】
AWS Data Exchange とは
AWS Data Exchange（製品ページ）
この問題のページを開く →
問題 6最も少ない運用上の労力（LEAST operational effort）でこれらの要件を満たすソリューションはどれです…データセキュリティとガバナンス
問題
ある小売企業は、Amazon S3 バケットに顧客データハブを持っています。多くの国の従業員がこのデータハブを使用して全社的な分析を支援しています。ガバナンスチームは、同社のデータアナリストが、自分と同じ国に属する顧客のデータのみにアクセスできるようにする必要があります。 最も少ない運用上の労力（LEAST operational effort）でこれらの要件を満たすソリューションはどれですか？

選択肢と解説

  • 1
    国ごとに個別のテーブルを作成する。アナリストが担当する国に基づいて各アナリストにアクセス権を付与する。
  • ✓
    S3 バケットを AWS Lake Formation のデータレイクロケーションとして登録する。Lake Formation の行レベルセキュリティ（row-level security）機能を使用して同社のアクセスポリシーを適用する。
  • 3
    顧客がいる国に近い AWS リージョンにデータを移動する。アナリストが担当する国に基づいて各アナリストにアクセス権を付与する。
  • 4
    データを Amazon Redshift にロードする。国ごとにビューを作成する。国ごとに個別の IAM ロールを作成して各国のデータへのアクセスを提供する。適切なロールをアナリストに割り当てる。

解説

【正解】B

【0からの解説】
要件は「同じ S3 上の顧客データに対し、アナリストごとに『自国の行だけ』を見せる」という行単位のアクセス制御を、最小運用で実現することです。これはまさに AWS Lake Formation の行レベルセキュリティ（row-level security / data filters） の典型的なユースケースです。

手順は、まず S3 バケットを Lake Formation の「データレイクロケーション」として登録し、Glue Data Catalog でテーブルを定義します。次に「country 列の値が利用者の国と一致する行だけを返す」というデータフィルター（行フィルター）を作り、各国のアナリスト（プリンシパル）に付与します。すると Athena などからのクエリ時に、ユーザーごとに該当国の行だけが自動的にフィルタされて返ります。テーブルを国ごとに分割したり、別データストアへ複製したりせず、1 つのテーブルに対してポリシーだけで制御できるため運用が最小です。よって B が正解です。

【誤りの選択肢】
A：国ごとにテーブルを物理的に分割すると、テーブル数の増加・ETL の複製・権限管理が煩雑になり、運用労力が増えます。行レベルセキュリティ 1 つで済む B より明らかに手間が多くなります。
C：データを国の近いリージョンへ移動してもアクセス制御の要件は満たせず、データのリージョン分散による複製・同期コストが増えるだけで的外れです。
D：Redshift にロードし国ごとのビューと IAM ロールを作る方法は、データ複製と多数のビュー／ロールの保守が必要で運用負荷が高くなります。S3 のデータをそのまま使える Lake Formation の行レベルセキュリティ（B）の方が手間が少なく適切です。

【参考】
AWS Lake Formation の行レベルセキュリティ（データフィルター）
Lake Formation でのきめ細かなアクセス制御の管理
この問題のページを開く →
問題 7最もコスト効率の高い方法（MOST cost-effectively）でこの要件を満たすソリューションはどれですか？データ運用とサポート
問題
ある企業には、Amazon API Gateway の REST API と AWS Lambda 関数を使用して Amazon DynamoDB インスタンスからデータを取得するアプリケーションがあります。ユーザーから最近、アプリケーションの応答時間に断続的に高いレイテンシが発生していると報告がありました。データエンジニアが調査したところ、同社の他の Lambda 関数の呼び出しが増加したときに、この Lambda 関数が頻繁にスロットリング（throttling）されることが分かりました。 同社は、この API の Lambda 関数が他の Lambda 関数の影響を受けずに動作できるようにしたいと考えています。 最もコスト効率の高い方法（MOST cost-effectively）でこの要件を満たすソリューションはどれですか？

選択肢と解説

  • 1
    DynamoDB の読み込みキャパシティーユニット（RCU）の数を増やす。
  • 2
    Lambda 関数にプロビジョンドコンカレンシー（provisioned concurrency）を構成する。
  • ✓
    Lambda 関数に予約済みコンカレンシー（reserved concurrency）を構成する。
  • 4
    Lambda 関数のタイムアウトと割り当てメモリを増やす。

解説

【正解】C

【0からの解説】
Lambda の同時実行数（concurrency）は、AWS アカウント・リージョン単位で共有のプール（既定 1,000 など）から消費されます。本問では「他の Lambda 関数の呼び出しが増えると、この API 用 Lambda がスロットリングされる」と明記されており、原因は共有プールを他の関数に食い尽くされていることです。

この問題の解決策が 予約済みコンカレンシー（reserved concurrency） です。特定の関数に同時実行数を予約しておくと、(1) 他の関数がいくら呼ばれてもその予約分は必ずこの関数のために確保され（隔離される）、(2) 同時にこの関数の上限にもなります。これにより API 用 Lambda は他関数の影響を受けずに動作できます。重要なのは、予約済みコンカレンシーの設定自体には追加料金がかからない 点で、最もコスト効率が良い選択です。よって C が正解です。

【誤りの選択肢】
A：DynamoDB の RCU を増やすのは読み込みスループット不足への対策であり、本問の原因である「Lambda の同時実行数のスロットリング」とは無関係です。
B：プロビジョンドコンカレンシーは、関数インスタンスを事前に初期化して待機させ、コールドスタートを無くす機能です。隔離にも使えますが、待機インスタンス分の料金が常時発生するためコスト効率では劣ります。本問はコールドスタートではなく「他関数によるスロットリング」が問題なので、無料で隔離できる予約済みコンカレンシーが適切です。
D：タイムアウトやメモリを増やしても、同時実行数の枯渇によるスロットリングは解消されません。レイテンシの根本原因（共有プールの奪い合い）に対処できていません。

【参考】
Lambda の予約済みコンカレンシーの設定
Lambda 関数のスケーリングとコンカレンシー
この問題のページを開く →
問題 8最も少ない管理上のオーバーヘッド（LEAST administrative overhead）でこれらのデータアクセス要…データセキュリティとガバナンス
問題
ある企業は、個人を特定できる情報（PII）を含む顧客データを Amazon Redshift クラスターに保存しています。同社のマーケティングチーム、クレーム（保険金請求）チーム、分析チームは、この顧客データにアクセスできる必要があります。 マーケティングチームは、難読化（obfuscated）されたクレーム情報にアクセスできる必要がありますが、顧客の連絡先情報には完全にアクセスできる必要があります。クレームチームは、自チームが処理する各クレームの顧客情報にアクセスできる必要があります。分析チームは、難読化された PII データのみにアクセスできる必要があります。 最も少ない管理上のオーバーヘッド（LEAST administrative overhead）でこれらのデータアクセス要件を適用するソリューションはどれですか？

選択肢と解説

  • 1
    チームごとに個別の Redshift クラスターを作成する。各チームに必要なデータのみをロードする。チームに基づいてクラスターへのアクセスを制限する。
  • 2
    各データ要件に必要なフィールドを含むビューを作成する。各チームが必要とするビューにのみアクセス権を付与する。
  • ✓
    チームごとに個別の Amazon Redshift データベースロールを作成する。チームごとに個別に適用するマスキングポリシーを定義する。適切なマスキングポリシーを各チームのロールにアタッチする。
  • 4
    顧客データを Amazon S3 バケットに移動する。AWS Lake Formation を使用してデータレイクを作成する。きめ細かなセキュリティ機能を使用して各チームに適切なアクセス権限を付与する。

解説

【正解】C

【0からの解説】
要件は「Redshift に保存済みの顧客データ（PII を含む）に対して、チームごとに『同じ列でも見せ方を変える』（あるチームには平文、別チームには難読化／マスク）を最小管理で実現する」ことです。これに最適なのが Amazon Redshift の 動的データマスキング（Dynamic Data Masking, DDM）＋データベースロール です。

動的データマスキングでは、列に対してマスキングポリシーを定義し、それを「ロール（チーム）」単位でアタッチできます。同じ列でも、適用されたポリシーに応じてユーザーごとに平文・部分マスク・完全マスクなど異なる結果を返せます。たとえばマーケティングロールには連絡先は平文・クレームは難読化、分析ロールには PII を難読化、といったポリシーをロールに割り当てるだけで要件を満たせます。

この方式は、データを複製したり大量のビューを作ったりせず、既存の 1 つのテーブルに「ロール × マスキングポリシー」を設定するだけなので管理オーバーヘッドが最小です。よって C が正解です。

【誤りの選択肢】
A：チームごとに別クラスターを立て、必要データだけをロードする方法は、複数クラスターの運用・データ複製・整合性管理が必要で管理負荷が非常に高くなります。
B：ビューを要件ごとに作って付与する方法も実現は可能ですが、難読化のロジックや細かな要件が増えるほどビューの数と保守が膨らみます。列単位でロールごとに見せ方を変える動的データマスキングの方が、ビュー乱立を避けられ管理が容易です。
D：データを S3 へ移して Lake Formation で制御する案は、Redshift にすでにデータがある前提で、わざわざデータを別のストアへ移行・複製する大掛かりな変更が必要となり、管理オーバーヘッドが大きく「最小」の要件に反します。Redshift 内で完結する C が適切です。

【参考】
Amazon Redshift の動的データマスキング
Amazon Redshift のロールベースアクセス制御（RBAC）
この問題のページを開く →
問題 9同社はこの CloudWatch アラームにどのように対処すべきですか？データ運用とサポート
問題
ある金融企業は最近、モバイルアプリに新機能を追加しました。新機能のために、同社は既存の Amazon Managed Streaming for Apache Kafka (Amazon MSK) クラスターに新しいトピックを作成する必要がありました。 トピックを追加した数日後、Amazon CloudWatch が MSK クラスターの RootDiskUsed メトリクスに対してアラームを発生させました。 同社はこの CloudWatch アラームにどのように対処すべきですか？

選択肢と解説

  • ✓
    MSK ブローカーのストレージを拡張する。MSK クラスターのストレージが自動的に拡張されるように構成する。
  • 2
    Apache ZooKeeper ノードのストレージを拡張する。
  • 3
    MSK ブローカーインスタンスをより大きなインスタンスタイプに更新する。MSK クラスターを再起動する。
  • 4
    既存のトピックに対して Target Volume-in-GiB パラメータを指定する。

解説

【正解】A

【0からの解説】
Amazon MSK は Apache Kafka をフルマネージドで提供するサービスで、メッセージ（レコード）は「ブローカー」と呼ばれるノードのストレージ（EBS ボリューム）上に保持されます。新しいトピックを追加してデータが流れ込むと、その分ブローカーのディスク使用量が増えます。
・RootDiskUsed メトリクスは「ブローカーのストレージがどれだけ使われているか」を示す指標です。アラームが鳴ったのは、トピック追加でブローカーのディスクが逼迫したことが原因です。
・対処は「ブローカーのストレージ容量を拡張すること」です。さらに MSK には Storage Auto Scaling（ストレージの自動拡張）機能があり、使用率がしきい値を超えたら自動でボリュームを拡張してくれます。これを有効化すれば、今後同じアラームの再発を防げます。
これが運用負荷も含めて最も適切な対処になります。

【誤りの選択肢】
B：ZooKeeper ノードはクラスターのメタデータ管理に使われるノードで、トピックのメッセージデータはここには保存されません。RootDiskUsed（ブローカーストレージ）の逼迫とは無関係です。
C：インスタンスタイプの変更は CPU/メモリ/ネットワークの性能を上げますが、ディスク容量不足そのものを解決しません。また再起動はダウンタイムを伴い不要なオーバーヘッドです。
D：Target Volume-in-GiB はクラスター（ブローカーストレージ）の自動スケーリング設定で使うものであり、「トピック単位」で指定するパラメータではありません。選択肢の記述が誤っています。

【参考】
Amazon MSK ストレージの自動拡張
Amazon MSK のモニタリング (CloudWatch メトリクス)
この問題のページを開く →
問題 10最も少ない運用オーバーヘッドでこれらの要件を満たすソリューションはどれですか？データストア管理
問題
ある企業は、アプリケーション用の半構造化トランザクションデータをデータベースに保存する必要があります。データベースはサーバーレスでなければなりません。アプリケーションはデータの書き込みは頻繁ではありませんが、読み取りは頻繁に行います。アプリケーションはミリ秒単位でデータを取得できる必要があります。 最も少ない運用オーバーヘッドでこれらの要件を満たすソリューションはどれですか？

選択肢と解説

  • 1
    データを Amazon S3 Standard バケットに保存する。S3 Transfer Acceleration を有効にする。
  • 2
    データを Amazon S3 の Apache Iceberg テーブルに保存する。S3 Transfer Acceleration を有効にする。
  • 3
    データを Amazon RDS for MySQL クラスターに保存する。クラスターに対して RDS Optimized Reads を構成する。
  • ✓
    データを Amazon DynamoDB テーブルに保存する。DynamoDB Accelerator (DAX) キャッシュを構成する。

解説

【正解】D

【0からの解説】
キーワードを順に拾います。「半構造化データ」「サーバーレス」「書き込みは稀・読み取りは頻繁」「ミリ秒で取得」「運用負荷最小」。
・Amazon DynamoDB は完全マネージドのサーバーレス NoSQL データベースで、JSON のような半構造化（キー・バリュー/ドキュメント）データの保存に適し、単一桁ミリ秒のレイテンシでアクセスできます。容量管理やパッチ適用が不要で運用負荷が小さいのも特長です。
・読み取りが頻繁という要件には DynamoDB Accelerator (DAX) を組み合わせます。DAX は DynamoDB 専用のインメモリキャッシュで、キャッシュヒット時はマイクロ秒台の読み取りを実現し、頻繁な読み取りを高速化します。
これらにより、すべての要件をサーバーレスかつ低運用負荷で満たすのが D です。

【誤りの選択肢】
A：S3 はオブジェクトストレージであり、トランザクションデータベースとしての一貫した低レイテンシなアイテム取得には向きません。S3 Transfer Acceleration は遠距離からのアップロード高速化機能で、本要件の「ミリ秒読み取り」とは無関係です。
B：S3 上の Iceberg テーブルは大規模分析（クエリ）向けのテーブル形式であり、ミリ秒単位の個別レコード取得を行うトランザクション用途には不適です。Transfer Acceleration も的外れです。
C：RDS for MySQL は管理が必要なリレーショナルデータベースで、本問の「サーバーレス」要件を満たしません（Aurora Serverless でない MySQL クラスターはインスタンス管理が伴います）。半構造化データの自然な保存先でもありません。

【参考】
Amazon DynamoDB とは
DynamoDB Accelerator (DAX) によるインメモリ高速化
この問題のページを開く →
問題 11これらの要件を満たすソリューションはどれですか？データセキュリティとガバナンス
問題
ある企業は、Amazon S3 のデータへのアクセスを制限し、AWS マネージドキーを使用してデータを暗号化するソリューションを必要としています。このソリューションは、AWS Lambda 関数が使用するデータベース認証情報を管理し、その認証情報を自動的にローテーションしなければなりません。 これらの要件を満たすソリューションはどれですか？

選択肢と解説

  • 1
    S3 バケットポリシーを使用してアクセスを制御する。Amazon S3 マネージドキーによるサーバー側暗号化 (SSE-S3) を使用してデータを暗号化する。データベース認証情報を Lambda の環境変数として保存する。
  • ✓
    IAM ポリシーを使用してアクセスを制御する。AWS KMS キーによるサーバー側暗号化 (SSE-KMS) を使用してデータを暗号化する。AWS Secrets Manager を構成して認証情報を保存し、Lambda 関数を使用して自動的にローテーションする。
  • 3
    S3 ACL を使用してアクセスを制御する。AWS KMS キーによるサーバー側暗号化 (SSE-KMS) を使用してデータを暗号化する。認証情報を AWS Systems Manager Parameter Store に保存し、Lambda 関数を使用して自動的にローテーションする。
  • 4
    IAM ポリシーを使用してアクセスを制御する。Amazon S3 マネージドキーによるサーバー側暗号化 (SSE-S3) を使用してデータを暗号化する。認証情報を AWS Systems Manager Parameter Store に保存する。スケジュールされた Lambda 関数を構成して認証情報をローテーションする。

解説

【正解】B

【0からの解説】
要件は3つ。「S3 アクセスの制限」「AWS マネージドキーでの暗号化」「Lambda が使う DB 認証情報を管理し自動ローテーション」。
・アクセス制御：IAM ポリシーは、どのプリンシパル（ユーザー/ロール）がどの S3 リソースに何をできるかを集中管理でき、AWS が推奨するアクセス制御の基本です。
・暗号化：SSE-KMS は AWS KMS で管理される鍵を使った暗号化で、「AWS マネージドキー（aws/s3 など）」を利用でき、キーポリシーや CloudTrail での監査も可能です。要件の「AWS マネージドキーでの暗号化」に合致します。
・認証情報の管理と自動ローテーション：AWS Secrets Manager は認証情報（DB のユーザー名/パスワード等）を安全に保管し、組み込みのローテーション機能（Lambda 関数）で自動的にパスワードを更新できます。RDS など多くの DB に対するローテーションがマネージドに行えるため、これがベストプラクティスです。
これらをすべて正しく満たすのは B です。

【誤りの選択肢】
A：認証情報を Lambda の環境変数に平文で保存するのはセキュリティ上のアンチパターンで、自動ローテーションもできません。
C：S3 ACL は現在は非推奨のアクセス制御方式で、バケットポリシー/IAM が推奨されます。Parameter Store でもローテーションは実装可能ですが、組み込みのマネージドなローテーションを持つ Secrets Manager の方が DB 認証情報の自動ローテーションには適し、ACL の使用も含め B に劣ります。
D：SSE-S3 自体は暗号化しますが、本問の最適解 B（IAM + SSE-KMS + Secrets Manager）と比べると、Parameter Store + 自前のスケジュール Lambda によるローテーションは運用負荷が高く、マネージドな自動ローテーションを備えた構成になっていません。

【参考】
AWS Secrets Manager でシークレットを自動ローテーションする
Amazon S3 のサーバー側暗号化 (SSE-KMS)
この問題のページを開く →
問題 12元のファイルについて、これらの要件を最もコスト効率よく満たす S3 ライフサイクル構成はどれですか？データストア管理
問題
あるメディア企業は、処理のために大容量の動画ファイルを Amazon S3 にアップロードします。処理後、同社はファイルの再処理が必要になる場合に備えて、元のファイルを90日間保持する必要があります。90日後は、ストレージコストを削減するためにファイルを削除できます。同社は処理済みの動画を別の S3 バケットに保存します。 元のファイルについて、これらの要件を最もコスト効率よく満たす S3 ライフサイクル構成はどれですか？

選択肢と解説

  • 1
    ファイルを90日間 S3 Standard に保存する。その後ファイルを長期保管のために S3 Glacier Flexible Retrieval に移行する。その後ファイルを有効期限切れ（expire）にする。
  • 2
    ファイルを90日間 S3 Standard に保存する。バージョニングを有効にする。ファイルに対して90日間 Object Lock を有効にする。その後ファイルを有効期限切れにする。
  • ✓
    ファイルを90日間 S3 Standard に保存する。S3 ライフサイクル管理を実装してファイルを有効期限切れにする。
  • 4
    ファイルを90日間 S3 Intelligent-Tiering に保存する。バージョニングを有効にする。S3 ライフサイクル管理を追加してファイルを有効期限切れにする。

解説

【正解】C

【0からの解説】
要件は「元ファイルを90日間保持（その間は再処理に備えてアクセスする可能性あり）」「90日後は削除」「最もコスト効率よく」です。
・90日でデータを完全に削除するのですから、その途中で別のストレージクラス（Glacier 等）へ移行しても意味がありません。むしろ移行には最低保管期間や移行手数料が絡み、すぐ消すデータには割高・無駄になります。
・最もシンプルかつ安価なのは「90日間 S3 Standard に置き、S3 ライフサイクルルールで90日後に Expire（削除）する」ことです。再処理にすぐアクセスできる Standard のまま保持し、期限到来で自動削除します。
この素直な構成 C が最もコスト効率的です。

【誤りの選択肢】
A：90日後に削除するのに、その前に Glacier Flexible Retrieval へ移行するのは無意味です。Glacier への移行コストや最低保管期間（90日）のペナルティが発生し得て、かえって割高になります。
B：バージョニングや Object Lock（書き込み禁止のロック）は要件にありません。Object Lock を有効にすると保持期間中はオブジェクトを削除できず、不要な機能でコストと複雑さが増えます。
D：S3 Intelligent-Tiering は対象オブジェクトごとに月額のモニタリング・自動階層化手数料がかかります。90日という短期間で削除する大容量ファイルにはモニタリング費用が無駄で、Standard + Expire より割高になります。バージョニングも不要です。

【参考】
S3 ライフサイクル設定でオブジェクトを失効させる
Amazon S3 ストレージクラス
この問題のページを開く →
問題 13この要件を満たすソリューションはどれですか？データ運用とサポート
問題
ある企業は、Amazon DynamoDB、Amazon RDS、Amazon Redshift、Amazon S3 に保存されているデータを結合（join）して、一度限りのパフォーマンスレポートを生成する必要があります。同社は不要なデータ移動を回避し、クエリの実行時間を最小化したいと考えています。 この要件を満たすソリューションはどれですか？

選択肢と解説

  • 1
    DynamoDB Streams を使用して DynamoDB からデータをキャプチャする。AWS DMS を使用して Amazon RDS からデータを移行する。Amazon Redshift のデータをエクスポートする。すべてのデータを Amazon S3 に保存する。Redshift Spectrum を使用してクエリを実行する。
  • 2
    AWS Glue ETL パイプラインをセットアップし、データを抽出・変換して Amazon S3 に集約する。Amazon Athena を使用して分析クエリを実行する。
  • 3
    Apache Spark を搭載した Amazon EMR クラスターをデプロイし、複数のソースからデータセットを取り込み・処理・マージする。マージされたデータに対して分析ワークロードを実行する。
  • ✓
    Amazon Athena Federated Query を使用して、DynamoDB、Amazon RDS、Amazon Redshift、Amazon S3 にまたがる一度限りの結合と分析を実行する。

解説

【正解】D

【0からの解説】
この問題の決め手は「一度限り（one-time）」「不要なデータ移動を回避」「クエリ実行時間を最小化」という3つのキーワードです。
・Amazon Athena Federated Query（フェデレーテッドクエリ）は、Lambda ベースのデータソースコネクタを介して、DynamoDB・RDS・Redshift・S3 など複数の異種データソースに対して、データを1か所に移動させることなく、その場で SQL の結合・分析を実行できる機能です。
・一度限りのレポート用途では、ETL でデータを事前に集約するパイプラインを構築するのはコストも準備時間も無駄になります。Federated Query なら各ソースに直接接続して即座に結合クエリを投げられるため、不要なデータ移動がなく、構築の手間も最小です。
このように「複数の異種ソースをまたいだアドホックな結合分析」は Athena Federated Query の代表的なユースケースです。

【誤りの選択肢】
A：DynamoDB Streams・DMS・Redshift エクスポートで全データを S3 にコピーするのは、まさに「不要なデータ移動」そのものであり、一度限りのレポートには過剰で時間もかかります。
B：Glue ETL で S3 に集約してから Athena でクエリする方式も、事前のデータ移動と変換が発生するため、一度限り用途では不要なデータ移動と準備時間が生じます。
C：EMR/Spark クラスターを立てて全ソースを取り込み・マージするのは最も運用負荷が高く、クラスター起動・処理のために大量のデータ移動と時間を要します。

【参考】
Amazon Athena フェデレーテッドクエリの使用
Amazon Athena データソースコネクタ
この問題のページを開く →
問題 14この要件を満たすソリューションはどれですか？データセキュリティとガバナンス
問題
ある企業は、機密性の高いトランザクションデータを Amazon S3 バケットに保存しています。データエンジニアは、誤った削除（accidental deletions）を防止するための制御を実装する必要があります。 この要件を満たすソリューションはどれですか？

選択肢と解説

  • ✓
    S3 バケットでバージョニングを有効化し、MFA delete を構成する。
  • 2
    S3 削除マーカーの作成を拒否する S3 バケットポリシールールを構成する。
  • 3
    削除されたファイルを S3 Glacier Deep Archive に移動する S3 ライフサイクルルールを作成する。
  • 4
    ユーザーが S3 オブジェクトを削除できないようにする AWS Config の修復（remediation）アクションを設定する。

解説

【正解】A

【0からの解説】
S3 における「誤削除の防止」の定番ベストプラクティスは、バージョニング + MFA delete の組み合わせです。
・バージョニングを有効化すると、オブジェクトを「削除」しても実際には削除マーカーが付くだけで、以前のバージョンは保持され、いつでも復元できます。これにより誤って削除しても元に戻せます。
・MFA delete を構成すると、オブジェクトバージョンの完全削除（およびバージョニングの停止）に多要素認証（MFA）が必須となり、誤操作や権限を持つユーザーによるうっかり削除を強力に防げます。
この2つの組み合わせが、AWS が推奨する誤削除防止の標準的な手段です。

【誤りの選択肢】
B：S3 削除マーカーの作成だけをバケットポリシーで拒否しても、バージョニングが無効ならオブジェクトは普通に削除されますし、削除マーカー作成の拒否は通常の削除操作をブロックする正規の制御手段ではなく、誤削除防止のベストプラクティスではありません。
C：ライフサイクルルールは「削除されたファイルを移動する」ことはできません（削除済みオブジェクトは存在しません）。ライフサイクルは保存期間に応じたストレージクラス移行や失効が目的で、誤削除の防止にはなりません。
D：AWS Config はリソースの構成を評価・記録するサービスで、修復アクションは構成違反を是正するものです。リアルタイムにユーザーの S3 削除操作をブロックする仕組みではなく、誤削除の予防的制御には適しません。

【参考】
S3 バージョニングの使用
MFA delete の設定
この問題のページを開く →
問題 15この要件を満たすソリューションはどれですか？データストア管理
問題
ある企業のアプリケーションは、ニアリアルタイムでデータを検索・分析する必要があります。このアプリケーションは、低いクエリレイテンシで毎秒最大 1,000 件のリクエストを処理しなければなりません。同社は、個々のデータチームが、各チームのコストおよびパフォーマンス最適化の要件を満たすために、自ら所有・構成できるソリューションを求めています。 この要件を満たすソリューションはどれですか？

選択肢と解説

  • 1
    Amazon S3 バケットを使用してデータを保存する。Amazon Athena を使用してデータをクエリ・分析する。各データチームにクエリ最適化のため個別の S3 バケットプレフィックスを割り当てる。
  • 2
    Amazon Kinesis Data Streams のストリームと Amazon Managed Service for Apache Flink を使用してデータをクエリ・分析する。各データチームに管理・消費する個別のストリームを割り当てる。
  • ✓
    Amazon OpenSearch Service クラスターとインデックスを使用してデータをクエリする。各データチームにストレージとクエリを構成するための個別のクラスターを割り当てる。
  • 4
    Aurora I/O-Optimized インスタンスで動作する Amazon Aurora クラスターを使用する。各データチームにストレージとクエリを構成するための個別の Aurora クラスターを割り当てる。

解説

【正解】C

【0からの解説】
キーワードは「ニアリアルタイムで検索（search）・分析」「毎秒最大1,000リクエスト・低レイテンシ」「各チームが所有・構成できる」です。
・Amazon OpenSearch Service は、まさに「検索と分析」のためのマネージドサービスで、ドキュメントをインデックス化することで全文検索や集計分析を低レイテンシ・高スループットで実行できます。毎秒1,000リクエスト級のニアリアルタイム検索ワークロードに適しています。
・各データチームに個別の OpenSearch クラスターを割り当てれば、チームごとにストレージ容量・インスタンスタイプ・シャード設計などをコストとパフォーマンスの要件に合わせて独立して所有・構成できます。
「検索」というキーワードが OpenSearch を選ぶ強い手がかりです。

【誤りの選択肢】
A：S3 + Athena はサーバーレスのアドホック分析には向きますが、データのスキャンに基づくクエリのため低レイテンシ・高 QPS のニアリアルタイム「検索」には適しません。
B：Kinesis Data Streams + Managed Service for Apache Flink はストリーム処理（リアルタイムのデータ処理・集計）向けで、対話的な「検索・クエリ」のデータストアではありません。蓄積データの検索分析という要件に合いません。
D：Aurora はリレーショナルなトランザクション/分析クエリには優れますが、全文検索を含む「検索・分析」を低レイテンシで大量に処理するワークロードでは OpenSearch が最適です。

【参考】
Amazon OpenSearch Service とは
Amazon OpenSearch Service の概要
この問題のページを開く →

DEA-C01 対策のハンズオンラボ

実際の Azure・AWS 環境を払い出して手を動かせます。問題演習と組み合わせると理解が定着します。

AWS Glue と Athena で分析用データを準備しクエリする
intermediate・約 50 分
Glue で S3 のデータを Redshift にロードする
intermediate・約 60 分
Kinesis Data Stream を作成して CloudShell からデータを投入・取得する
beginner・約 30 分

DEA-C01 模擬問題集についてよくある質問

DEA-C01 の練習問題は無料で試せますか？

はい。DEA-C01 は先頭 15 問を会員登録なしで、正解と全選択肢の解説つきでご覧いただけます。16 問目以降は模試プラン（月額 ¥980）または Pro プラン（月額 ¥4,980）でご利用ください。

問題は何問ありますか？

DEA-C01 は本番形式の練習テスト 4 回・全 200 問を収録しています。全問に解説が付いています。

解説は付いていますか？

全ての問題に、正解の理由と各選択肢がなぜ誤りなのかの解説を付けています。ドメイン（出題分野）別の正答率も受験後に確認できます。

DEA-C01 のハンズオン学習もできますか？

はい。DEA-C01 に対応するハンズオンラボを 3 件ご用意しています。実際の Azure・AWS 環境を払い出して手を動かしながら学習できます。