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

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

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

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

The remaining options do not create lineage:

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

D uses a Jinja variable unrelated to lineage.

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

Therefore, A and B are the only valid answers.

The goal in this scenario is:

Select only models, tests, and snapshots that were modified in development, using:state:modified

Use already-built production objects whenever possible, so development does not need to rebuild everything. This is done with:--defer

Compare development code against production artifacts, which requires:--state

Run everything (models + tests + snapshots) in a single command. This is exactly what dbt build does.

dbt build = run models + run tests + run snapshots + run seeds.

Putting it all together, the correct command is:

dbt build --select state:modified --defer --state

This single command satisfies all requirements:

It runs only modified resources.

It uses the production state artifacts for comparison.

It defers to production-built models where possible.

It runs all resource types automatically.

Why the other options are incorrect:

A → Missing --state, so state:modified cannot function.

B → Splits run + test separately; question asks which single command you will invoke.

D → Missing --defer, which defeats the purpose of using production objects.

E → Also missing --defer.

Thus, Option C is the only correct answer.

Update int_order_items by replacing:

{{ source('tpch', 'orders') }} → {{ ref('stg_tpch_orders') }}

{{ source('tpch', 'lineitem') }} → {{ ref('stg_tpch_line_items') }}

In dbt’s recommended modeling pattern, sources should be referenced only in the staging layer. Downstream models (intermediate and mart/fact models) should reference staging models via ref(), not the raw source() directly. This keeps all raw-to-clean logic centralized in the staging layer and makes refactoring and documentation easier.

In the original DAG, int_order_items depends directly on tpch.orders and tpch.lineitem via source(), and staging models also depend on those same sources. That creates parallel paths from the sources and breaks the clean layered architecture.

By updating the int_order_items SQL to use:

from {{ ref('stg_tpch_orders') }}

join {{ ref('stg_tpch_line_items') }} ...

instead of:

from {{ source('tpch', 'orders') }}

join {{ source('tpch', 'lineitem') }} ...

you ensure that int_order_items sits entirely downstream of the staging layer. The new DAG becomes linear: sources → staging → intermediate (int_order_items) → any further marts. This improves modularity, reusability of cleaned logic, and makes the DAG easier to reason about and maintain.

The correct answer is A: Add model groups and set access to private.

dbt’s access control system is designed to restrict which models may reference others purely within the dbt project itself, independent of data warehouse permissions. This system uses model groups and an access property, which can be set to public, protected, or private. Setting a model to private means that only models within the same group are allowed to reference it. Any attempts to reference the model from outside the group will cause a compilation error, enforcing strong boundaries between domains or data products within a dbt project.

Option C (protected) is incorrect because protected allows references from other groups but requires explicit configuration—the intention is stewardship, not restriction. It does not fully restrict referencing.

Option B is incorrect because dbt model access control is not tied to warehouse permissions. Warehouse-level grants cannot control dependency references inside the dbt DAG.

Option D is irrelevant to access control. Versioning does not restrict references; it only manages updates to published models.

Therefore, the only correct way to restrict which models can reference another model is by placing it into a model group and marking it as private, which enforces strict internal usage boundaries.

The correct answer is A: The freshness check can be disabled with freshness: null.

In dbt, freshness checks are controlled by the freshness configuration block within a source definition. If a project includes a default freshness configuration, but you want to turn off freshness checking for a specific table, you can explicitly set freshness: null. This overrides inherited settings and tells dbt not to compute or evaluate freshness for that object.

Option B is incorrect because dbt evaluates all configured sources before finishing; it does not exit after the first failure. Instead, it completes the run and reports pass/warn/error statuses according to the configured thresholds.

Option C is incorrect because the placement of freshness checks is flexible. Some teams run dbt source freshness first to validate data arrival before running models; others run it separately or at the end of a workflow. There is no requirement that it always be last.

Option D is incorrect because dbt build does not automatically run freshness checks. Freshness checks are performed only when dbt source freshness is executed explicitly or configured in a dbt Cloud job step.

Therefore, A is the only statement that correctly describes the behavior of source freshness checks.

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

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

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

Thus, the two prerequisites are:

Running dbt source freshness (to create freshness metadata).

Defining a freshness configuration on the relevant sources.

In dbt, singular tests are custom SQL tests that live as standalone .sql files inside the root /tests directory, not inside /tests/generic. A singular test returns rows that indicate failure, and dbt runs the SQL directly as written. Generic tests, on the other hand, live inside the /tests/generic folder and are YAML-based macro-driven tests.

From your test folder structure (shown in the original screenshot), the following SQL files exist:

Inside /tests/generic/

furniture_customers_test.sqlThis file is a generic test, not singular.

Inside the root /tests directory:

macro_stg_tpch_orders_assert_pos_price.sql

macro_stg_tpch_suppliers_assert_pos_acct_bal.sql

stg_tpch_orders_assert_positive_price.sql

These are singular tests, because they are standalone SQL files in the tests root folder.

When you run:

dbt test --select 'test_type:singular'

dbt filters for only tests classified as singular. It ignores generic tests entirely.

Therefore, only the following 3 tests will run:

macro_stg_tpch_orders_assert_pos_price

macro_stg_tpch_suppliers_assert_pos_acct_bal

stg_tpch_orders_assert_positive_price

This matches Option C, making it the correct answer.

The requirement is:

Select all models that have been modified → this uses the state selector:state:modified

But only those modified models that are materialized as views → this uses the config selector:config.materialized:view

Then include upstream and downstream dependencies of those models → this requires adding + around the selectors.

To combine both selectors, dbt uses a comma-separated list within --select, meaning both selectors must match simultaneously.

The correct syntax is:

dbt build --select +state:modified, +config.materialized:view+

This command:

Finds models whose state is modified.

Filters them to only those materialized as views.

Includes upstream (+) and downstream (+) dependencies.

Runs and tests the selected nodes because dbt build includes running models, tests, seeds, and snapshots.

Why the other options are wrong:

A and C use invalid selector syntax (config.materialized:view+ must be prefixed with +).

B only selects modified models but does not filter by materialization type.

D uses materialized:view, which is invalid without the config. prefix.

Thus, only Option E satisfies all conditions and uses correct dbt selector syntax.

The correct answer is D: Declare the external table as a source using the external configuration.

When data arrives in an external storage system such as S3, many warehouses (like Snowflake, BigQuery, and Databricks) support external tables that reference data stored outside the warehouse. dbt fully supports external tables by allowing them to be declared as sources using the external: configuration block inside sources: in a YAML file. This tells dbt that the upstream object exists outside the warehouse and should not be materialized or transformed by dbt directly. It also enables dbt to include external data in lineage graphs, freshness checks, and downstream model dependencies.

Option A is not ideal because you still need to formally register the external table as a source; simply querying it in a model breaks the data lineage structure. Option B is unnecessary and operationally brittle—temporary tables are not required for external data ingestion. Option C is incorrect because dbt seed is intended for uploading local static CSV files, not files arriving via S3 or controlled by external vendors. Seeds do not support dynamic ingestion patterns.

Thus, the correct and documented method is to declare the external table as a source with the external configuration, allowing dbt to consume the data appropriately while maintaining proper governance and lineage.

The --fail-fast flag changes dbt’s execution behavior by immediately stopping the scheduling of any further models as soon as the first failure occurs. This is true regardless of the number of threads; in this case, the environment uses one thread, meaning models run strictly in sequence based on dependency order.

In the DAG provided, model_d is downstream of model_b, and model_f depends on model_d. The execution sequence when using a single thread would be something like:

model_a runs

model_c runs

model_e runs

model_b runs

model_d runs → fails

Once model_d fails:

With normal dbt run, dbt would attempt to continue running any unrelated models (though in this DAG, there are no more independent nodes left anyway).

With --fail-fast, dbt immediately stops scheduling any additional work, halting the run.

Therefore, no further models—including model_f or any other—will run. dbt does not drop models, retry them, or attempt related branches. It simply stops.

The correct answers are B: tags and C: enabled.

dbt tests—both generic and singular—support a limited but clearly defined set of configurations. Two of the supported configurations are tags, which allow grouping and selecting tests using dbt’s selector syntax, and enabled, which can be set to true or false to control whether a test should run. These configurations are commonly used to manage large test suites, such as disabling slow tests in development or tagging tests for CI pipelines.

Option A (on_schema_change) is a model-only configuration and cannot be applied to tests.

Option D (materialized) applies only to models, not tests, since tests compile into queries that evaluate failures rather than physical objects.

Option E (persist_docs) applies to models and sources for documentation purposes. Tests do not support persisted documentation properties beyond what appears in test metadata.

dbt’s documentation makes clear that tests inherit only a small subset of configurations compared to models—primarily enabled, tags, severity, and custom test arguments. Among the options provided, only tags and enabled are valid and supported.

Thus, the correct answers are B and C.

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.

dbt includes built-in support for model versioning and controlled deprecation. When you introduce a new version of a model, dbt will only warn about the old version being removed if the old version explicitly includes a deprecation_date configuration. This parameter signals to dbt that the model is scheduled for removal after a certain date, allowing dbt to produce structured warnings to users and downstream systems. These warnings serve as a formal notice that the old version should no longer be referenced and will eventually be removed.

Option A, simply creating a new version, does not trigger warnings by itself. dbt allows multiple versions to coexist without any deprecation messaging unless you explicitly configure it. Option C (enabled: false) disables the model entirely, which is not a graceful deprecation strategy and does not result in version-removal warnings. Option D (adding “deprecated” in the description) is only informational text and has no functional effect on dbt’s deprecation system.

Thus, only B—setting deprecation_date on the old version—activates dbt’s official deprecation warning mechanism, making it the correct answer.

The correct answer is B: Refer to a manifest and utilize the --defer and --state flags.

According to dbt’s official documentation, the --defer flag enables developers to defer the resolution of model references (ref(), source()) to an existing manifest—commonly the one generated from a production run. When this flag is used along with --state, dbt reads the prior project state and uses the already-built production models instead of rebuilding upstream dependencies. This is essential because production models are typically large and compute-intensive. By deferring to production artifacts, developers can test only the models they have modified, dramatically reducing warehouse costs and speeding up development cycles.

This approach is foundational to dbt’s recommended development workflow, especially when working with CI/CD or large DAGs. It preserves the integrity of the dependency graph while avoiding unnecessary recomputation.

Option A violates dbt best practices by removing dependency awareness. Option C is unnecessary operational overhead and does not integrate with dbt’s state management. Option D is incomplete because --state alone does not prevent upstream model execution—--defer is required to substitute those models with existing artifacts.

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.

Execute the last dbt command from the node point of failure.

Answer: retry

The --retry flag in dbt is specifically designed to re-execute a dbt command starting from the node where execution previously failed. In large DAGs, rebuilding all upstream models repeatedly is inefficient, especially when a downstream transformation is the only point of failure. dbt includes retry logic to support resiliency within orchestrated pipelines and CI/CD processes.

Using --retry allows dbt to leverage the metadata stored in the run_results.json to determine which model triggered the failure. Instead of re-running the entire DAG, dbt intelligently continues execution from the failed node, speeding up recovery and making iterative debugging far more efficient. This is particularly valuable in production pipelines where minimizing runtime is critical.

This behavior aligns with dbt’s philosophy of incremental, test-driven, modular development: failures should be isolated, reproducible, and simple to resume. By re-running only the subset of affected models, dbt improves developer productivity and orchestration reliability.

**Create a copy of an existing database object in a sandbox environment.

Answer: clone

The clone capability in dbt refers to creating a zero-copy clone (Snowflake) or snapshot-like duplicated object using the data platform's native features. This is extremely useful when developers or analysts need a safe sandbox environment to test transformations, experiment, or validate logic without affecting production data.

A clone operation duplicates the table or view metadata instantly without physically copying data, which is both cost-efficient and fast. dbt leverages this through commands such as dbt clone (dbt Cloud) or through adapters that support cloning.

Sandboxes created via cloning allow engineers to develop safely by ensuring that testing and prototyping has no impact on production tables. Because cloned objects share underlying data blocks, they are nearly storage-free unless mutated—keeping warehouse costs low.

This practice is aligned with modern analytics engineering best practices where separation of environments (dev/test/prod) is essential for governance, data quality, and reproducibility.

**Run a subset of models or tests in a sandbox environment without having to first build their upstream parents.

Answer: defer

The --defer flag allows dbt to reference already-built objects from another environment—commonly production—so that developers can run only the models they are modifying, without recreating all upstream dependencies.

When combined with --state, dbt compares the working branch’s DAG with previously generated artifacts and determines which nodes should be rebuilt. Any upstream nodes not modified in the current branch are deferred, meaning dbt will point to the existing production-built version instead of materializing them again.

This dramatically speeds up development because staging layers or intermediate models, which may take significant computation time, do not need to be rebuilt for every developer iteration.

The mechanism also prevents accidental overwrites of production objects because deferred references always point to a safe, isolated schema established by state comparison.

This concept is central to dbt’s “safe development via deferral,” enabling rapid experimentation while ensuring consistency between dev and prod environments.

**Compare nodes against a previous version of the same nodes.

Answer: state

The --state flag allows dbt to compare the current project against a previously generated manifest. This enables dbt to determine which models have changed, which tests must be re-run, and how the DAG differs between two versions.

State comparison is foundational to features such as Slim CI, deferred builds, and change-aware testing. dbt reads the state directory—typically containing artifacts from a production run—and examines differences in SQL, configurations, macros, or schema definitions.

This allows dbt to selectively build only modified nodes, increasing efficiency in CI/CD pipelines and reducing unnecessary warehouse costs. Additionally, state comparison is used for validating backward compatibility, testing versioned models, or enforcing governance rules such as model contracts.

By comparing nodes to their historical equivalents, teams can adopt modern engineering strategies such as impact analysis, regression detection, and selective deployment. This capability aligns with dbt’s focus on modular analytics engineering and automated change management.

The correct answers are B: All the code changes along the lifecycle of a project are tracked, and E: Code can be reverted to a previous state.

Git is a distributed version control system designed to maintain a complete, chronological history of all code changes. Every commit records who made the change, when it occurred, and what the modification included. This ensures transparency, reproducibility, and accountability across the development lifecycle, which makes B correct. Git also allows users to revert code to any previous commit, branch, or tag, making E correct as well. This capability is critical for recovering from mistakes, undoing faulty deployments, and ensuring stable releases.

Option A is incorrect because Git does not create file versions with suffixes; instead, it stores changes as snapshots within a repository. File suffixing is not part of Git’s functionality.

Option C is incorrect because Git does not automatically send email notifications. Notification mechanisms come from hosting platforms like GitHub, GitLab, or Bitbucket—not from Git itself.

Option D is incorrect because Git does not prevent committing sensitive information. Developers must manually ensure secrets are excluded via .gitignore, secret managers, or pre-commit hooks. Git will store whatever is committed unless prevented through tooling.

Thus, only B and E correctly describe how Git supports version control in analytics engineering and dbt workflows.

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.

This error occurs because the YAML structure is incorrectly indented, causing dbt’s parser (and YAML itself) to misinterpret the test definitions. In dbt, generic tests must be declared as a list under the tests: key, but YAML is extremely sensitive to indentation levels. In the faulty YAML, unique and not_null are indented incorrectly relative to the tests: key, which produces the error: “mapping values are not allowed in this context.”

According to the dbt Testing documentation, valid generic test syntax follows this exact pattern:

columns:

- name: id

tests:

- unique

- not_null

The indentation under tests: must be consistent and aligned so that YAML interprets the items as list elements, not as malformed mappings. When indentation is wrong, YAML attempts to parse list entries as key-value mappings, which leads to the error seen during compilation.

dbt does not require generic test names to be quoted, nor does it expect tests to be a dictionary. The test list format is correct—only the indentation is wrong. Therefore, the root cause is incorrect YAML indentation, making Option D correct.