Free dbt Labs dbt-Analytics-Engineering Practice Exam with Questions & Answers | Set: 2

(new_project)

(models:)

(grants)

(require-dbt-version: '>= 1.0.0' )

The dbt_project.yml file acts as the configuration backbone for every dbt project. dbt requires that project names follow a strict naming convention, allowing only lowercase letters, numbers, and underscores. Therefore, new_project is the only valid name among the choices. Names with spaces or hyphens, such as new project or new-project, violate dbt’s project naming rules.

To configure how models behave—materializations, schemas, tags, or per-directory overrides—dbt uses the models: block inside dbt_project.yml. This block defines configuration inheritance rules and is different from the config() function, which is used inside SQL models, not in YAML files.

When granting permissions on database objects created by dbt, you use the grants configuration. This allows you to define access roles at the model level or project level for downstream BI or analytics tools, ensuring proper data governance and controlled data exposure.

Finally, compatibility with specific dbt versions is set using require-dbt-version. The correct YAML formatting uses quotes, such as '>= 1.0.0', ensuring dbt interprets the value as a string. This prevents accidental mis-parsing and enforces version requirements during dbt run or dbt build.

The correct answers are B and E.

The dbt retry command was introduced to help developers quickly re-run only what failed in the prior dbt invocation. According to dbt documentation, dbt retry examines metadata from the previous execution, including the run results and the manifest.json, to determine which nodes failed. This aligns with Option E, as dbt uses the manifest to identify the models, tests, and other nodes that errored or were not executed successfully.

Option B is also correct because dbt retry works only when the previous run failed due to execution errors (e.g., a warehouse failure or a logic error in SQL). If the failure was due to a syntax error that prevented dbt from compiling, there will be no valid manifest produced, so retry cannot execute. Thus, dbt retry can only re-run models when the previous failure occurred after successful compilation.

Options A and C are incorrect because retry does not run all nodes nor does it automatically pick up exactly where an execution stopped — instead, it runs failed and downstream unbuilt nodes as determined by the manifest. Option D is also incorrect; retry uses the execution metadata, not selectors, to determine what should run.

The correct answers are A: schema and C: tags.

In dbt, the dbt_project.yml file is the central configuration file that defines model-level settings. Under the models: section, you can specify a wide range of model configurations such as schema, materialized, tags, alias, and custom meta fields. The schema configuration allows you to control which database schema a model should be built in, giving analytics engineers the flexibility to organize models by domain or environment. The tags configuration is also valid under models: and is widely used to group models logically for selection, documentation, or orchestration workflows.

Option B (source) is incorrect because sources are defined under YAML files in the sources: section, not under models: in dbt_project.yml. Option D (test) is incorrect because tests must be defined in model or source YAML files, not inside the project configuration. Option E (target) is not a configuration that applies to models; rather, it refers to dbt runtime environments and cannot be configured under the models: block.

dbt's project configuration system ensures that model-level behavior is managed centrally and consistently, and schema and tags are two of the officially supported configuration keys under models:.

The correct answers are A: run-operation and E: snapshot.

According to dbt’s retry documentation, the dbt retry command works by examining the artifacts of a previous invocation (manifest, run results) and then re-running failed nodes for commands that generate node executions. Only commands that write run results and maintain execution state can be retried. These include dbt run, dbt test, dbt seed, dbt snapshot, and dbt run-operation when the operation executes nodes or macros that generate runtime artifacts.

Option A is correct because run-operation supports retry when the macro being run triggers execution tracked in run results. Option E is correct because snapshots execute SQL against the warehouse and record stateful results, meaning dbt can retry failed snapshots using the retry mechanism.

Options B (parse), C (debug), and D (deps) do not create runnable nodes or execution results; they simply validate or install project resources. These commands do not produce retryable artifacts, so dbt retry cannot operate on them.

Thus, the only options that work with dbt retry from the list provided are run-operation and snapshot.

The dbt compilation error explicitly states that the model fct_tasks depends on a node named stg_tasks, but dbt cannot find any resource with that name in the project. dbt resolves ref('stg_tasks') at compile time by searching for a model, seed, or source named stg_tasks. When no such model exists, dbt raises the exact error shown: “depends on a node named 'stg_tasks' which was not found.”

This error occurs before execution and is unrelated to whether the table exists in the warehouse. For dbt, the existence of a warehouse table is irrelevant during compilation—only the presence of a declared dbt resource matters. Therefore, option C (no table in the warehouse) cannot cause this error.

Option A is incorrect because ephemeral models still count as dbt models, and dbt can resolve ref() to them without problem.

Option D is wrong because defining a model in schema.yml is optional and unrelated to dbt’s ability to find the model. Tests and documentation require YAML entries, but model definitions do not.

Thus, the only correct explanation is that no model file named stg_tasks.sql exists under /models, making Option B the correct choice.

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.

The correct answer is D: dbt run --select +1 my_model.

In dbt’s selection syntax, the + operator is used to include parents (upstream) and/or children (downstream) of a given node. When used as +my_model or my_model+, it means “include all ancestors” or “all descendants” respectively, with no limit on depth.

To limit how many levels of parents or children are included, dbt allows a numeric depth between the + and the resource name. +1 my_model (or my_model+1) means:

Select my_model

Plus only its first-degree parents (direct dependencies), and no further ancestors.

Because you want to materialize the models, you must use dbt run, not dbt compile. dbt compile only compiles SQL and does not create or update relations in the data platform.

So:

Option A (dbt run --select +my_model) would include all upstream ancestors, not just first-degree parents.

Options B and E use compile, so they don’t materialize.

Option C is just syntactically wrong.

Therefore, the only command that both runs models and limits selection to my_model plus its first-degree parents is dbt run --select +1 my_model.

In dbt, the Directed Acyclic Graph (DAG) is created from model dependencies, which dbt identifies only through two mechanisms: the ref() function for referencing dbt models and the source() function for referencing declared sources. These functions are explicitly designed to tell dbt how models relate to each other so that dbt can track lineage, enforce build order, and generate documentation.

Option A, {{ source('source', 'table') }}, correctly references a declared source. Any model using source() establishes an upstream dependency on that source table. dbt will therefore draw a lineage line in the DAG from the source to the model.

Option B, {{ ref('stg_jaffle_shop__customers') }}, is the canonical way to reference another dbt model. ref() ensures dbt determines dependencies at compile time, and thus creates a DAG edge between this model and its parent.

The remaining options do not create lineage:

C directly references a database object, which dbt cannot interpret as a dependency.

D uses a Jinja variable unrelated to lineage.

E is invalid, because source() requires two arguments: a source name and table name, not a dotted string.

Therefore, A and B are the only valid answers.

When converting a model-specific SQL query into a generic test, dbt expects the test macro to accept the two standard arguments used across all generic tests: model and column_name. These arguments allow dbt to automatically pass the correct table and the correct column when the test is applied in YAML.

The argument model represents the actual relation (table/view) being tested. dbt compiles the reference itself—so instead of writing ref('stg_orders'), generic tests always use {{ model }} to represent the referenced relation.

The argument column_name represents the actual column being tested. In this case, the hard-coded column amount_usd becomes the dynamic argument {{ column_name }}, allowing you to apply the logic to any numeric or validated column across multiple models.

So the generic version of your SQL becomes:

select *

from {{ model }}

where {{ column_name }} < 0

The other options are incorrect:

source is not the standard argument for generic tests.

model_name is not automatically passed by dbt.

field is not a recognized standard test argument.

Thus, the two correct standard arguments are model and column_name.