DEA資格演習問題（無料10問）
採点する
10問中 0問が回答されています
質問:
インフォメーション
You have already completed the テスト before. Hence you can not start it again.
問題を読み込んでいます…
無料レッスン・テストを受講するにはフリーコース（無料）に登録してください。
まず、次の操作を完了する必要があります:
結果
結果
正解数 0/問題数10
回答にかかった時間:
終了時間となりました
回答お疲れ様でした。
Earned Point(s): 0 of 0, (0)
0 Essay(s) Pending (Possible Point(s): 0)
カテゴリー
- 分野1-データの取り込み 0%
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 選択中
- 後で確認
- 回答済み
- 正解
- 不正解
-
質問 1 of 10
1. 質問
カテゴリ: 分野1-データの取り込み【DEA-2001】あるデータエンジニアは、モバイルアプリから送信されるクリックストリームイベントを Amazon Kinesis Data Streams で受信しています。イベントは Amazon S3 に JSON 形式で保管され、後続の分析ジョブが参照します。イベントの生成から S3 への到達までの遅延を可能な限り短くする必要があります。イベントの流量は 1 分あたり数千件で変動します。これらの要件を満たす方法を選択してください。
正解不正解ヒントボタン
Kinesis Data Streams は単体で S3 へ直接データを書き出せるでしょうか。まず S3 への配信を担うコンポーネントが何かを整理してみましょう。そのうえで、各選択肢に登場する「バッファ間隔」「バッチウィンドウ」「タンブリングウィンドウ」といった時間指定が、データが S3 に届くまでの待ち時間にどう影響するかを比べてください。同じサービスを使う選択肢が複数ある場合、差は設定値そのものにあります。
-
質問 2 of 10
2. 質問
カテゴリ: 分野1-データの取り込み【DEA-2002】あるデータエンジニアは、モバイルアプリから送信されるクリックストリームイベントをリアルタイムで取り込む基盤を構築しています。イベント量は平常時と比べてキャンペーン開始直後に 10 倍以上に急増し、事前の予測ができません。取り込んだデータは 1 秒未満のレイテンシーで下流の分析アプリケーションから読み取る必要があります。データエンジニアは、シャード数やキャパシティの見積もりと手動調整を避けたいと考えています。運用オーバーヘッドを最小限に抑えて、これらの要件を満たすソリューションを選択してください。
正解不正解ヒントボタン
「1 秒未満で読み取る」という要件は、バッファリングしてからファイルとして書き出す方式でも満たせるでしょうか。まずレイテンシー特性で候補を絞ってみましょう。次に「シャード数やキャパシティの見積もりと手動調整を避けたい」という条件に注目してください。同じサービス内にキャパシティ管理の考え方が異なる 2 つのモードがあることを思い出せると、答えが見えてきます。
-
質問 3 of 10
3. 質問
カテゴリ: 分野1-データの取り込み【DEA-2003】あるデータエンジニアは、決済処理システムから 1 秒あたり数千件のトランザクションイベントを Amazon Kinesis Data Streams に送信しています。企業は不正トランザクションのパターンを検知して、イベント発生から数秒以内に運用チームへ通知することを求めています。検知ロジックには 5 分間のスライディングウィンドウでの集計と、しきい値の比較が含まれます。これらの要件を満たすソリューションを選択してください。
正解不正解ヒントボタン
「イベント発生から数秒以内」という制約に注目してください。データをいったんストレージやデータベースに書き込んでから定期的に問い合わせる方式では、書き込みの待ち時間とポーリング間隔がそれぞれ遅延として積み上がってしまいます。
では、データがストリームを通過するその瞬間に 5 分間のスライディングウィンドウ集計を実行できる処理層はどれでしょうか。ウィンドウ集計をネイティブ機能として備えたサービスを探してみましょう。 -
質問 4 of 10
4. 質問
カテゴリ: 分野1-データの取り込み【DEA-2004】あるデータエンジニアは、IoT センサーから送信されるテレメトリデータを Amazon Kinesis Data Streams で受信しています。企業はこのストリームに対して、デバイスごとに 5 分間のタンブリングウィンドウで平均値と最大値を算出し、結果を Amazon S3 に書き込む必要があります。集計処理は障害発生時にも中間状態を失わずに復旧できる必要があります。これらの要件を満たすソリューションを選択してください。
正解不正解ヒントボタン
「デバイスごとに5分間のタンブリングウィンドウで平均値と最大値」という要件は、単なるバッファリングやファイル分割では実現できません。タンブリングウィンドウとは、時間軸を重複なく固定長のブロックに区切って処理する窓のことです（例：5分ごとに区切り、各区間内のデータだけで平均値・最大値を計算します）。時間窓をまたいで集計途中の状態を保持する仕組みが必要です。
さらに「障害発生時にも中間状態を失わずに復旧」という条件に注目してください。この状態保存と復旧を自前でコードやテーブル設計に落とし込むのか、それともサービスの標準機能として備わっているのか、という違いで選択肢を並べ替えてみましょう。 -
質問 5 of 10
5. 質問
カテゴリ: 分野1-データの取り込み【DEA-2005】あるデータエンジニアは、モバイルアプリケーションから送信される非構造化のアプリケーションログを収集する基盤を構築しています。ログは 1 日あたり数百 GB に達し、量と速度は時間帯によって大きく変動します。収集したログは検索とダッシュボード分析のため、Amazon OpenSearch Serverless のコレクションに数分以内に格納する必要があります。同時に監査用として Amazon S3 にも保管します。運用オーバーヘッドを最小限に抑える必要があります。これらの要件を満たす最も運用効率の高いソリューションを選択してください。
正解不正解ヒントボタン
ログの量と速度が時間帯で大きく変動する状況で、スケーリングを自分で考えなくてよいのはどのサービスでしょうか。また「OpenSearch Serverless へ数分以内」と「S3 にも保管」という2つの宛先を、コードを書かずに設定だけで満たせる仕組みがないか探してみましょう。ストリーム系サービスのうち、配信先（デリバリー先）をネイティブに持つものはどれかに注目してください。
-
質問 6 of 10
6. 質問
カテゴリ: 分野1-データの取り込み【DEA-2006】あるデータエンジニアは、業務システムから Amazon S3 のランディングバケットに毎時アップロードされる CSV ファイルを AWS Glue の Spark ETL ジョブで変換し、分析用バケットに Parquet 形式で書き込んでいます。ジョブは 1 時間ごとにスケジュール実行されますが、実行のたびにバケット内のファイル全体を再処理しており、同一レコードが分析用バケットに重複して出力されています。データエンジニアは、前回の実行以降に追加されたファイルのみを処理するようにパイプラインを再現性のある形で構成する必要があります。これらの要件を満たすソリューションを選択してください。
正解不正解ヒントボタン
「前回の実行以降に追加されたファイルのみ」を処理するには、ジョブが自分がどこまで読んだかを覚えている必要があります。その状態を自分でテーブルやコードで管理するのか、AWS Glue のマネージド機能に任せられるのかを比べてみましょう。また「再現性のある形で」という表現に注目してください。重複を後から取り除く方法と、そもそも重複データを読み込まない方法では、処理コストと信頼性がどう変わるでしょうか。
-
質問 7 of 10
7. 質問
カテゴリ: 分野1-データの取り込み【DEA-2007】あるデータエンジニアは、Amazon S3 のデータレイクに毎時アップロードされる CSV ファイルを AWS Glue の ETL ジョブで変換し、変換後のデータを Amazon Redshift にロードするパイプラインを構築しています。ジョブは Amazon EventBridge のスケジュールで 1 時間ごとに起動します。現状では実行ごとに S3 の対象プレフィックス全体が読み込まれ、前回までに処理済みのファイルが再度変換されて Redshift 側に重複レコードが発生しています。新しく追加されたファイルのみを処理する必要があります。これらの要件を満たすソリューションを選択してください。
正解不正解ヒントボタン
「前回までに処理済み」という情報を、誰がどこに保持しているかを考えてみましょう。ジョブが毎回まったく状態を持たずに起動するなら、増分の境界を判断する材料はどこから来るのでしょうか。AWS Glue には、この「どこまで読んだか」を自動的に記録して次回実行に引き継ぐ標準機能が用意されています。自前の時刻比較や外部キューを組む前に、まずマネージドな仕組みが要件を満たせるかに注目してください。
-
質問 8 of 10
8. 質問
カテゴリ: 分野1-データの取り込み【DEA-2008】あるデータエンジニアは、Amazon S3 のプレフィックスに毎日追加される CSV ファイルを AWS Glue の ETL ジョブで変換し、Amazon Redshift にロードするパイプラインを運用しています。ジョブが失敗した日には手動で再実行しますが、過去に処理済みのファイルが再度読み込まれ、Redshift 側で重複レコードが発生しています。エンジニアは再実行時に未処理のファイルだけが取り込まれる状態にしたいと考えています。これらの要件を最も少ない開発工数で満たすソリューションを選択してください。
正解不正解ヒントボタン
問題の本質は「どのファイルまで処理したか」という状態を誰が覚えているかという点にあります。カタログのパーティション情報やテーブル定義は、ジョブがどこまで読み終えたかを記録してくれるでしょうか。AWS Glue の ETL ジョブには、実行間で処理位置を引き継ぐための組み込み機能が用意されています。追加のキューや独自判定ロジックを書かずに済む方法はないか、注目してください。
-
質問 9 of 10
9. 質問
カテゴリ: 分野1-データの取り込み【DEA-2009】あるデータエンジニアは、決済アプリのイベントを Amazon Kinesis Data Streams に取り込み、AWS Lambda コンシューマーで集計しています。プロデューサーは PutRecord がタイムアウトした際に同じイベントを再送しています。コンシューマーはシャードごとにチェックポイントを保持していますが、集計結果に同一イベントが二重に計上される事象が発生しています。イベントを厳密に一度だけ集計する必要があります。この要件を満たす方法を選択してください。
正解不正解ヒントボタン
二重計上されているイベントは、そもそもどの時点で二つになったのでしょうか。プロデューサーがタイムアウト後に再送している点に注目してください。実際には送信が成功していた場合、ストリームには別々のシーケンス番号を持つ二件のレコードが存在します。ストリーム側の設定や配信方式を変えることで、この二件を一件に戻せるでしょうか。それとも別の層で判断する必要があるか考えてみましょう。
-
質問 10 of 10
10. 質問
カテゴリ: 分野1-データの取り込み【DEA-2010】あるデータエンジニアは、顧客向けチャットアプリケーションの取り込み層を構築しています。クライアントは長時間接続を維持し、サーバー側からも随時メッセージを配信します。会話の文脈を保持するため、接続ごとの状態を Amazon DynamoDB のテーブルに格納し、後続の分析用に Amazon Kinesis Data Streams へ転送します。ステートレスなリクエスト単位の処理では連続した対話のセッションを継続できません。これらの要件をレイテンシーを最小限に抑えて満たす構成を選択してください。
正解不正解ヒントボタン
クライアントが長時間接続を維持し、かつサーバー側からも随時メッセージを送る、という二つの条件に注目してください。
リクエストごとに接続が閉じるプロトコルでは、サーバーがクライアントを「呼び出す」ことができるでしょうか。
また、会話の文脈を保持するには、何を鍵にして DynamoDB のレコードと接続を結び付ければよいか考えてみましょう。
ポーリングや片方向ストリームがレイテンシー要件にどう影響するかも比較してみましょう。
改善リクエスト