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).