Validating Silver and Gold datasets for quality

In the medallion architecture, Silver and Gold datasets must be validated before use downstream, and Delta Lake plus Delta Live Tables (DLT) provide built-in mechanisms to enforce this. Data quality checks range from simple constraints on Delta tables to declarative expectations in DLT pipelines that can warn, drop, or fail on bad records.

Must-know

• Delta Lake supports NOT NULL and CHECK constraints on tables; violating writes are rejected outright, enforcing schema-level data quality.
• DLT expectations use the @dlt.expect (warn only, row kept), @dlt.expect_or_drop (row dropped), and @dlt.expect_or_fail (pipeline fails) decorators to define row-level validation rules.
• DLT tracks expectation metrics (records passed/failed) in the pipeline event log, giving auditable visibility into data quality over time.
• Schema enforcement (rejecting mismatched writes) and schema evolution (mergeSchema) are distinct Delta Lake features; enforcement protects Silver/Gold integrity while evolution must be explicitly opted into.
• Quarantining bad records (writing failed rows to a separate table) is a common pattern for expect_or_drop style checks so data isn't silently lost.
• Data quality checks are typically applied progressively: looser validation in Bronze-to-Silver, stricter business-rule validation in Silver-to-Gold, since Gold feeds reporting and ML.

Coverage checked against the published exam guide on Jul 26, 2026.

These are independent practice questions, written against this certification's published exam guide. They are not the certification vendor's own questions, and not the real exam.