dbt Analytics Engineering Certification · 24% of the exam

Testing and documentation: free practice questions

5 sample questions from our 60-question bank for this domain — answers and explanations included. These are the same scenario-based style as the real dbt Labs exam.

1. A developer configures `persist_docs` in `dbt_project.yml` as follows: ```yaml models: my_project: +persist_docs: relation: true columns: true ``` What is the effect of this configuration?

  • A. dbt generates a static documentation site that includes model and column descriptions
  • B. dbt writes model-level and column-level descriptions as comments or metadata directly on the warehouse objects (tables/views)✓ Correct
  • C. dbt stores model descriptions in the `manifest.json` but not in the warehouse
  • D. dbt fails to run if any model or column is missing a description
Explanation

`persist_docs` with `relation: true` and `columns: true` causes dbt to apply the descriptions from YAML files as metadata (e.g., table comments and column comments) directly on the warehouse objects such as tables and views. This is distinct from dbt's documentation site generation, which is triggered by `dbt docs generate` and is always available regardless of `persist_docs`. Descriptions are always stored in `manifest.json` regardless of this setting — `persist_docs` specifically controls whether they also go to the warehouse. dbt does not fail if descriptions are missing; descriptions are optional metadata.

2. A developer wants to apply the `not_null` test to the `email` column of `dim_customers`, but only for rows where `account_status = 'active'`. Which configuration achieves this without writing a singular test?

  • A. ```yaml columns: - name: email tests: - not_null: where: "account_status = 'active'" ```✓ Correct
  • B. ```yaml columns: - name: email tests: - not_null: filter: "account_status = 'active'" ```
  • C. ```yaml columns: - name: email tests: - not_null: config: condition: "account_status = 'active'" ```
  • D. ```yaml columns: - name: email tests: - not_null where: "account_status = 'active'" ```
Explanation

All built-in and generic tests in dbt support a `where` property that appends a WHERE clause to the compiled test SQL, restricting it to a subset of rows. This is the correct approach. Option B is wrong — `filter` is not a valid dbt test property; `where` is the correct key. Option C is wrong — `condition` is not a recognized dbt config key for tests; there is no such property. Option D is wrong — `where` placed at the column level rather than nested inside the specific test definition is not the correct syntax and would not be applied to the test.

3. A developer is configuring a `relationships` test to ensure every `customer_id` in `fct_orders` exists in `dim_customers`. They write the following YAML: ```yaml columns: - name: customer_id tests: - relationships: to: ref('dim_customers') field: id ``` The test fails during `dbt test`. Which TWO of the following could be valid root causes of this failure?

  • A. There are rows in `fct_orders` where `customer_id` is NULL, and the test does not exclude NULLs by default in all dbt versions.✓ Correct
  • B. The `dim_customers` model has not been materialized yet in the target schema.
  • C. The `relationships` test requires both columns to have the same name, but `customer_id` and `id` are different.
  • D. There are `customer_id` values in `fct_orders` that do not have a matching `id` in `dim_customers`, representing true referential integrity violations.✓ Correct
  • E. The `to` property must use `source()` instead of `ref()` when referencing dimension tables.
Explanation

Option A is a valid root cause: in some dbt versions and adapters, NULL values in the column under test are treated as non-matching and can cause the test to fail; developers often add `where: 'customer_id is not null'` to handle this. Option D is the most direct cause — actual orphaned foreign key values will always fail a `relationships` test. Option B is wrong — dbt resolves `ref()` to the compiled schema name at runtime; if the model doesn't exist, compilation would fail before test execution, not during it as a test failure per se. Option C is wrong — the `relationships` test is explicitly designed to allow different column names via the `field` property. Option E is wrong — `ref()` is the correct function for referencing dbt models in tests.

4. A developer wants to write documentation for the `dim_customers` model so that the description appears in `dbt docs`. They write the following in `schema.yml`: ```yaml models: - name: dim_customers description: "A table containing one row per customer with cleansed attributes." columns: - name: customer_id description: "Primary key for the customer." ``` After running `dbt docs generate`, where will this documentation be visible?

  • A. Only in the `manifest.json` file; descriptions are not rendered in the dbt docs UI.
  • B. In the dbt docs UI under the model's detail page, including both the model description and the column-level description.✓ Correct
  • C. In the data warehouse as column comments, because `dbt docs generate` automatically persists descriptions.
  • D. Only if `persist_docs` is enabled in `dbt_project.yml`; otherwise descriptions are ignored entirely.
Explanation

Running `dbt docs generate` compiles all descriptions from YAML files into the `catalog.json` and `manifest.json`, which are then rendered in the dbt docs UI (accessible via `dbt docs serve`). Both model-level and column-level descriptions appear on the model's detail page. Option A is incorrect — descriptions are rendered in the UI, not just stored raw in the manifest. Option C is incorrect — persisting descriptions to the warehouse as column comments requires `persist_docs` to be configured separately. Option D is incorrect — descriptions are always captured in the docs site; `persist_docs` is only needed if you want them written back to the warehouse.

5. A developer has written the following custom generic test macro: ```sql {% test is_greater_than_zero(model, column_name) %} select * from {{ model }} where {{ column_name }} <= 0 {% endtest %} ``` Where should this file be saved so that dbt automatically discovers and registers it as a generic test available across the project?

  • A. `tests/is_greater_than_zero.sql` — dbt scans the `tests/` directory for both singular and generic test definitions.
  • B. `macros/is_greater_than_zero.sql` — dbt discovers generic tests defined using the `{% test %}` block in any file within the `macros/` directory.✓ Correct
  • C. `tests/generic/is_greater_than_zero.sql` — dbt recognizes the `tests/generic/` subdirectory specifically for generic test macros.✓ Correct
  • D. `models/tests/is_greater_than_zero.sql` — generic tests must live alongside the models they test.
Explanation

dbt discovers generic test macros (defined with `{% test %}`) from two locations: the `macros/` directory (any file) and the `tests/generic/` subdirectory. Both Option B and Option C are valid save locations. Option A is incorrect — files saved directly in `tests/` (not in `tests/generic/`) are treated as singular tests, not generic test definitions; a file there using `{% test %}` blocks will not be registered properly. Option D is incorrect — there is no `models/tests/` convention in dbt; dbt does not scan subdirectories of `models/` for test macros.

55 more questions in this domain

Practice the full bank with instant grading, flashcards, and a timed mock exam.

Start practicing free