Streaming data quality — in-flight DQ, quarantine / DLQ, completeness

4 h
requires STH-05

From your world. dbt tests and SOX controls: not-null, accepted-values and relationship tests, but applied in-flight with a quarantine instead of failing the run

Practice quiz with instant feedback. For a scored run that counts toward your local progress, use uv run de quiz STH-06.

1In a streaming data-quality stage, what is the key difference between filtering with a WHERE clause and using a quarantine/DLQ? AThere is no difference BA WHERE filter silently drops failing records. A quarantine routes them to a side table with the reason they failed CA quarantine is slower and always worse DWHERE keeps bad records in the mart

3Why must the 'good' and 'quarantine' predicates be exact logical complements? ASo the job compiles BSo the job routes no record to both tables and no record to neither (this preserves completeness) CTo make the query faster DTo avoid using a CASE expression

4A record violates two DQ rules at once (null customer AND non-positive amount). How does the pipeline handle it? ATwo quarantine rows, one per rule BOne quarantine row with a single reason (the first matching rule in the CASE) CIt is dropped because it is 'too broken' DIt is sent to the mart with a warning

7Which statements about in-flight DQ with a quarantine are correct? (choose all) (select all that apply) AEvery input record ends up in the mart or the quarantine, never in neither BA quarantine row carries the reason the record failed CSilently filtering bad rows preserves completeness DThe good and quarantine sets are disjoint

8Why does streaming data quality route each record instead of failing the run like a dbt test? AStreaming engines cannot raise errors BA stream has no post-load gate. Data flows to consumers continuously, so the pipeline must decide quality for each record and keep the mart flowing Cdbt tests are not allowed in streaming DFailing the run is impossible in SQL