DEA-C01 Practice Question 7: Glue Data Quality ETL Ruleset
AWS Certified Data Engineer – Associate (DEA-C01) · Test 1 · question 7 of 10
A finance dashboard displayed negative order totals and rows with null customer identifiers. The bad records had already been loaded into the curated zone by an AWS Glue ETL job and had to be removed by hand.
Going forward the team requires that records failing agreed-upon checks never reach the curated zone; that the exact records which failed each check be captured for investigation; and that failures raise a notification through Amazon EventBridge. Business analysts, not only engineers, must be able to read and adjust the checks, and the team wants to avoid maintaining custom validation code.
Which approach best satisfies these requirements?
Show answer and explanation
Answer:
AWS Glue Data Quality has two entry points, and the distinction is the whole question. The ETL job entry point is the proactive one: it "helps you identify and filter out bad data *before* you load a data set into your data lake". Rules are written in DQDL, a domain-specific language designed so that "business users can easily express data quality rules in a straightforward language that they can understand", which covers the analyst-authoring requirement without custom code. Critically, identifying the specific records that failed a check is supported only for the ETL job entry point, which is what makes routing failures to a quarantine prefix possible. EventBridge integration is supported, so failures can raise a notification.
Option B is the Data Catalog entry point. It is a genuine feature and it does support rule recommendations and scheduling, but it evaluates data at rest, after the load has already happened, which is how the bad rows got into the dashboard in the first place. Per the feature comparison, identifying the records that failed data quality checks is not supported for the Data Catalog entry point.
Option C would work mechanically but is the maintenance burden the team asked to avoid: no managed rule language for analysts, no data quality score, no rule recommendations, and no built-in EventBridge or CloudWatch reporting. Failing the whole job on any violation also stops good records from loading instead of quarantining the bad ones.
Option A solves a different problem. Crawlers infer and update schema in the Data Catalog. A negative amount and a null customer ID are perfectly valid values for their column types, so no amount of schema inference will catch them.
Reference: AWS Glue Data Quality