Free DBT-Analytics-Engineering Practice Test Questions and Answers (2026)

The sources.yml file is the designated location in a dbt project to declare and configure raw data sources. By defining the source table's name (or identifier) in this central file, you decouple the raw database object from the models that reference it. When a raw object name changes, you only need to update its definition once in the sources.yml file. All models using the {{ source() }} function will automatically point to the new name without requiring any changes to the model files themselves. This approach adheres to the DRY (Don't Repeat Yourself) principle and significantly simplifies project maintenance.

A. Update the {{ source() }} function in each affected model: This is inefficient and error-prone. If a source is used in many models, you would have to manually update each file, violating the DRY principle.

C. Update the raw object names in the database: This option misinterprets the task. The goal is to adapt the dbt project to an external change, not to revert the change in the source database.

D. Create a new dbt project with the updated raw object names: This is an extreme and impractical solution. Creating an entirely new project for a simple name change is unnecessary and would create a significant maintenance burden.

1. dbt Labs Official Documentation

"Sources": "By declaring resources in your project

you can then refer to them from your models using the source function. ... This provides a clean way to refer to source tables

and it also provides a single location for describing your source data." This document establishes sources.yml as the single location for defining source tables.

2. dbt Labs Official Documentation

"Sources - Declaring a source": This section details the syntax for sources.yml

showing the identifier property. It states

"The identifier is the name of the source table in your database. If it is not provided

it will be default to the name of the source table." This confirms that the identifier field is the specific place to update the raw table name.

3. dbt Labs Official Documentation

"source function": "The source function is the primary way to reference a source table in a model. ... Using the source function also allows dbt to understand the dependencies in your project." This highlights how the function links models to the definitions in sources.yml

enabling the centralized update mechanism.

The dbt run command executes compiled dbt models. To specify which models to run, you use the --select flag (or its alias -s). The source: selector is used to select nodes based on their source dependencies. When you use dbt run --select source:sourcename.tablename, dbt leverages its understanding of the project's dependency graph (DAG) to identify and run only the models that directly depend on the specified source table. This is the standard and correct method for achieving the desired outcome.

A. dbt run --filter source:sourcename

The --filter flag is not a valid command-line option for the dbt run command for node selection. The correct flag is --select.

B. dbt run --models table:tablename

The selector syntax table:tablename is not a valid method for selecting models based on a source. The correct selector for sources is source:.

C. dbt run --model source:sourcename

While --model is a functional alias for --select, the official dbt documentation recommends using --select in new projects as it is the canonical and more explicit flag.

1. dbt Labs Official Documentation

"Node selection syntax": This document details the source: selector. It states

"The source: selector will select a source. When used with dbt run

this will run all of the models that select from this source."

Source: dbt Labs Documentation

docs.getdbt.com

"Reference" -> "Node selection" -> "Syntax". Section: "The source: selector".

2. dbt Labs Official Documentation

"dbt run command": This page lists the valid arguments for the dbt run command

showing --select as the primary flag for specifying models to run.

Source: dbt Labs Documentation

docs.getdbt.com

"Reference" -> "dbt Commands" -> "run". Section: "Arguments".

3. dbt Labs Official Documentation

"About command line options": This page clarifies that --models is an alias for --select and explicitly recommends using --select for clarity and future compatibility.

Source: dbt Labs Documentation

docs.getdbt.com

"Reference" -> "Node selection" -> "About command line options". Section: "Full flag list".

The UNIQUE constraint in SQL is a rule that enforces that all non-null values in a column or a group of columns must be distinct. Its primary purpose is to prevent duplicate values from being entered into the specified column(s), ensuring data integrity.

It is important to note that most SQL database systems (like PostgreSQL, Snowflake, and SQL Server) allow multiple NULL values in a column that has a UNIQUE constraint. This is because NULL is treated as an unknown value, and therefore one NULL is not considered equal to another NULL. However, this specific handling of NULLs does not invalidate the primary function of the constraint, which is to ensure the uniqueness of all defined values. The dbt Core unique test directly implements this principle to validate data quality in analytics models.

This is a "TRUE or FALSE" question; therefore, this section is not applicable.

1. dbt Labs Official Documentation

unique test: "This test validates that there are no duplicate values in a column. It is configured on a model's column."

Source: dbt Labs Documentation

Reference

Generic tests

unique.

2. PostgreSQL 16 Official Documentation

Unique Constraints: "Unique constraints ensure that the data contained in a column or a group of columns is unique among all the rows in the table. ... For the purpose of a unique constraint

null values are not considered equal."

Source: PostgreSQL 16 Documentation

Chapter 5. Data Definition

Section 5.4.5. Unique Constraints.

3. Snowflake Official Documentation

Constraints: "UNIQUE: Specifies that the column can contain only unique values. Note that unlike primary keys

unique keys allow NULL values. A unique constraint allows for any number of NULL values in the column."

Source: Snowflake Documentation

SQL Reference

DDL (Data Definition Language)

CREATE | ALTER TABLE ... CONSTRAINT.

The dbt test command is a core feature of dbt used for data quality assurance. Its primary purpose is to execute tests defined within a dbt project against the data in the warehouse. These tests, which can be generic (e.g., unique, notnull) or custom SQL queries, validate that the data produced by dbt models adheres to specific business rules and integrity constraints. A successful test run indicates that the data meets the defined quality standards, while failures alert developers to potential issues in the data or the transformation logic.

A. To compile the dbt project: This is incorrect. The dbt compile command is specifically used to generate executable SQL from project files without running it.

B. To seed the dbt project with static data: This is incorrect. The dbt seed command is used to load static data from CSV files into the data warehouse.

C. To execute the dbt run command: This is incorrect. The dbt run command is a distinct command used to execute the SQL for dbt models, creating tables and views.

1. dbt Labs Documentation

dbt test command: "dbt test will run tests on your data. dbt ships with four generic tests out of the box: unique

notnull

acceptedvalues and relationships... You can also write your own

custom data tests to test any assertion about your data that you can write in SQL." (Reference: dbt test command page).

2. dbt Labs Documentation

About dbt commands: This page provides a high-level overview of the different commands and their purposes

clearly distinguishing test from run

compile

and seed. (Reference: About dbt commands page).

3. dbt Labs Documentation

dbt compile command: "The dbt compile command generates executable sql from your project's model

test

and analysis files." (Reference: dbt compile command page).

4. dbt Labs Documentation

dbt seed command: "The dbt seed command loads data from csv files into your data warehouse. These csv files are located in the seed-paths directory of your dbt project (dbtproject.yml)." (Reference: dbt seed command page).

The view materialization in dbt does not store the query's resulting data in the database. Instead, it creates a database view, which is essentially a stored SQL query definition. When this view is queried by a downstream model or a BI tool, the database executes the underlying query at that moment, pulling the latest data from the source tables. This means no data is physically stored for the view itself.

The statement describes the behavior of the table materialization, not the view materialization. A model materialized as a table will execute its SQL and store the results in a new physical table within the data warehouse.

1. dbt Labs Official Documentation

"About materializations": "Views don't store data

but rather run the query behind them each time they are referenced." This section explicitly states that data is not stored for views.

Source: dbt Labs Documentation

Core > docs > dbt-versions > v1.8 (latest) > "About materializations".

Link: https://docs.getdbt.com/docs/build/materializations#view

2. dbt Labs Official Documentation

"table materialization": "When using the table materialization

your model is rebuilt as a table on each run

via a create table as statement... Tables are useful for models that are computationally expensive to build

as they can be referenced by downstream models without being re-calculated." This provides the direct contrast to the view materialization

clarifying which type stores data.

Source: dbt Labs Documentation

Core > docs > dbt-versions > v1.8 (latest) > "About materializations".

Link: https://docs.getdbt.com/docs/build/materializations#table

The statement is correct. In SQL, and by extension in dbt which compiles to SQL, UNION ALL is significantly more performant than UNION. The UNION operator combines the result sets of two or more SELECT statements and then performs a distinct operation to remove any duplicate rows. This de-duplication step is computationally expensive as it often requires sorting or hashing the entire combined dataset. In contrast, UNION ALL simply concatenates the result sets, including all duplicate rows, without performing the costly de-duplication step. Therefore, if duplicate rows are acceptable or if the datasets are known to be mutually exclusive, using UNION ALL will result in a faster and more efficient query.

The "False" option is incorrect because it ignores the fundamental operational difference between the two operators. UNION performs two operations: concatenation and de-duplication. UNION ALL performs only one: concatenation. The additional de-duplication step makes UNION inherently less performant.

1. dbt Labs Official Documentation (SQL Style Guide): The official dbt style guide explicitly recommends this for performance reasons.

Source: dbt Labs

"SQL Style Guide"

Reference: In the "Be specific" section

the guide states: "Prefer union all to union. The union command performs a union all then a distinct. If you don't need to remove duplicate records

union all is much more performant."

Link: https://docs.getdbt.com/guides/best-practices/how-we-style-our-dbt-projects/3-be-specific#prefer-union-all-to-union

2. dbt Labs Official Documentation (dbt-utils package): The widely used unionrelations macro within the dbt-utils package defaults to using UNION ALL

reinforcing this as a best practice for performance.

Source: dbt Labs

dbt-utils Package Documentation

unionrelations

Reference: The macro is designed to "stack a list of relations on top of each other" and by default

it generates a series of select ... from ... union all statements. This design choice prioritizes performance.

Link: https://github.com/dbt-labs/dbt-utils#unionrelations-source

3. Vendor Documentation (Google Cloud for BigQuery): The documentation for major data warehouses

which execute the SQL generated by dbt

confirms this performance principle.

Source: Google Cloud

"BigQuery optimized SQL patterns: part 1"

Reference: In the section on "Set operators"

the documentation advises: "If your data doesn't have duplicates or you don't need to eliminate them

use UNION ALL for better performance. BigQuery must do extra work to remove duplicate rows for UNION DISTINCT (or UNION)."

Link: https://cloud.google.com/blog/products/bigquery/bigquery-optimized-sql-patterns-part-1

4. Vendor Documentation (Snowflake): Snowflake's documentation also highlights the performance advantage of UNION ALL.

Source: Snowflake Documentation

"UNION & UNION ALL"

Reference: The documentation notes: "UNION ALL is much faster than UNION because UNION ALL does not search for and remove duplicate rows."

Link: https://docs.snowflake.com/en/sql-reference/operators-set#union-union-all

Configuring an incremental model in dbt involves several key steps. First, the model must be explicitly defined as incremental by setting materialized='incremental' in its configuration block (C). The core logic for an incremental run is to process only new or changed data. This is achieved by filtering the source data, typically by adding a WHERE clause to the model's SQL that leverages the isincremental() macro (B). To handle updates to existing records and prevent duplicates, a uniquekey can be specified. This key enables dbt to match records between the source and destination, performing an update/merge operation instead of a simple append (D).

A. partitionby is a data warehouse-specific configuration for performance optimization that physically organizes data. It is not a primary method for defining the incremental logic of which records to process.

1. dbt Labs Documentation

"Incremental models":

Reference for C: Under the "How do I use incremental models?" section

the first step listed is: "To use incremental models

you need to set the materialized configuration for a model to incremental."

Reference for B: The same section explains the second step: "You also need to tell dbt how to filter the rows for an incremental run... using the isincremental() macro." This macro is used within a WHERE clause.

Reference for D: The section "How do I use uniquekey?" states: "The optional uniquekey parameter enables updating existing rows instead of just appending new rows. If a uniquekey is specified

dbt will use a merge statement to build the model."

2. dbt Labs Documentation

"About materializations":

Reference for C: This page defines the incremental materialization: "Models can be configured as incremental... dbt will insert new records and update existing records in the table." This confirms materialized='incremental' is the foundational configuration.

3. dbt Labs Documentation

"BigQuery configs" (as an example of adapter-specific configs):

Reference for A: The partitionby configuration is listed as a specific configuration for warehouses like BigQuery to improve query performance by partitioning tables. It is described as a physical layout property

distinct from the logical filtering (WHERE clause) or update strategy (uniquekey) of the incremental model itself.

The dbt debug command is a diagnostic utility designed to help users troubleshoot their dbt project setup. Its primary functions are to test the connection to the data warehouse, validate the dbtproject.yml and profiles.yml files, and report on the dbt environment. This command does not perform a compilation step; it does not parse Jinja-SQL into executable SQL. Consequently, no compiled code is generated or saved to the target/ directory on disk. The command specifically designed to generate and save compiled SQL without executing it is dbt compile.

The "False" option is incorrect. If the statement were false, it would imply that dbt debug does save compiled code to disk. This is functionally inaccurate. The dbt debug command is strictly for configuration and connection validation. It is separate from the build-related commands (compile, run, build, test) that are responsible for parsing and materializing project code.

1. dbt Labs Official Documentation

dbt debug command: "dbt debug is a utility command that helps you troubleshoot your dbt project. It tests your database connection and displays information about your dbt installation and project... It does not run any of your dbt models

tests

or other resources." This source confirms the command's purpose is diagnostic and does not involve running or compiling models.

Source: dbt Labs Documentation

"dbt debug command". Retrieved from https://docs.getdbt.com/reference/commands/debug

2. dbt Labs Official Documentation

dbt compile command: "Generates executable SQL from your project's model

test

and analysis files. You can find these compiled SQL files in the target/ directory of your dbt project." This source explicitly identifies dbt compile as the command responsible for generating and saving compiled SQL

contrasting it with the function of dbt debug.

Source: dbt Labs Documentation

"dbt compile command". Retrieved from https://docs.getdbt.com/reference/commands/compile

3. dbt Labs Official Documentation

About the target/ directory: "When you run dbt

it generates artifacts in the target directory... The compiled directory contains the compiled SQL for your models." This reference clarifies that compiled artifacts are placed in the target/ directory by commands that perform compilation

a group to which dbt debug does not belong.

Source: dbt Labs Documentation

"The target/ directory". Retrieved from https://docs.getdbt.com/reference/dbt-artifacts#the-target-directory

The statement provides a correct and standard definition of a SQL subquery. A subquery, also known as an inner query or nested query, is a complete SELECT statement that is embedded within the clause of another SQL statement (the outer query). The database executes the subquery first, and the result set returned by the subquery is then used by the outer query to filter, evaluate, or complete its operation. This technique is fundamental for performing complex data retrieval and transformations, which are core activities in dbt analytics engineering.

The "False" option is incorrect. The provided statement accurately describes both the structure (a query within a query) and the function (providing intermediate results to an outer query) of a SQL subquery, which is a foundational concept in SQL and, by extension, in dbt.

1. dbt Labs Documentation

Glossary: While the dbt documentation focuses heavily on Common Table Expressions (CTEs) as a more readable alternative

it operates on the fundamental SQL principle that models are SELECT statements. Subqueries are a standard feature of SELECT statements. The dbt Glossary defines a model as "a single select statement

" and subqueries are a core component of how complex select statements are constructed.

Source: dbt Labs

"Glossary

" under the definition of "model." (URL: https://docs.getdbt.com/docs/glossary)

2. Snowflake Documentation (Official Vendor): Snowflake

a primary data platform for dbt

explicitly defines subqueries in its documentation.

Quote: "A subquery is a query within another query. The outer query is called the parent query

and the inner query is the subquery. The subquery is executed first

and the result of the subquery is used by the parent query."

Source: Snowflake Documentation

"Working with Subqueries." (URL: https://docs.snowflake.com/en/user-guide/queries-subqueries)

3. PostgreSQL Documentation (Official Vendor): PostgreSQL documentation provides a similar

authoritative definition.

Quote: "A subquery is a SELECT statement that is nested inside another statement... The subquery is executed and its result is substituted into the outer query."

Source: PostgreSQL 16 Documentation

Chapter 9: Functions and Operators

Section 9.23: "Subquery Expressions." (URL: https://www.postgresql.org/docs/current/functions-subquery.html)

4. Stanford University Courseware: Academic materials for database courses confirm this definition as a foundational concept.

Concept: Lecture notes for database courses like Stanford's CS145 (Introduction to Databases) define a subquery as a SELECT-FROM-WHERE expression nested inside another query

whose result is used by the containing query.

Source: Stanford University

CS145 Introduction to Databases

Lecture Notes on "Subqueries in SQL." (Example URL structure: https://web.stanford.edu/class/cs145/)

An incorrect reference to another model, such as {{ ref('nonexistentmodel') }}, utilizes dbt's ref function. This function is a core component of dbt's Jinja templating engine and is not standard SQL. The dbt compilation process parses these ref functions to build the Directed Acyclic Graph (DAG) of dependencies before any SQL code is sent to the data warehouse for execution. If dbt cannot find the model being referenced, it will raise a compilation error. This error originates from and is reported by dbt itself, indicating an issue within the dbt project's code structure or logic. Therefore, it is fundamentally a dbt issue, not a SQL execution error.

The alternative, False, is incorrect because the error's root cause lies in a dbt-specific construct (ref), not in the SQL syntax that the data warehouse would execute. The data warehouse never sees the {{ ref(...) }} syntax; it only receives the pure, compiled SQL. If the reference is wrong, dbt cannot compile the code correctly, and the process halts with a dbt-level error before the warehouse is even involved in executing the query.

1. dbt Labs Official Documentation

ref function: "The ref function is how you refer to other models in dbt... When you use ref

dbt interpolates the schema/database and identifier for this model into your query. More importantly

dbt uses these refs to automatically build the dependency graph." This establishes that ref is a dbt-managed mechanism.

Source: dbt Docs

"Jinja Functions: ref". Retrieved from https://docs.getdbt.com/reference/dbt-jinja-functions/ref

2. dbt Labs Official Documentation

Building a dbt Project: "When you execute the dbt run command

dbt will first compile your code into executable SQL. Compilation involves... resolving any ref or source calls." This confirms that reference resolution is a distinct compilation step handled by dbt.

Source: dbt Docs

"How dbt works". Retrieved from https://docs.getdbt.com/docs/introduction/how-dbt-works

3. dbt Labs Official Documentation

Troubleshooting: Common errors include "Compilation Error... dbt was unable to find a model with the name...". This type of error message explicitly demonstrates that dbt is the tool identifying and reporting the issue with the model reference.

Source: dbt Docs

"FAQs: Troubleshooting". Retrieved from https://docs.getdbt.com/faqs/troubleshooting (This page discusses common errors

including compilation exceptions related to missing refs).

The statement is correct. Window functions are a powerful feature in SQL that dbt models leverage to perform complex calculations over a specific set of rows, or "window," related to the current row. They can compute aggregates like sums, averages, or ranks without collapsing the rows as a GROUP BY clause would. This capability directly replaces older, often less efficient, patterns that required self-joins or subqueries to achieve the same result. By using a window function, an analyst can calculate, for example, a running total or a percentage of a total in a single, more readable step, which often allows the database's query planner to generate a more optimized execution plan.

This is a True/False question. The statement is factually correct, so "False" is the incorrect option. Declaring the statement as false would ignore a primary use case and benefit of window functions in modern analytical SQL, which is a core component of dbt modeling. The alternative to window functions for these tasks (e.g., calculating a value for a row based on an aggregate of its group) is typically a subquery that calculates the aggregate, which is then joined back to the original data. This multi-step process is generally less performant and harder to read than a single window function call.

1. dbt Labs Developer Blog

"How to use window functions in SQL": This official guide explicitly states

"Window functions are a powerful SQL feature that can help you write cleaner and more efficient queries." It provides examples of calculating running totals and moving averages

noting that these functions "allow you to perform calculations that would otherwise require complicated joins and subqueries." This directly supports the claim that they reduce the need for these constructs and help optimize queries.

2. dbt Labs Documentation

"Refactoring SQL for modularity": In the section "Refactoring a query that computes market share

" the guide shows a "before" query that uses a subquery in a JOIN to calculate a total denominator for a percentage calculation. The "after" version refactors this logic using the window function sum(amount) over (). The text notes that the refactored version is more modular and readable

which are key aspects of optimization in a dbt project. This provides a concrete example of a window function replacing a subquery.

3. Stanford University

CS 145 Introduction to Databases

Lecture Notes on "Advanced SQL": University courseware on databases frequently covers the benefits of window functions. For instance

lecture notes often contrast the performance and readability of a query using RANK() OVER (...) with an equivalent query using a correlated subquery or a self-join. The materials explain that the database optimizer can often process the single scan required for a window function more efficiently than the multiple scans or complex logic required for the older constructs. (Note: Specific slide/page numbers vary by semester

but this is a standard topic in advanced SQL sections of university database courses).

The statement is false. dbt's core philosophy and recommended best practices advocate for modularity. Instead of a single, monolithic model, transformations should be broken down into multiple, smaller, and logically distinct models. These models are typically organized into layers (e.g., staging, intermediate, and marts). This approach makes the project more maintainable, easier to debug, and allows for incremental testing of each transformation step. While this creates a more complex Directed Acyclic Graph (DAG), the resulting DAG is more readable and accurately represents the flow of data transformations, which is the intended purpose. A single model for all transformations is considered an anti-pattern.

The "True" option is incorrect because it misinterprets the goal of DAG simplicity. The objective is not to have the fewest nodes possible in a DAG, but to have a DAG that is clear, logical, and easy to understand. A single, massive model hides all complexity within its code, making the project brittle, difficult to debug, and nearly impossible to test in a granular way. The dbt best practice is to use the DAG to visualize and manage the complexity of data transformations, which is achieved by building many small, interdependent models.

1. dbt Labs Official Documentation

"How we structure our dbt projects": This guide explicitly details the best practice of using multiple layers and models. It states

"By breaking down complex logic into smaller

more manageable pieces

we can improve the modularity

reusability

and maintainability of our dbt project. This is a core tenet of dbt." The guide then outlines the multi-layered approach (staging

intermediate

marts)

which inherently requires many models

not one.

2. dbt Labs Official Documentation

"What is a dbt model?": The documentation defines a model as a single select statement. The entire concept of the ref() function

a cornerstone of dbt

is built on the principle of creating dependencies between multiple models. The documentation explains

"The ref function is the most important function in dbt. It's how you refer to other models

" which presupposes a multi-model project structure.

3. dbt Labs Official Documentation

Best Practice Guides

"Building a scalable dbt project": This guide emphasizes the importance of model layering for scalability and maintainability. It advises

"Layering your models is a key part of a scalable dbt project. It allows you to build up your transformations in stages

making them easier to debug and manage." This directly contradicts the idea of using a single model.

The dbt seed command supports dbt's standard node selection syntax, which can be applied using the --exclude flag. The most direct and fundamental method to exclude a specific seed is by its resource name. The resource name is derived from the seed's filename (e.g., myseed for the file myseed.csv). This method allows for precise and straightforward control over which individual seeds are excluded from the dbt seed operation without requiring additional configuration like tags or relying on file paths.

A. --exclude path:pathname/: This is a valid selection method to exclude all seeds within a specific directory, but it is not the most direct way to exclude a single, named seed.

B. --exclude config.materialized:materializationtype: This selector is impractical for seeds. All seeds have the same materialization type (seed), so this cannot be used to selectively exclude one seed from another.

C. --exclude tag:tagname: This is a valid method, but it requires the extra step of configuring tags on the seeds in dbtproject.yml, making it less direct than simply using the seed's name.

1. dbt Labs. (n.d.). Node selection syntax. dbt Docs. Retrieved from https://docs.getdbt.com/reference/node-selection/syntax. (This documentation confirms that you can select/exclude resources directly by their name

as well as by path:

tag:

and config:.)

2. dbt Labs. (n.d.). dbt seed command. dbt Docs. Retrieved from https://docs.getdbt.com/reference/commands/seed. (This reference states that the seed command accepts --select and --exclude arguments to run a subset of seeds.)

3. dbt Labs. (n.d.). About dbt selectors. dbt Docs. Retrieved from https://docs.getdbt.com/reference/node-selection/selectors. (This document clarifies the hierarchy and types of selectors

noting that "The most basic selector is the name of a resource.")

The CHECK constraint in SQL is used to enforce domain integrity by ensuring that all values in a column or a set of columns satisfy a specified Boolean expression. When a CHECK constraint is defined on a column, the database management system (DBMS) validates any new or updated data against this expression. If the expression evaluates to FALSE, the INSERT or UPDATE operation is rejected. This directly limits the set of permissible values that can be stored in the column, enforcing a specific business rule or data validation logic.

This is a "True or False" question. The statement is factually correct according to standard SQL definitions and implementations. Therefore, selecting "False" would be incorrect as it contradicts the fundamental purpose of the CHECK constraint. Other constraints serve different purposes: NOT NULL ensures a value is present, UNIQUE ensures no duplicate values, and FOREIGN KEY ensures referential integrity, but CHECK is specifically for validating the value itself against a condition.

1. PostgreSQL 16 Documentation

Chapter 5. Data Definition

Section 5.4.5. Check Constraints:

"A check constraint specifies that the values in a column must satisfy a Boolean (truth-value) expression. The expression should return true or unknown for the constraint to succeed. ... A check constraint specified as a column constraint should only reference that column's value

while a check constraint specified as a table constraint can reference multiple columns."

This source confirms that the core function is to ensure column values satisfy a specific expression

thereby limiting them.

2. Snowflake Documentation

SQL Reference

CREATE TABLE

tableconstraint:

Under the definition of constraints

it lists CHECK ( ). The purpose of constraints is to "ensure data integrity". The CHECK constraint achieves this by evaluating the expression for each row

which limits the values to only those for which the expression is not false.

3. Stanford University

CS 145: Introduction to Databases

Lecture Notes on SQL:

In the section covering Data Definition Language (DDL) and constraints

the CHECK constraint is defined as: CHECK . The notes explain that this constraint ensures that attribute values must satisfy the specified condition. For example

CHECK (rating >= 1 AND rating <= 10) limits the rating column to integers between 1 and 10

inclusive. This is a direct example of limiting values in a column.

The dbt command line interface (CLI) and the corresponding log file (logs/dbt.log) provide the most direct and detailed information for debugging. When a Jinja rendering error occurs, such as a macro being called with missing arguments, dbt generates a traceback. This traceback explicitly states the error, the model file (.sql) where the error occurred, and the exact line number of the problematic macro call. This makes the log output the primary and most efficient resource for pinpointing the source of compilation errors.

B. Inspect the model's compiled SQL code: The error occurs during the Jinja compilation phase. The compiled SQL file in the target/ directory may not be generated or could be incomplete, as the rendering process failed.

C. Check the manifest.json file: The manifest.json file contains the parsed structure and metadata of the dbt project. It does not contain runtime execution details or error tracebacks from a specific dbt run.

D. Examine the runresults.json file: While runresults.json records the final status and the error message for the failed model, it lacks the detailed, line-specific traceback that is readily available in the log output.

---

1. dbt Labs Official Documentation

"Debugging errors": "The error message from dbt should point you in the right direction. If you're lucky

it will even include a line number where the error is occurring." This confirms that the primary source for error details

including line numbers

is the message output from the dbt run

which is captured in the logs.

Source: dbt Labs Documentation

Core > dbt-Core fundamentals > dbt-core Developer Hub > Guides > "Debugging errors".

2. dbt Labs Official Documentation

"Logging": "dbt writes events to two different places: stdout (the command line) and a log file (logs/dbt.log). By default

dbt will write INFO-level log messages and above to both of these locations." This establishes the log file as the canonical record of the run's output

including error tracebacks.

Source: dbt Labs Documentation

Core > dbt-Core fundamentals > dbt-core Developer Hub > Reference > "Logging".

3. dbt Labs Official Documentation

"run command": The documentation for the dbt run command details the output users can expect

which includes status updates and error messages for failed models. The example outputs clearly show that errors are printed directly to the console.

Source: dbt Labs Documentation

Core > dbt-Core fundamentals > dbt-core Developer Hub > Reference > dbt-Commands > run.

The {{ ref() }} function is a fundamental Jinja macro in dbt used to reference other models. Its primary purpose is to enable modular data modeling by allowing you to select from the output of another model. When dbt parses a project, it uses these ref calls to automatically infer dependencies between models. This process builds the Directed Acyclic Graph (DAG), which dictates the correct execution order for dbt run. Therefore, ref is utilized both to reference a model within another (its direct action) and to build the dependency graph (its critical outcome).

A. The ref function resolves to a table or view name; it does not execute the SQL query. The surrounding SQL statement (e.g., SELECT) performs the execution.

B. Model configurations, such as materialization or tags, are defined using the {{ config() }} macro or in .yml files, not with ref.

1. dbt Labs Official Documentation

ref function: "The ref function is the most important function in dbt. It's the way you refer to other models... More importantly

dbt uses these refs to automatically build the dependency graph between models. This is what allows dbt to run models in the correct order..."

Source: dbt Labs Documentation

Jinja Functions

ref.

2. dbt Labs Official Documentation

About dbt models: "The ref function is how you reference one model within another. This is a core concept in dbt

as it allows dbt to automatically build a dependency graph of all of your models."

Source: dbt Labs Documentation

Core concepts

dbt models

About dbt models.

3. dbt Fundamentals Course

Building your first dbt models: "Instead of writing the schema and table name

we can use the ref function... When you use ref

dbt knows that your current model depends on the model being referenced. This is how dbt is able to build your DAG and determine the correct order to run your models in."

Source: dbt Labs

dbt Fundamentals Course

Section: Building your first dbt models.

The dbtproject.yml file uses YAML (YAML Ain't Markup Language) syntax, which is strictly dependent on indentation to define structure and hierarchy. An incorrect indentation level is a syntax error that will cause the YAML parser to fail before dbt can even begin to interpret the file's contents. This type of parsing failure is a common compilation error and is the most fundamental issue to check first, as it prevents any other configurations, keywords, or dependencies within the file from being read correctly.

A. Incorrectly defined dependencies: This typically causes errors when running the dbt deps command, not a compilation error related to parsing the dbtproject.yml file itself.

B. Misspelled keywords: While this will cause a compilation error, an indentation error is more fundamental. The parser must successfully interpret the file's structure (via indentation) before it can validate the keywords.

C. None of the above: Incorrect indentation is a frequent and valid cause of compilation errors in dbtproject.yml, making this option incorrect.

1. dbt Labs Official Documentation

"Project configurations": In the documentation for dbtproject.yml

it is stated: "Because this file is written in YAML

indentation is important. We recommend using two spaces for indentation." This highlights the critical role of indentation in the file's syntax. (Source: dbt Labs

dbt Core documentation

"Project configurations"

dbtproject.yml section).

2. dbt Labs Official Documentation

"About dbtproject.yml": This page establishes that the file is a YAML file

and the core principle of YAML syntax is its reliance on indentation for data structure. Any deviation from the expected indentation will result in a parsing error. (Source: dbt Labs

dbt Core documentation

"About dbtproject.yml").

The dbt snapshot command is used to execute snapshot configurations defined in a dbt project. Snapshots are a mechanism for capturing the state of a mutable source table over time. This process records changes to data, creating a historical archive of how records have evolved. This is a common method for implementing Type 2 Slowly Changing Dimensions (SCDs), which track historical data by creating multiple records for a given natural key, with each record having distinct start and end dates. The command applies the logic defined in snapshot files to the data warehouse, effectively capturing a point-in-time "snapshot" of the source data.

A. dbt docs generate is the command used to generate documentation for a dbt project, not dbt snapshot.

B. Backups of a dbt project's code are typically managed through version control systems like Git, not a specific dbt command.

C. The dbt run command is used to execute specific dbt models, not dbt snapshot.

1. dbt Labs Documentation

"Snapshots": "Snapshots implement type-2 slowly changing dimensions over mutable source data. The dbt snapshot command will apply the logic in your snapshot files to your warehouse."

Source: dbt Labs Official Documentation

About dbt Core -> Core concepts -> Snapshots.

2. dbt Labs Documentation

"snapshot command": "The dbt snapshot command is used to execute snapshots defined in your project."

Source: dbt Labs Official Documentation

dbt Command reference -> snapshot.

The --exclude argument in the dbt source freshness command utilizes dbt's node selection syntax to filter out sources that would otherwise be checked. This provides a flexible mechanism to omit specific sources from the freshness calculation based on a wide range of criteria. These criteria can include the source's name, its path, tags applied to it, or its package, among other selectors. This allows developers to selectively run freshness tests, for example, to ignore sources that are known to be stale or are not relevant to a particular run.

B. Excludes sources by tag: This is an incomplete answer. While you can exclude sources by tag (e.g., --exclude tag:mytag), this is just one of many selection methods supported, not the argument's sole function.

C. Excludes sources of a specific type: The dbt source freshness command operates exclusively on the source resource type by default, so excluding by type in this context is not a primary or logical use case.

D. Excludes sources by materialization: Sources are not materialized by dbt; they are pointers to existing data in a database. Therefore, they do not have a materialization property and cannot be excluded on this basis.

---

1. dbt Labs Official Documentation

dbt source freshness command: This document confirms that the dbt source freshness command accepts the --exclude argument for node selection.

Reference: In the "Command reference" section for dbt source freshness

it states

"This command accepts select and exclude arguments..."

URL: https://docs.getdbt.com/reference/commands/source-freshness

2. dbt Labs Official Documentation

Node selection syntax: This page details the various methods and criteria available for the --select and --exclude arguments

demonstrating that selection is based on multiple criteria

not just tags.

Reference: The "Selection methods" section lists various selectors like fqn:

tag:

source:

and path:.

URL: https://docs.getdbt.com/reference/node-selection/syntax

3. dbt Labs Official Documentation

About sources: This document clarifies that sources are declared representations of raw data and are not created or materialized by dbt.

Reference: The "About sources" page states

"Sources make it possible to name and describe the raw data loaded into your warehouse." This confirms they lack a dbt materialization property.

URL: https://docs.getdbt.com/docs/build/sources

Best practices for structuring a dbt project emphasize scalability, maintainability, and clarity. Organizing models into logical directories (e.g., staging, intermediate, marts) provides a clear, layered architecture that reflects the data transformation process and makes the project easier to navigate. Using modularization through reusable macros adheres to the "Don't Repeat Yourself" (DRY) principle. This reduces code duplication, centralizes business logic, and simplifies maintenance, as a change in one macro propagates to all its uses. These two practices are fundamental to building robust and professional dbt projects.

A. Avoiding the use of variables and configurations: This is incorrect. Variables and configurations are essential dbt features for managing environments (dev/prod), parameterizing models, and making projects flexible and adaptable without hardcoding values.

B. Including extensive comments in the SQL code: This is not a primary best practice. dbt encourages self-documenting code through clear naming and structure, and formal documentation via description fields in YAML files, which populate the dbt Docs site.

1. dbt Labs Documentation

"How we structure our dbt projects": This guide explicitly details the best practice of organizing models into directories. It states

"We structure our dbt projects into a few different directories... This structure helps us keep our project organized and easy to navigate." It specifically recommends staging

marts

and intermediate directories.

Source: dbt Labs Documentation > dbt Core > Guides > Best practice guides > How we structure our dbt projects.

2. dbt Labs Documentation

"About dbt projects": This section highlights the importance of directory structure. It notes

"The models/ directory is where you'll write the SQL (or Python) for the models that will make up your project... You can create subdirectories within the models/ directory to help you organize your models."

Source: dbt Labs Documentation > dbt Core > dbt projects > About dbt projects > Project structure.

3. dbt Labs Documentation

"Macros": The documentation introduces macros as a way to write reusable code. It states

"Macros in Jinja are pieces of code that can be called multiple times – they are analogous to 'functions' in other programming languages... Don't Repeat Yourself (DRY)." This directly supports the practice of modularization.

Source: dbt Labs Documentation > dbt Core > Jinja & macros > Macros.

4. dbt Labs Documentation

"Don't Repeat Yourself": This best practice guide explicitly advises against repeating code and promotes the use of macros. "If you find yourself copying and pasting SQL

consider creating a macro instead."

Source: dbt Labs Documentation > dbt Core > Guides > Best practice guides > Don't Repeat Yourself.