1.4標準
データ供給元が列名を変更する可能性がある。
GlueスクリプトのCIで、期待スキーマとの互換性を確認してから本番へ昇格する。
最も適切な方法はどれか。
× 不正解
データ契約テストで列名・型・NULL許容・必須列を検証し、破壊的なスキーマ変更をCI/CDで止める。
詳細解説
正しいデータ契約テストで列名・型・必須性・互換性を検証する
入力スキーマの変更をデプロイ前に検出し、破壊的変更を止められる。
入力スキーマの変更をデプロイ前に検出し、破壊的変更を止められる。
誤り本番ジョブが失敗するまで変更を許可する
障害が本番データと業務処理へ波及する。
障害が本番データと業務処理へ波及する。
誤りS3のアクセスログだけを確認する
アクセス状況は列名・型の互換性を検証しない。
アクセス状況は列名・型の互換性を検証しない。
誤りCloudTrailのユーザー名でスキーマを判定する
変更者はスキーマの構造・互換性を示さない。
変更者はスキーマの構造・互換性を示さない。
実際に確かめる
一時的な検証環境で実行できる例です。
AWS Glue Data Catalog、CodeBuild、データ契約・スキーマ検証の公式説明を確認する。期待される結果
運用ログ・監査主体と、スキーマ互換性テストの違いを説明できる。理解のポイント
- データ契約
- スキーマ検証
- CodeBuild
- 互換性
確認時の注意
- 確認環境: AWS公式DEA-C01試験ガイドと各サービスの公式ドキュメントの確認
- AWS公式DEA-C01 Domain 1・Task 1.4と各サービスの公式ドキュメントを確認する。
基礎のおさらい
スキーマ進化
追加列と削除・型変更を区別し、下流互換性をルール化する。
シフトレフト
本番処理前に小さなfixtureとCatalogメタデータで契約違反を検出する。
問題IDAWS-DEA-101
確認環境AWS公式DEA-C01試験ガイドと各サービスの公式ドキュメントの確認
最終技術確認2026-08-20
誤り・権利侵害を報告