dbt Analytics Engineering Certification: Implementing dbt Tests Practice Questions

type, owner, and depends_on are all standard, required or commonly used properties of dbt exposures. type classifies the downstream use case; owner identifies the responsible party; depends_on links the exposure to the dbt nodes it consumes. freshness is a source-level concept and is not a valid property of exposures. maturity is a valid exposure property in some dbt versions (e.g., maturity: high/medium/low), but freshness is not. tags can be applied to exposures for filtering purposes, but among the distractors, freshness is clearly invalid. Note: maturity and tags are actually valid — the three most clearly correct are type, owner, and depends_on, which are the canonical exposure properties highlighted in dbt documentation.

The unique generic test asserts that every value in a column is distinct, making it the correct choice for preventing duplicate order_id values. not_null only checks that no values are NULL, but does not prevent duplicates. accepted_values validates that column values belong to a predefined list, which is unrelated to uniqueness. relationships validates referential integrity between two models/columns, not uniqueness within a single column.

The accepted_values test queries the model and fails if any row contains a value that is not in the provided values list. Since 'pending' is absent from the list, the test will fail at runtime. dbt does not raise compile-time errors for data mismatches — those are caught at test execution time. accepted_values has nothing to do with NULL checks; that is not_null's responsibility. Tests are not skipped based on whether the model was re-run; they always execute against the current data in the warehouse.

In dbt, test threshold configurations (severity, warn_if, error_if) must be placed inside a config: block within the test definition. The warn_if and error_if values are row-count expressions (not percentages), so >= 1 means 'one or more failing rows triggers this severity'. With severity: warn as the base and error_if: >= 1, the test warns when there are any failures but would error at the threshold — however, the intended behavior (warn below threshold, error at/above) is achieved by setting severity: warn, warn_if: < 1, and error_if: >= 1. Option B correctly uses the config: block. Options A and C incorrectly place severity configs at the same level as the test name rather than inside a config: block. Option D uses warn_if: '!= 0' which would warn on any failure, conflicting with the error threshold logic.

Custom generic tests in dbt use the {% test test_name(model, column_name, ...) %} block syntax. model and column_name are always the first two required arguments (dbt injects them automatically), and additional optional arguments like max_value can have defaults using Python-style default values. Option A correctly implements all of this. Option C is wrong — generic tests must use {% test %} blocks, not {% macro %}; using a macro would not register it as a callable test. Option D is wrong — model is a required first argument for all generic tests; omitting it would cause an error when dbt tries to inject the model reference. Option B is wrong — {% generic_test %} is not a valid Jinja block tag in dbt.