dbt Labs dbt-Analytics-Engineering dbt Analytics Engineering Certification Exam Exam Practice Test

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.

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 correct answers are C: Exposures describe a downstream use of your dbt project and E: You can run, test, and list resources that feed into your Exposure.

Exposures in dbt are documentation constructs that describe how the outputs of your dbt project are used downstream—such as dashboards, machine learning models, applications, reporting layers, or external tools. They exist to provide visibility into the final layer of the analytics workflow, making it easier to track lineage from raw data → models → downstream consumers.

Option C is correct because the official dbt documentation explicitly states that exposures define the downstream use cases of dbt models. They create transparency about dependencies outside the dbt DAG itself.

Option E is also correct. Using commands like dbt ls --select +exposure: or dbt run --select +exposure:, dbt enables users to run, test, and inspect the upstream resources feeding into the exposure. This is extremely valuable for impact analysis and CI workflows.

Option A is incorrect because exposures are downstream, not upstream—meaning models feed into exposures, not the other way around.

Option B is incorrect because exposures are not materialized in the warehouse; they are metadata stored in YAML.

Option D is incorrect because exposures are defined in YAML files, not SQL files.

Thus, C and E are the correct statements.

In dbt, source freshness can be defined at the source level (affecting all tables) or overridden at the individual table level. When freshness is declared at the source root, dbt applies the freshness policy to every table within that source unless a specific table opts out. The official dbt documentation states that setting:

freshness: null

at the table level disables freshness checks for that specific table, even when the source itself defines default freshness rules. This is the only documented way to exclude an individual table from a source freshness policy.

Option B is incorrect because tables can override and disable freshness even when the parent source defines it. dbt’s configuration hierarchy supports overriding child-level settings on a per-resource basis.

Option C (loaded_at_field: null) does not disable freshness—it simply removes the loaded_at_field, which would cause dbt to error because a freshness check requires a timestamp field to operate.

Option D (error_after: null) only removes the error threshold but does not disable freshness. The table would still participate in freshness checks and could trigger warnings.

Thus, the correct and dbt-supported method to exclude a table from freshness is to explicitly set:

freshness: null

making A the correct answer.

In dbt, a singular test is any SQL file placed directly inside the tests/ directory—not inside the tests/generic/ folder. Singular tests contain a custom SQL query where returning any rows means failure. They are distinct from generic tests, which are YAML-defined and live inside the generic directory, often referencing macros.

Looking at the folder structure:

In tests/generic/

furniture_customers_test.sql → This is a generic test, not a singular test.

In the root tests/ directory

macro_stg_tpch_orders_assert_pos_price.sql → singular test

macro_stg_tpch_suppliers_assert_pos_acct_bal.sql → singular test

stg_tpch_orders_assert_positive_price.sql → singular test

When you run:

dbt test --select 'test_type:singular'

dbt selects only singular tests, meaning tests that are individually written SQL files in the top-level tests/ directory.

Therefore, dbt will run:

macro_stg_tpch_orders_assert_pos_price

macro_stg_tpch_suppliers_assert_pos_acct_bal

stg_tpch_orders_assert_positive_price

It will not run furniture_customers_test, because that file is inside tests/generic/, which is reserved for template-based generic tests and is not classified as singular.

Thus, the correct answer is Option C.

The correct answer is A: Information is gathered from the use of source and ref macros.

dbt determines the dependency graph — the DAG — by analyzing calls to ref() and source() inside model SQL files. These macros explicitly declare relationships between models. When a developer writes ref('orders'), dbt interprets this as: “the current model depends on the orders model.” Similarly, source() indicates dependencies on upstream raw data sources. This declarative approach allows dbt to build a structured and deterministic DAG without scanning SQL for implicit table references.

Option B is incorrect because dbt does not query database objects to infer dependencies; it resolves dependencies at compile time through metadata generated from model files. Option C is incorrect because dbt intentionally does not parse SQL to detect table names—this would be brittle and error-prone across warehouses. Instead, dbt requires explicit references to maintain reliability. Option D is incorrect because YAML files define metadata about models and sources but do not create dependency relationships between them.

Thus, the dependency graph is built exclusively by reading ref() and source() macro calls, which ensures clarity, correctness, and maintainability within the analytics engineering workflow.

The correct answer is C: Underlying data must be accessible on your data platform.

dbt does not perform data ingestion or data loading. Instead, dbt operates after raw data is already available in your warehouse. This means that before dbt can build any models—whether staging, intermediate, or mart-layer models—the underlying source data must already exist and be accessible in the connected data platform (Snowflake, BigQuery, Redshift, Databricks, etc.). dbt uses SQL to transform existing relations; therefore, if the data platform cannot access the underlying tables or external sources, model execution will fail.

Option A is incorrect because sources do not need to be defined before building models. Models can be built without using sources at all. Source definitions are optional metadata and lineage declarations, not prerequisites.

Option B is incorrect because service accounts are not required; dbt can connect through any credential mechanism supported by the warehouse (OAuth, user accounts, tokens, etc.).

Option D is incorrect because dbt itself performs transformations on raw data—cleaning raw data beforehand is not required; in fact, that is one of dbt’s main responsibilities.

Thus, the only true prerequisite is that the warehouse must contain accessible underlying data.

This test is a singular test, meaning it is defined as a standalone SQL file placed inside the /tests directory (not attached through YAML like generic tests). dbt executes singular tests by running the SQL query, and the test fails if the query returns any rows. In this case, the test selects all records from fct_orders where status_code = 13. That means if even one row in fct_orders has a status code of 13, the test will fail, because dbt interprets returned rows as evidence of a data-quality issue.

The configuration block at the top sets severity='error', meaning the test raises an error when it fails, rather than a warning. This setting overrides default severity behavior, so option B is incorrect. Singular tests do not need to be attached in YAML because they run automatically when placed under /tests → making option A incorrect. Meanwhile, generic tests live in /tests/generic, but singular tests should live directly under /tests (option C incorrect).

Therefore, the only correct statement is that records with status_code = 13 will cause the test to fail, because the test query is explicitly written to identify such rows.

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.

1. There is a config block at the top of the model with materialized = 'table'

➡️ Answer: False

2. The corresponding table already exists in the data warehouse

➡️ Answer: True

3. The incremental model was executed with the --full-refresh flag

➡️ Answer: False

4. The corresponding table does not already exist in the data warehouse

➡️ Answer: False

The is_incremental() macro in dbt is used within an incremental model to determine whether the current invocation should perform an incremental update or a full rebuild. It evaluates to True only during an incremental run when the target table already exists in the data warehouse and dbt is not performing a full refresh.

For is_incremental() to return True, two conditions must be met:

The model must be materialized as incremental, not table or view.Therefore, if the config specifies materialized = 'table', the model is not incremental, and the function evaluates to False.

The table already exists in the target schema.In this case, dbt will run the model in incremental mode, making is_incremental() return **True`.

If the incremental model is run with --full-refresh, dbt intentionally rebuilds the entire table, meaning is_incremental() evaluates to False, even if the table exists.

Lastly, if the target table does not exist yet, dbt must create it from scratch, so the run is treated as a full rebuild, not an incremental update, causing is_incremental() to evaluate to False.

Thus, the only scenario where is_incremental() returns True is when the table exists and the model is actually incremental.

In dbt, the source() function resolves a source by its declared source name and table name, not by the physical schema or identifier in the warehouse. The YAML block defines a source named jaffle_shop, and under that source, a table named orders. The identifier: customer_orders field tells dbt that although the logical table name is orders, the actual physical object in the warehouse is named customer_orders.

dbt always expects the syntax:

{{ source(source_name, table_name) }}

Here, the correct reference uses jaffle_shop as the source name and orders as the table name because these are the logical names assigned in the YAML. dbt internally resolves the physical table name via the identifier field, so the model should not reference customer_orders directly.

Option A and B are incorrect because the first argument is not the schema; dbt does not use schemas in the source() call. Option D is incorrect because customer_orders is the warehouse identifier, not the logical table name recognized by dbt.

Therefore, the correct reference is:

{{ source('jaffle_shop', 'orders') }}

This ensures consistent modeling, dependency tracking, and accurate documentation.

The purpose of this question is to determine how to validate that the input values in the state column support the business logic that determines the is_active field. Since the logic checks whether state = 'Active', it is critical that the state column only contains values that the business process expects. In the example shown, acceptable states appear to be: 'active', 'churned', and 'trial'.

The correct way to enforce this expectation is to apply an accepted_values test on the state column. This ensures that any unexpected state (e.g., 'inactive', 'pending', 'deleted', or NULL) will cause the test to fail, alerting the team that the upstream system is producing unexpected or invalid values. Additionally, adding not_null ensures every user record contains a valid state.

Option A is the only configuration that applies the accepted values test to the correct column (state) and reflects the expected domain of values.

Options B and D incorrectly apply tests to the derived column is_active, not the source column that needs validation. Option C only checks nullability and uniqueness, which does not validate the range of allowed values and thus does not protect the business logic.

Therefore, Option A is the only correct answer.

Yes, this is a benefit of breaking large CTE-heavy SQL models into modular dbt models. According to dbt and Analytics Engineering best practices, modularity improves clarity, maintainability, and documentation quality. When CTEs remain embedded inside a single large SQL file, their purposes are often unclear, difficult to document, and hard for other developers to reuse. By extracting a logical CTE into its own model, dbt treats it as a first-class resource—meaning it can have its own description, tests, documentation, lineage, and metadata defined in YAML.

dbt’s documentation system allows each model to include a description explaining what the transformation does, the assumptions being made, and the expected behavior of the data. This aligns with the Analytics Engineering principle of creating self-documenting pipelines, where transformations are transparent and easier for downstream users to understand.

Additionally, modular models improve lineage visualization in the DAG. Instead of a single model hiding multiple transformation layers, a modular structure reveals how data flows through each intermediate step, helping both debugging and governance. Modularization also enables reusability—other models can reference the intermediate model rather than rebuilding the same logic through duplicated CTEs, supporting DRY (Don't Repeat Yourself) principles.

Therefore, moving CTEs into separate dbt models absolutely provides a documentation benefit and improves the overall engineering quality of the project.

Create a new branch in git and switch to itB. Update the dbt code according to the new logicC. Create a Pull / Merge RequestD. Run some automated CI checks and/or manual review of the updated codeE. Merge the updated code to the main git branch

Version control best practices in dbt follow the same engineering workflow used in modern software development. The first step is always to create a new git branch and switch into it, ensuring all work is isolated from production-ready code and allowing your team to develop safely without affecting others. Once inside the feature branch, you update the dbt code according to the new logic, which may include modifying models, tests, macros, or documentation.

Next, you create a Pull Request (PR), also known as a Merge Request, to propose integrating your changes into the main branch. This is important because dbt projects are collaborative, and PRs facilitate peer review, enforce project standards, and prevent regressions. Once the PR is created, automated CI pipelines—such as running dbt build, schema tests, data quality checks, and code-style checks—are executed. Reviewers may also manually inspect code for logic correctness, naming conventions, and modeling consistency.

After all checks have passed and reviewers approve the PR, the final step is to merge the updated code into the main branch, making the new transformations part of the production dbt project. This workflow ensures governance, reliability, and auditable development practices, all of which are core principles in analytics engineering.

The correct answers are A and C.

dbt clone is a command introduced to efficiently replicate existing relations (tables/views) from one schema/environment to another within the same warehouse without fully rebuilding them. It typically leverages warehouse-level “clone” functionality (e.g., Snowflake zero-copy clone). To know what to clone, dbt needs information about previously built models; this is stored in artifacts like manifest.json. Therefore, A is correct: it requires a reference to a previous manifest/state to know which models and locations to operate on.

C is also correct because cloning a production schema into a development schema enables you to test code changes while pointing downstream tools (like BI dashboards) at the cloned data. That way, BI or ML systems can exercise new dbt logic without impacting real production objects.

Option B describes state:modified / state comparison behavior, but dbt clone does create (or clone) objects, so B is false.

Option D is incorrect because clone works within a warehouse, not across different warehouses.

Option E is wrong: _v# suffixing is for model versioning, not cloning.

Thus, A and C correctly describe the behavior and purpose of dbt clone.

Hook 1

on-run-end: "{{ macro_x() }}"

Answer: macro_1

Hook 2

models:

:

post-hook: "{{ macro_x() }}"

Answer: macro_2

Hook 3

on-run-start: "{{ macro_x() }}"

Answer: macro_3

Hook 4

{{

config(

pre-hook: "{{ macro_x() }}"

)

}}

Answer: macro_4

dbt supports run-level hooks and model-level hooks. Run-level hooks fire once per invocation, while model-level hooks fire around each individual model.

on-run-end is a run-level after hook that executes once after the entire dbt command completes. Because macro_1() must run after every dbt run, it correctly belongs here.

The post-hook configured under the models: section runs after each model in that scope finishes building. This matches the requirement for macro_2() to execute after a model runs.

on-run-start is a run-level before hook and fires once before dbt begins executing any models for that command, making it the right place for macro_3() which must run before every dbt run.

Finally, the pre-hook specified inside a model’s config() block runs before that specific model is built. Since macro_4() must execute before a model runs, it belongs in the pre-hook configuration.

Thus the correct mapping is:

on-run-end → macro_1

model post-hook → macro_2

on-run-start → macro_3

model pre-hook → macro_4.

model_a contains an in-model config explicitly setting:

{{ config(materialized = "view") }}

In dbt, in-model config overrides project-level config, including folder-level defaults. Even though the staging/ folder is configured as:

staging:

+materialized: ephemeral

…this does not apply because the in-file config has higher precedence.

So model_a is materialized as a view.

A view in dbt is not persisted as data; instead, it stores the SQL definition. When a downstream query selects from that view, the database executes the underlying SQL at query time. As a result:

Queries run slower than selecting from a table, because the underlying computation happens each time.

But the data is always up to date, because views read directly from the current underlying tables.

This matches Option C.

Why the other options are wrong

A & D describe table behavior (faster queries, data only as fresh as last run). model_a is not materialized as a table.

B is incorrect because views are fully queryable; no error occurs.

Will always point to the latest version of the source schema

Correct Match: ✔ defer

Allows to use objects built in the target schema with any downstream tool

Correct Match: ✔ dbt clone

3️⃣ Allows to safely modify objects built in the target schema

Correct Match: ✔ defer

4️⃣ Is a point-in-time operation

Correct Match: ✔ dbt clone

defer and dbt clone serve very different purposes in dbt, and understanding their behavior is essential for choosing the right command.

The --defer flag tells dbt to use already-built objects from a previous environment (often production) instead of rebuilding them. Because it always references the existing target schema’s most recent objects, it “always points to the latest version of the source schema.” Since no objects are overwritten when using defer, it also “allows safely modifying objects built in the target schema”—your development environment uses production objects without altering them.

By contrast, dbt clone creates a point-in-time copy of existing relations. This cloned schema is static; it does not auto-update when source data changes. Therefore, clone is classified as a “point-in-time operation.” Since clone copies physical tables/views into a new schema, downstream tools (BI dashboards, ML pipelines) can safely query the cloned environment without affecting production, making “allows to use objects built in the target schema with any downstream tool” the correct match.

Thus, defer is used for logic substitution without copies, while clone is used for replicable, point-in-time snapshots.

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.