dbt-Analytics-Engineering Questions Bank

Information Type

Retrieved From

Singular tests

C. .sql files

Column data types

A. Data platform information schema

Generic tests

B. .yml configuration

SQL code

C. .sql files

Column descriptions

B. .yml configuration

Model dependencies

C. .sql files

The dbt docs command compiles metadata about your project by gathering information from three primary sources: your warehouse’s information schema, your YAML configuration files, and your SQL model files. Understanding which metadata comes from which source is essential for debugging and for effective documentation practices.

Singular tests live inside .sql files within the /tests directory. Since dbt renders these tests directly from SQL files, their definitions appear in documentation sourced from that location.

Column data types come from the warehouse itself. dbt introspects the data platform information schema to retrieve actual types because dbt does not infer or define column types—only the warehouse does.

Generic tests (e.g., unique, not_null, accepted_values) are declared in .yml files. These YAML definitions contain test configurations, descriptions, and parameters, which dbt uses to document and execute these tests.

SQL code for models is naturally sourced from .sql files where the models are defined. This includes logic such as SELECT statements, CTEs, and transformations.

Column descriptions are written exclusively in .yml files. dbt never extracts descriptions from SQL comments—only from YAML.

Model dependencies come from the ref() and source() calls inside .sql model files, which dbt parses to build the DAG.

In dbt, Jinja runs at compile time and operates only on Python objects that exist in the Jinja context (variables, lists, dictionaries, etc.). The tasks inside your with clause:

with tasks as (

select * from {{ ref('stg_tasks') }}

)

defines a SQL CTE named tasks, not a Jinja variable. Jinja cannot iterate over a SQL CTE; it can only loop over a Python iterable that has been created or passed into the template. Because there is no Jinja variable named tasks defined with something like:

{% set tasks = ['task_a', 'task_b', 'task_c'] %}

the for task in tasks loop has nothing to iterate over. As a result, the entire loop body is effectively skipped during compilation, and the compiled SQL only contains:

select

user_id,

with no generated case when expressions.

Option A is incorrect because loop.last is only needed for formatting (e.g., commas), not for the loop to render. Option B is wrong because Jinja control structures correctly use {% %}, while {{ }} is for output. Option D is irrelevant to compilation; missing columns would cause a runtime database error, not an empty compiled block.

Therefore, the problem is that no Jinja variable tasks was defined, making C the correct answer.

In dbt, grants can be configured globally, at the project level, or directly inside a model using the config() function. When a grant is set in dbt_project.yml, it becomes a base definition, and individual models may extend (append to) or override that configuration.

According to dbt documentation, prefixing a grant with a plus sign (+) means “extend the list defined in higher-level configurations.”

Thus, if the project-level config already sets:

select: ['reporter']

…and a model needs to add an additional role (here, bi) without removing the existing one, the correct syntax is:

{{ config(grants = { '+select': ['bi'] }) }}

This tells dbt: “Take the existing grant list (reporter) and append bi to it.”

Option B is incorrect because '+bi' is not a valid grants syntax.

Option C is invalid because grants do not use an inherits parameter.

Option D is invalid because include: is not a grants configuration key.

Therefore, Option A correctly applies dbt’s documented merging behavior for grants.

The selector source_status:fresher+ depends entirely on freshness metadata created by a previous dbt source freshness run. Source freshness results are stored in artifacts, and the --state flag points dbt to the location where these artifacts were previously generated. Without first running dbt source freshness, dbt has no stored freshness status and therefore cannot filter sources by “fresher” status. This makes option A required.

Additionally, source freshness checks only work when sources include a freshness block in their YAML configuration. This block specifies the loaded_at_field and the warn_after / error_after thresholds. If no freshness block exists, dbt does not compute freshness at all, meaning such sources cannot appear in the source_status:fresher+ selector. Therefore D is also required.

Options B and E are unrelated to source freshness artifacts and do not contribute to the preconditions for this selector. Option C does not impact freshness logic, as generic tests have no role in generating freshness metadata.

Thus, the two prerequisites are:

Running dbt source freshness (to create freshness metadata).

Defining a freshness configuration on the relevant sources.