The dbt Analytics Engineering Certification Exam (dbt-Analytics-Engineering)

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 true root cause is not related to run hooks or regular expressions. The warning clearly indicates that dbt found a configuration path that does not match any actual model path inside the project. In this case, the config block uses the key models.jaffle-shop, which is incorrect because dbt model paths must match the folder structure and cannot contain hyphens unless the folder itself contains a hyphen. Since the project folder is named jaffle_shop (with an underscore), dbt cannot map the configuration to any model.

dbt evaluates configuration paths based on directory names under the models/ folder. A mismatch between the folder name and the configuration key causes dbt to ignore the configuration entirely. This results in the warning:

“Configuration paths exist in your dbt_project.yml file which do not apply to any resources.”

This warning is specifically triggered when dbt identifies unused configuration paths due to typos, incorrect nesting, or invalid identifiers. dbt does not interpret hyphens (-) as valid Python identifiers for resource names, so a config path like models.jaffle-shop will never be applied.

Therefore, the assertion that the cause is a " run hook with an incorrect regular expression " is incorrect . The actual root cause is that the configuration path uses the wrong name (jaffle-shop instead of jaffle_shop).

Here is the correct sequence:

Correct Order

sources:

- name: blue (source definition)

tables:

- name: yellow (table definition)

columns:

- name: red (column definition + tests)

In dbt, source documentation follows a strict YAML hierarchy. At the top level, the sources: key declares that you are defining source metadata. Inside this block, each source is listed as an item beginning with - name:. Therefore, the snippet describing the source ( blue ) must come immediately after sources:.

Next, dbt requires a tables: block inside each source to define the raw tables belonging to that source. Thus, the snippet containing tables: must follow the source definition. The table description ( yellow ) is then placed directly under this key because it represents a table within that source.

Finally, dbt allows column-level metadata under a columns: block inside a table definition. Therefore, columns: appears next, followed by the snippet defining a specific column ( red ) which includes both a description and tests (unique, not_null).

Arranging the YAML in this hierarchical order ensures dbt can correctly assign documentation to the source object, the table object, and the individual column. Misordering these snippets would break the structure and prevent dbt from generating documentation properly.

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.

Create a new branch in git and switch to it B. Update the dbt code according to the new logic C. Create a Pull / Merge Request D. Run some automated CI checks and/or manual review of the updated code E. 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.

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.

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

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

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

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

The correct answer is A: dbt test --select " orders " --indirect-selection=empty " .

In dbt, the --indirect-selection flag controls how dbt handles indirectly related resources during selection, such as tests whose parent models may or may not be selected. By default, dbt may include related resources depending on the selection behavior.

indirect-selection=empty is the strictest form of selection. It means that dbt will not run tests whose parent models are not explicitly selected , even if the tests are indirectly related. This prevents executing tests on models that you did not intend to build or include in your workflow, ensuring test execution is tightly scoped.

Other options behave differently:

Option B (no indirect-selection flag) uses dbt’s default behavior, which does include related tests, meaning tests could run even when their parent models were not selected.

Option C: buildable includes resources that can be built (e.g., when downstream dependencies require them).

Option D: cautious runs tests if their parents are selected transitively through dependencies.

Therefore, to prevent tests from running when parent models are unselected, you must use --indirect-selection=empty , making A the correct choice.

The --fail-fast flag tells dbt to stop scheduling any new nodes as soon as one node fails . Importantly, dbt does not kill models that are already running; in-flight nodes are allowed to finish.

Here’s what happens step by step with 2 threads:

Roots model_a and model_b start first.

model_a finishes successfully. That makes model_c eligible to run.

dbt now runs model_b and model_c in parallel.

While they are running, model_b fails.

Because --fail-fast is set, dbt immediately stops scheduling any additional models (like model_d, model_e, or model_f).

model_c was already running when model_b failed, so it is allowed to complete successfully.

Downstream models of either branch (model_d, model_e, and model_f) never start , because fail-fast prevents any further nodes from being queued after the first failure.

So, the only models that successfully build during this run are:

model_a (completed before model_b failed)

model_c (already running at the time of failure and allowed to finish)

Hence the correct choice is B: model_a, model_c .