【DEA-C01】AWS Data Engineer Associateとは？勉強方法と教材紹介

正解：A

A. 受注データのS3バケットをLake Formationにデータレイクロケーションとして登録し、行レベルセキュリティのデータフィルターで事業部別の行を制御します。

正解 Lake Formationはデータレイクの権限を一元管理するサービスです。行レベルセキュリティ（Row-Level Security）を使うと、単一テーブルのまま行単位で表示範囲を絞れます。事業部ごとの行フィルター式を持つデータフィルターを定義し、SELECT権限を付与する際にアナリストのIAMロールへ関連付けると、クエリ実行時にそのロールに紐づく行だけが自動的に返り、テーブルを分ける必要がありません。事業部の追加もフィルターと権限付与の追加だけで済み、中央集権的なガバナンスを保ちながら最小限の設定で要件を満たします。

B. 受注データを拠点に近いAWSリージョンへ複製し、アナリストには所属事業部に応じた権限を割り当てます。

不正解 リージョンを分けても、アクセス制御の単位が変わるわけではありません。リージョンは物理的なインフラの場所であって、データの参照範囲を制限する仕組みではないため、同じリージョン内のアナリストは他事業部の受注レコードにもアクセスできてしまいます。複数リージョンへの複製は同期や一貫性の維持、クロスリージョンの転送コストという追加の負担も生みます。

C. AWS Glue Data Catalogに、事業部ごとの受注データ用テーブルを個別に定義します。各アナリストには、所属する事業部のテーブルへのSELECT権限だけを付与します。

不正解 事業部ごとに個別のテーブルを用意する方式は、技術的には機能しますが、運用の手間が大きくなります。事業部が増えるたびにテーブル定義と権限設定をやり直す必要があり、同じ受注データを複数のテーブルに分けることでデータの整合性維持も難しくなります。スキーマ変更の際は全テーブルに個別に反映しなければならず、管理コストが膨らみます。

D. Amazon QuickSightの行レベルセキュリティを設定し、事業部ごとの権限ルールでダッシュボードに表示される受注データの行を制限します。

不正解 QuickSightの行レベルセキュリティは、QuickSightのデータセットやダッシュボードで閲覧者に見せる行を制限する機能です。閲覧者はルールで許可された行しか表示されませんが、この制御はQuickSight内部にしか効かず、S3のデータレイク本体へのアクセス（Athenaなどのクエリ）を制限するものではありません。アナリストがデータレイクを直接クエリすれば、所属外の事業部の受注レコードも参照できてしまいます。データレイク全体のアクセス制御という要件は満たせません。

全体的な説明

問われている要件

• S3データレイクに統合された受注データへのアクセスを事業部別に制限すること
• 各アナリストが自事業部の受注レコードにのみアクセスできるようにすること
• 全社横断の分析を支える既存のデータレイクを活用すること
• 運用の手間を最小限に抑えて実装すること

前提知識

AWS Lake Formationについて

AWS Lake Formationは、データレイクの構築、保護、管理を数日で行えるようにするサービスです。 データカタログの作成、データ変換、きめ細かいアクセス制御、データ監査などの機能を提供します。S3に保存されたデータをデータレイクロケーションとして登録することで、Lake Formationの権限管理機能を使用してアクセスを制御できます。

行レベルセキュリティとデータフィルターの仕組み

Lake Formationのデータフィルターは、テーブルへのアクセス時に行と列を制限する機能です。 行フィルター式はPartiQLのWHERE句に相当する構文サブセットで定義し、式の長さは2048文字未満に収める必要があります。フィルターを作成し、SELECT権限を付与するプリンシパルごとに関連付けることで、同じテーブルでもプリンシパルによって異なるデータ行を表示できます。行フィルター式で使えるデータ型はSTRING、CHAR、VARCHAR、INT、LONG、BIGINT、FLOAT、DECIMAL、DOUBLE、BOOLEAN、STRUCTで、ARRAYとMAPは使用できません。

従来のアクセス制御方法との比較

テーブル分割やビュー作成によるアクセス制御は、新しい条件が追加されるたびに手動での設定変更が必要です。 Lake Formationの行レベルセキュリティでは、データを1つのテーブルに保ったまま、プリンシパル（IAMロールやIAM Identity Centerのユーザー・グループ）にデータフィルター付きのSELECT権限を付与するだけでよいため、新しいアナリストの追加や事業部の追加時にも最小限の設定変更で対応できます。また、Athena（エンジンバージョン3以降）、Redshift Spectrum、EMR、Glueなど複数のクエリエンジンで一貫したアクセス制御が適用されます。 なお、Amazon QuickSightにも行レベルセキュリティの機能はありますが、これはダッシュボード上の表示制御であって、データレイク本体へのアクセスを制限するものではありません。Amazon QuickSightは2025年10月にAmazon Quick Suiteへ統合され、現在はQuick Suiteの一機能として提供されていますが、行レベルセキュリティの考え方はこの問題の文脈のまま理解して問題ありません。

アーキテクチャ図の解説

アーキテクチャ図

受注データを格納したS3バケットをLake Formationのデータレイクロケーションとして登録し、Glue Data Catalogと連携してメタデータを管理します。その上でデータフィルター（行レベルセキュリティ）をSELECT権限に関連付けると、Athenaでクエリを実行する時点で、アナリストの所属事業部に応じた行だけが自動的に絞り込まれます。家電事業部のアナリストには家電の受注行だけが、産業機器事業部のアナリストには産業機器の受注行だけが返ります。テーブルを事業部ごとに分ける方式と違い、事業部の追加はフィルターとIAMロールの関連付けだけで済み、単一テーブルのまま一貫性を保てます。データをリージョンで分けたり、事業部ごとにテーブルを分けたり、BIツール側の表示制御に頼ったりする方式では、このきめ細かい制御をデータレイク全体に対して最小の運用負荷で実現できません。

アーキテクチャ図

全事業部の受注を統合したテーブルから、家電事業部のアナリストがクエリを実行すると business_unit=CE という条件が自動付与されて家電の受注行だけが返り、産業機器事業部のアナリストには business_unit=IE が適用されて産業機器の受注行だけが返ります。重要なのは、フィルターがデータを物理的に複製・分割するのではなく、クエリ実行時に行の条件を付与するだけという点です。そのため新しい事業部を追加する場合も、フィルター条件とIAMロールの関連付けを追加するだけで対応でき、テーブルやETLの再構成は不要です。この仕組みを「データを事業部ごとに分けて格納する」と誤解すると、不要なテーブル複製や変換処理を増やして運用負荷を逆に高めてしまいます。

解くための考え方

受注データは単一のテーブルにまとまっています。テーブルを分割せずに行単位で参照範囲を変えられる仕組みが、最も運用負担を抑えられます。 テーブルを事業部ごとに分ける案は、事業部が増えるたびにテーブル定義・権限設定・ETLの再構築が続き、データの一貫性も損ないます。データをリージョンで分ける案は、リージョンがアクセス制御の単位ではないため要件を満たしません。QuickSightの行レベルセキュリティで制御する案は、制御がダッシュボード表示に限られ、データレイク本体へのアクセスを止められません。 これに対し、Lake Formationの行レベルセキュリティは、S3のデータをそのままデータレイクロケーションとして登録し、データフィルターをIAMロールに関連付けるだけで行単位の制御ができます。事業部の追加もフィルター条件の追加だけで済むため、管理コストを最も低く抑えられます。 参考資料

• AWS Lake Formation でのデータフィルタリング - AWS Lake Formation
• PartiQL サポートされる式 - AWS Lake Formation
• AWS Lake Formation を使用した行レベルおよびセルレベルのセキュリティの実装 - AWS Big Data Blog
• データレイクのロケーションの登録 - AWS Lake Formation
• AWS Lake Formation とは - AWS Lake Formation

正解：A

A. 受注データのS3バケットをLake Formationにデータレイクロケーションとして登録し、行レベルセキュリティのデータフィルターで事業部別の行を制御します。

正解 Lake Formationはデータレイクの権限を一元管理するサービスです。行レベルセキュリティ（Row-Level Security）を使うと、単一テーブルのまま行単位で表示範囲を絞れます。事業部ごとの行フィルター式を持つデータフィルターを定義し、SELECT権限を付与する際にアナリストのIAMロールへ関連付けると、クエリ実行時にそのロールに紐づく行だけが自動的に返り、テーブルを分ける必要がありません。事業部の追加もフィルターと権限付与の追加だけで済み、中央集権的なガバナンスを保ちながら最小限の設定で要件を満たします。

B. 受注データを拠点に近いAWSリージョンへ複製し、アナリストには所属事業部に応じた権限を割り当てます。

不正解 リージョンを分けても、アクセス制御の単位が変わるわけではありません。リージョンは物理的なインフラの場所であって、データの参照範囲を制限する仕組みではないため、同じリージョン内のアナリストは他事業部の受注レコードにもアクセスできてしまいます。複数リージョンへの複製は同期や一貫性の維持、クロスリージョンの転送コストという追加の負担も生みます。

C. AWS Glue Data Catalogに、事業部ごとの受注データ用テーブルを個別に定義します。各アナリストには、所属する事業部のテーブルへのSELECT権限だけを付与します。

不正解 事業部ごとに個別のテーブルを用意する方式は、技術的には機能しますが、運用の手間が大きくなります。事業部が増えるたびにテーブル定義と権限設定をやり直す必要があり、同じ受注データを複数のテーブルに分けることでデータの整合性維持も難しくなります。スキーマ変更の際は全テーブルに個別に反映しなければならず、管理コストが膨らみます。

D. Amazon QuickSightの行レベルセキュリティを設定し、事業部ごとの権限ルールでダッシュボードに表示される受注データの行を制限します。

不正解 QuickSightの行レベルセキュリティは、QuickSightのデータセットやダッシュボードで閲覧者に見せる行を制限する機能です。閲覧者はルールで許可された行しか表示されませんが、この制御はQuickSight内部にしか効かず、S3のデータレイク本体へのアクセス（Athenaなどのクエリ）を制限するものではありません。アナリストがデータレイクを直接クエリすれば、所属外の事業部の受注レコードも参照できてしまいます。データレイク全体のアクセス制御という要件は満たせません。

全体的な説明

問われている要件

• S3データレイクに統合された受注データへのアクセスを事業部別に制限すること
• 各アナリストが自事業部の受注レコードにのみアクセスできるようにすること
• 全社横断の分析を支える既存のデータレイクを活用すること
• 運用の手間を最小限に抑えて実装すること

前提知識

AWS Lake Formationについて

AWS Lake Formationは、データレイクの構築、保護、管理を数日で行えるようにするサービスです。 データカタログの作成、データ変換、きめ細かいアクセス制御、データ監査などの機能を提供します。S3に保存されたデータをデータレイクロケーションとして登録することで、Lake Formationの権限管理機能を使用してアクセスを制御できます。

行レベルセキュリティとデータフィルターの仕組み

Lake Formationのデータフィルターは、テーブルへのアクセス時に行と列を制限する機能です。 行フィルター式はPartiQLのWHERE句に相当する構文サブセットで定義し、式の長さは2048文字未満に収める必要があります。フィルターを作成し、SELECT権限を付与するプリンシパルごとに関連付けることで、同じテーブルでもプリンシパルによって異なるデータ行を表示できます。行フィルター式で使えるデータ型はSTRING、CHAR、VARCHAR、INT、LONG、BIGINT、FLOAT、DECIMAL、DOUBLE、BOOLEAN、STRUCTで、ARRAYとMAPは使用できません。

従来のアクセス制御方法との比較

テーブル分割やビュー作成によるアクセス制御は、新しい条件が追加されるたびに手動での設定変更が必要です。 Lake Formationの行レベルセキュリティでは、データを1つのテーブルに保ったまま、プリンシパル（IAMロールやIAM Identity Centerのユーザー・グループ）にデータフィルター付きのSELECT権限を付与するだけでよいため、新しいアナリストの追加や事業部の追加時にも最小限の設定変更で対応できます。また、Athena（エンジンバージョン3以降）、Redshift Spectrum、EMR、Glueなど複数のクエリエンジンで一貫したアクセス制御が適用されます。 なお、Amazon QuickSightにも行レベルセキュリティの機能はありますが、これはダッシュボード上の表示制御であって、データレイク本体へのアクセスを制限するものではありません。Amazon QuickSightは2025年10月にAmazon Quick Suiteへ統合され、現在はQuick Suiteの一機能として提供されていますが、行レベルセキュリティの考え方はこの問題の文脈のまま理解して問題ありません。

アーキテクチャ図の解説

アーキテクチャ図

受注データを格納したS3バケットをLake Formationのデータレイクロケーションとして登録し、Glue Data Catalogと連携してメタデータを管理します。その上でデータフィルター（行レベルセキュリティ）をSELECT権限に関連付けると、Athenaでクエリを実行する時点で、アナリストの所属事業部に応じた行だけが自動的に絞り込まれます。家電事業部のアナリストには家電の受注行だけが、産業機器事業部のアナリストには産業機器の受注行だけが返ります。テーブルを事業部ごとに分ける方式と違い、事業部の追加はフィルターとIAMロールの関連付けだけで済み、単一テーブルのまま一貫性を保てます。データをリージョンで分けたり、事業部ごとにテーブルを分けたり、BIツール側の表示制御に頼ったりする方式では、このきめ細かい制御をデータレイク全体に対して最小の運用負荷で実現できません。

アーキテクチャ図

全事業部の受注を統合したテーブルから、家電事業部のアナリストがクエリを実行すると business_unit=CE という条件が自動付与されて家電の受注行だけが返り、産業機器事業部のアナリストには business_unit=IE が適用されて産業機器の受注行だけが返ります。重要なのは、フィルターがデータを物理的に複製・分割するのではなく、クエリ実行時に行の条件を付与するだけという点です。そのため新しい事業部を追加する場合も、フィルター条件とIAMロールの関連付けを追加するだけで対応でき、テーブルやETLの再構成は不要です。この仕組みを「データを事業部ごとに分けて格納する」と誤解すると、不要なテーブル複製や変換処理を増やして運用負荷を逆に高めてしまいます。

解くための考え方

受注データは単一のテーブルにまとまっています。テーブルを分割せずに行単位で参照範囲を変えられる仕組みが、最も運用負担を抑えられます。 テーブルを事業部ごとに分ける案は、事業部が増えるたびにテーブル定義・権限設定・ETLの再構築が続き、データの一貫性も損ないます。データをリージョンで分ける案は、リージョンがアクセス制御の単位ではないため要件を満たしません。QuickSightの行レベルセキュリティで制御する案は、制御がダッシュボード表示に限られ、データレイク本体へのアクセスを止められません。 これに対し、Lake Formationの行レベルセキュリティは、S3のデータをそのままデータレイクロケーションとして登録し、データフィルターをIAMロールに関連付けるだけで行単位の制御ができます。事業部の追加もフィルター条件の追加だけで済むため、管理コストを最も低く抑えられます。 参考資料

• AWS Lake Formation でのデータフィルタリング - AWS Lake Formation
• PartiQL サポートされる式 - AWS Lake Formation
• AWS Lake Formation を使用した行レベルおよびセルレベルのセキュリティの実装 - AWS Big Data Blog
• データレイクのロケーションの登録 - AWS Lake Formation
• AWS Lake Formation とは - AWS Lake Formation