2.4標準
開発環境でCatalogのテーブル定義を変更してから本番へ反映する。
同じ名前のテーブルを誤って上書きせず、承認済みの定義を追跡したい。
最も適切な設計はどれか。
× 不正解
Glue CatalogやLake Formationの定義・権限をIaCと変更履歴で管理し、環境を分離して安全に反映する。
詳細解説
正しいCatalogの定義をコード化し、環境別データベースと変更履歴で昇格する
テーブル定義・権限・場所をレビュー可能な形で管理し、段階的に本番へ反映できる。
テーブル定義・権限・場所をレビュー可能な形で管理し、段階的に本番へ反映できる。
誤り本番Catalogを手動で直接編集する
変更者・差分・ロールバックが不明確になり、再現性が下がる。
変更者・差分・ロールバックが不明確になり、再現性が下がる。
誤りテーブル名だけを同じにして場所を毎回変更する
論理名と物理データの対応が不安定になり、下流を壊す。
論理名と物理データの対応が不安定になり、下流を壊す。
誤りS3オブジェクトを削除して定義変更を通知する
物理データ削除はメタデータの承認・履歴管理にならない。
物理データ削除はメタデータの承認・履歴管理にならない。
実際に確かめる
一時的な検証環境で実行できる例です。
AWS Glue Data Catalog、Lake Formation permissions、CloudFormationの公式説明を確認する。期待される結果
データモデル変更を物理データ削除ではなくメタデータと権限の変更として管理できる。理解のポイント
- Catalog
- IaC
- 環境分離
- 変更履歴
確認時の注意
- 確認環境: AWS公式DEA-C01試験ガイドと各サービスの公式ドキュメントの確認
- AWS公式DEA-C01 Domain 2・Task 2.4と各サービスの公式ドキュメントを確認する。
基礎のおさらい
再現性
同じ定義を開発・検証・本番へ適用し、差分をレビュー可能にする。
権限
テーブル定義とLake Formation権限の変更を同じリリース単位で追跡する。
問題IDAWS-DEA-175
確認環境AWS公式DEA-C01試験ガイドと各サービスの公式ドキュメントの確認
最終技術確認2026-08-20
誤り・権利侵害を報告