DEA-C01 の無料練習問題
データエンジニア アソシエイト

複数のKinesis Data Streams（StreamAとStreamB）を単一のLambda関数で処理する場合、ストリームごとに個別のイベントソースマッピングを作成する必要があります。この構成において、複数ストリームを処理する際は各バッチが単一のシャードまたはストリームからのレコードのみを含むという仕様上の制約があり、これによりStreamAのバッチとStreamBのバッチは必ず分離され、同一の関数呼び出しで両者のレコードが混在することはありません。 選択肢Dはこの仕様上の制約を正確に説明しており、設計が実現できなかった理由を正しく指摘しています。 選択肢Aは、バッチサイズを調整すればこの制約を回避できるという誤解です。バッチサイズは各マッピング内で取得するレコード数を制御するものにすぎず、ストリーム間でレコードを統合する機能はありません。 選択肢Bは、同時実行数の設定がストリーム間のデータ統合に寄与するという誤解です。同時実行数は複数の関数呼び出しを並行実行するための制御であり、バッチの構成そのものには影響しません。 選択肢Cは、シャード数を揃えることで統合が可能になるという誤解です。各バッチが単一のストリーム（またはシャード）からのレコードのみを含むという制約は、シャード数の一致・不一致にかかわらず適用されます。

A：不正解です。バッチサイズはイベントソースマッピングごとに設定される値であり、1つのストリームから取得するレコード数の上限を制御するものです。バッチサイズをどれだけ大きくしても、複数ストリームを処理する際に各バッチが単一のストリーム（またはシャード）からのレコードのみを含むという制約自体は変わらないため、異なるストリームのレコードを同一バッチに統合することはできません。

B：不正解です。同時実行数の設定は、Lambda関数の複数呼び出しを並行して実行するための制御であり、ストリームからのレコードをどうバッチにまとめるかとは無関係です。StreamAとStreamBのレコードが同一バッチに含まれるかどうかは、各イベントソースマッピングが単一のストリームのみを対象とするという仕様によって決まり、同時実行数の設定では変えられません。

C：不正解です。複数ストリームを処理する場合、各バッチは単一のシャードまたはストリームからのレコードのみを含むという制約が適用されます。この制約はストリーム間のシャード数の一致・不一致とは関係がなく、シャード数を揃えても異なるストリームのレコードが同一バッチに統合されることはありません。

D：これが正解です。複数のストリームからのアイテムを1つの関数で処理する場合、ストリームごとに個別のイベントソースマッピングを作成しますが、複数ストリームを処理する際は各バッチが単一のシャードまたはストリームからのレコードのみを含むという仕様があります。この仕様により、StreamAとStreamBのレコードが同一バッチに混在することはなく、設計どおりの統合は実現できません。

学習のポイント：複数のKinesis Data Streamsをそれぞれ個別のイベントソースマッピングで1つのLambda関数に接続する場合、各バッチは単一のストリーム（またはシャード）からのレコードのみを含むため、異なるストリームのレコードが同一バッチに混在することはない。

公式ドキュメント

• services-kinesis-create.html

この問題で求められているのは、複数の支社が使い続けている既存の FTP/SFTP クライアントを変更せずに、AWS ストレージへスケーラブルにファイルを転送できるサービスの選択です。AWS Transfer Family は FTP、SFTP、FTPS といった標準プロトコルをそのままサポートしつつ Amazon S3 などのストレージと統合できるため、クライアント互換性とスケーラビリティの両方を満たします。AWS DataSync はオンプレミスと AWS 間のデータ転送サービスですが、FTP/SFTP プロトコル互換のエンドポイントを提供しないため要件に合いません。Amazon AppFlow はアプリケーション間のデータ連携サービスであり、ファイル転送プロトコルを扱う仕組みを持たないため対象外です。AWS Glue は ETL 処理のためのサービスであり、プロトコルベースのファイル転送機能は持たないため、この要件には適合しません。

A：AWS DataSync はオンプレミスのファイルシステムと AWS ストレージの間でデータを転送するサービスですが、既存の FTP/SFTP クライアントとの互換性を提供する仕組みではないため、支社の担当者が既存クライアントを変更せずに使い続けるという要件を満たしません。

B：Amazon AppFlow は SaaS アプリケーションと AWS サービスの間でデータを連携させるサービスであり、FTP/SFTP プロトコルによるファイル転送を扱う機能を持たないため、既存クライアントとの互換性を維持したファイル移行という要件には適合しません。

C：AWS Transfer Family は FTP、SFTP、FTPS といった標準プロトコルをサポートしながら Amazon S3 などの AWS ストレージにファイルを転送できるマネージドサービスです。既存の FTP/SFTP クライアントをそのまま利用でき、AWS 側のストレージへスケーラブルに統合できるため、支社の要件を満たします。

D：AWS Glue はデータの抽出・変換・ロード（ETL）を行うサービスであり、FTP/SFTP プロトコルでファイルを受け取る転送用のエンドポイントを提供するものではないため、既存クライアントの互換性を保ったファイル移行の要件には合致しません。

学習のポイント：既存の FTP/SFTP クライアントの互換性を維持したまま AWS ストレージへファイルを転送する必要がある場合、標準プロトコルをサポートするマネージドサービスを選ぶ必要がある。

公式ドキュメント

• data-engineer-associate-01-domain2.md

最小権限の原則に基づく権限整理では、ロールに付与する権限をそのリソースが実際に必要とする範囲に限定したカスタムポリシーとして構成することが求められる。 選択肢Aは、必要以上の権限を持つ現状のロールをそのまま維持することを提案しており、不要な権限を削減する対応になっていないため誤りである。 選択肢Bは、Lambda関数が実際に必要とする特定のアクションと特定のリソースのみを許可するカスタムポリシーへ絞り込むことを提案しており、これは最小権限の原則を満たすカスタムポリシーを作成するという要件に直接合致するため正しい。 選択肢Cは、AWS管理ポリシーをそのままアタッチした新しいロールを作り直すことを提案しているが、管理ポリシーが特定の関数の業務要件に合わせて絞り込まれているとは限らず、ロールを作り直すだけでは不要な権限が残る可能性があるため誤りである。 選択肢Dは、絞り込んだ新しいポリシー案を既存のロールに反映する前に、IAM Access Analyzerのカスタムポリシーチェックを用いて、そのポリシー案が意図しない新しいアクセスを許可していないかを検証することを提案しており、これはポリシーをエンティティにアタッチする前に内容を検証する用途に合致するため正しい。 選択肢Eは、将来の要件拡大に備えて複数サービスへのフルアクセス権限を保持することを提案しているが、これは不要な広範な権限を維持する対応であり、最小権限の原則に反するため誤りである。 正解はBとDであり、Bは権限を必要な範囲まで絞り込む対応、Dはその絞り込んだポリシー案が意図しない新しいアクセスを許可していないかを事前に検証する対応である。

A：ロールに付与する権限は、そのリソースが実際に必要とする範囲に限定したカスタムポリシーとして構成することが求められており、必要以上の権限をそのまま維持することは最小権限の原則に反する対応であるため誤りである。

B：特定のアクションと特定のリソースのみを許可するカスタムポリシーを構成することは、最小権限の原則を満たすカスタムポリシーを作成するという要件に直接合致する対応であり、不要な権限を削減するための正しい方法である。

C：AWS 管理ポリシーは特定の関数の業務要件に合わせて絞り込まれているとは限らない。管理ポリシーがニーズを満たさない場合はカスタムポリシーを作成することが求められており、ロールを作り直して管理ポリシーをそのままアタッチするだけでは不要な権限が残る可能性があるため誤りである。

D：IAM Access Analyzer のカスタムポリシーチェックは、セキュリティ基準に基づいて新しいアクセスが許可されていないかを確認する機能であり、ポリシーをエンティティにアタッチする前にその内容を検証する用途で利用できる。絞り込んだポリシー案を適用する前にこの検証を行うことは、意図しない権限の混入を防ぐための適切な確認手順であるため正しい。

E：将来の要件拡大の可能性は、現時点で不要な広範な権限を保持する理由にはならない。ロールの権限はそのリソースが現在必要とする範囲に絞り込むことが求められるため、この対応は最小権限の原則に反しており誤りである。

学習のポイント：ロールの権限は、そのリソースが実際に必要とする特定のアクションと特定のリソースに限定したカスタムポリシーとして構成することが最小権限の原則の実現であり、IAM Access Analyzerのカスタムポリシーチェックを使えば、絞り込んだポリシー案をアタッチする前に意図しない新しいアクセスが許可されていないかを検証できる。

公式ドキュメント

• data-engineer-associate-01-domain4.md
• access-analyzer-checks-validating-policies.html

対象のブローカーの CloudWatch メトリクスを個別に確認すると、BytesInPerSec は 12 MBps で `express.m7g.large` の ingress 上限 15.6 MBps の範囲内ですが、BytesOutPerSec は 35 MBps に達しており、egress 上限である 31.2 MBps を超過しています。これがダウンストリームの遅延の直接的な原因です。選択肢 A のクライアント側パラメータ調整は送信効率の改善には有効ですが、ブローカーの物理的なスループット上限そのものを引き上げることはできません。選択肢 B はブローカーをより高い容量のインスタンスタイプにスケールアップするか、ブローカーを追加することでクラスタ全体のスループット容量を拡大する対応であり、超過したブローカーの egress 上限を解消する直接的な手段のため正解です。選択肢 C は既存クラスタ内でスケーリング可能な選択肢がある以上、別サービスへの移行を優先する理由がなく不適切です。選択肢 D はデータ流入量(ingress)を減らす対策であり、今回超過しているのは読み出し側(egress)のトラフィックであるため、根本原因の解決にはなりません。

A：クライアント側のバッチ設定調整は、プロデューサー側の送信効率を高める手段であり、ブローカー自体が処理・送出できるデータ量の物理的な上限を引き上げるものではありません。今回問題になっているブローカーの BytesOutPerSec はすでに `express.m7g.large` の egress 上限である 31.2 MBps を超えて 35 MBps に達しており、この超過分はクライアント側の設定調整だけでは解消できません。

B：`express.m7g.large` の egress 上限は1ブローカーあたり 31.2 MBps ですが、対象のブローカーでは BytesOutPerSec が 35 MBps とこの上限を超過しています。この超過はブローカーの物理的なスループット制限に起因するため、より高い容量を持つインスタンスタイプへのスケールアップ、またはブローカー数を増やしてクラスタ全体の処理能力を拡大することが、この上限超過を解消する直接的な対策になります。

C：既存の MSK cluster 内でインスタンスタイプの変更やブローカー追加によってスループット容量を拡大する手段が用意されているため、この問題への対応として別サービスへの全面移行を行う必要はありません。

D：今回超過しているのは BytesOutPerSec(egress、ブローカーからの読み出しトラフィック)であり、これはコンシューマー側の読み出し量に起因するものです。MSK への書き込み前にデータ量を削減しても、ブローカーからの読み出し側のスループット上限超過は解消されません。

学習のポイント：CloudWatch のブローカー単位のメトリクスと、インスタンスタイプごとに定義された per-broker のスループット上限を比較し、どちらの方向(ingress/egress)で上限超過が発生しているかを正しく特定する力。

公式ドキュメント

• bestpractices-msk-skill.html

AI エージェントが利用するカスタムのスキルアセットを AWS Glue のデータカタログに作成する場合、その識別子は amazon. で始めてはならないと定められている。これはAmazon所有のビルトインスキル（例: amazon.skill::querying-aws-s3）の識別子と区別するためのルールである。選択肢Aはこの内容と一致するため正しい。選択肢Bはルールを逆に述べており誤り。選択肢Cはカスタムスキルが SearchAssets API を通じて検索可能であるという点に反しており誤り。選択肢Dは、プレビュー中のアクセスがIAMロールによって管理されるとされている点に反し、また識別子に制約がないとする点も誤りである。

A：カスタムスキルの識別子は amazon. で始めてはならないと定められている。この設定はカスタムスキルとAmazon所有のビルトインスキル（例: amazon.skill::querying-aws-s3）を区別するためのものであり、この問題のシナリオのように独自のS3ドキュメントを指すカスタムスキルを作成する場合に該当する。

B：amazon. で始まる識別子はAmazon所有のビルトインスキル（例: amazon.skill::querying-aws-s3）のためのものであり、カスタムスキルの識別子はこの接頭辞で始めてはならないとされている。ルールが逆であり誤り。

C：カスタムスキルは SearchAssets API を通じて検索可能であると定められている。検索できないとする点、およびビルトインスキルと同じ命名規則が必要とする点はいずれも誤りである。

D：カスタムスキルの識別子は amazon. で始めてはならないという制約があり、「制約はない」とする点が誤り。またプレビュー中のアクセスはIAMロールで管理されるとされており、IAMロールを経ずにアクセスできるとする点も誤りである。

学習のポイント：カスタムスキルの識別子は amazon. で始めてはならず、この接頭辞はAmazon所有のビルトインスキル専用である。

公式ドキュメント

• catalog-skill-assets.html