dbt Analytics Engineering Certification Course

1. Exam Overview

What the exam is testing

The dbt Analytics Engineering Certification validates whether you can use dbt in a production analytics workflow, not just whether you can remember commands. The exam expects you to reason through realistic project situations such as:

• building a clean model DAG from raw sources to marts;
• choosing the right materialization for performance and maintainability;
• using ref() and source() correctly instead of hard-coded object names;
• testing assumptions about source data and transformed models;
• debugging model, YAML, SQL, dependency, and pipeline failures;
• applying model governance features such as access, groups, versions, contracts, and grants;
• using state-aware workflows for CI, slim CI, retries, and production-safe deployments;
• managing packages, source freshness, exposures, and documentation so downstream users trust the data.

The real exam is scenario-heavy. A typical question gives you a project problem, then asks for the dbt-native fix. The best answer is usually the option that improves lineage, repeatability, maintainability, and production safety without over-engineering.

Current official exam structure to know

The official dbt Analytics Engineering Certification page currently lists these logistics and domains:

Older official guides and older question banks often mention dbt Core 1.7 and include a separate documentation domain. The current public exam page lists 7 domains and no separate documentation domain. Documentation still matters because it appears across sources, model properties, lineage, exposures, and governance scenarios.

How to think like the exam

Think like a production analytics engineer:

1. Use dbt abstractions before warehouse-specific shortcuts. Prefer ref(), source(), model configs, selectors, tests, contracts, and exposures over manual warehouse object names.
2. Preserve the DAG. Anything that hides lineage, bypasses dependencies, or relies on manually ordered SQL is suspicious.
3. Choose the simplest materialization that satisfies usage. Do not make everything incremental or table. Do not make a dashboard-facing mart ephemeral.
4. Test assumptions, not implementation trivia. Use tests where they express business rules or data quality guarantees.
5. Debug from dbt outward. Check logs, compiled SQL, YAML validity, dependencies, target/profile config, and then warehouse-specific SQL/errors.
6. Separate development from production. Use state, defer, clone, CI jobs, and PR review to avoid rebuilding or querying expensive production tables unnecessarily.
7. Govern public interfaces. If other teams depend on a model, use model access, versioning, contracts, docs, exposures, and deprecation instead of silently changing schemas.

How to use this course

Read Sections 1–3 once to orient yourself. Then study each domain in Section 4 and use Sections 5–10 as quick revision material. The course intentionally merges repeated CSV themes into decision frameworks so you can answer new scenarios rather than memorize answers.

2. Exam Domains

Current domain list

Priority notes

The largest share of the analyzed bank is model development and optimization. This makes sense because almost every other topic depends on a correct mental model of dbt resources, DAG lineage, materializations, and configuration precedence.

High-yield cross-domain concepts:

• ref() vs source();
• model materializations: view, table, incremental, ephemeral;
• tests: generic vs singular vs custom generic;
• source freshness and source testing;
• compiled SQL for debugging;
• YAML indentation and resource properties;
• dbt build vs dbt run + dbt test;
• model contracts, versions, access, and groups;
• state selection, defer, and CI efficiency;
• packages and macro compatibility.

What matters most

3. Start-to-Finish Study Path

Foundation phase: build the dbt mental model

Learn first:

• What a dbt project is: dbt_project.yml, models, macros, seeds, snapshots, tests, sources, packages.
• How dbt builds a DAG from ref() and source().
• Difference between development, CI, staging, and production environments.
• Basic commands: dbt debug, dbt compile, dbt run, dbt test, dbt build, dbt docs generate, dbt deps, dbt seed, dbt snapshot, dbt source freshness.

Hands-on checklist:

• Create a source YAML file with at least one source and table.
• Create staging models using source().
• Create intermediate/mart models using ref().
• Run dbt compile and inspect target/compiled.
• Generate docs and inspect lineage.

Intermediate phase: learn production patterns

Focus on:

• materializations and their tradeoffs;
• incremental models and is_incremental();
• test types and test configuration;
• model property YAML;
• packages and macros;
• git workflow and PR review;
• docs and exposures.

Hands-on checklist:

• Build one view, one table, one incremental model, one ephemeral model.
• Add generic tests: not_null, unique, relationships, accepted_values.
• Add a singular test for a business rule.
• Add source freshness to a source.
• Add an exposure for a dashboard.
• Install a package and run dbt deps.

Advanced phase: governance, state, and debugging

Focus on:

• model contracts and column-level constraints;
• model versions and deprecation;
• access levels and groups;
• grants for warehouse permissions;
• slim CI using state:modified+ and --defer;
• result selectors and retries;
• debugging YAML, SQL, package, and pipeline failures.

Hands-on checklist:

• Add a contract to a model and intentionally break it.
• Add a v2 model and deprecate v1.
• Make a protected/public model and test dependency behavior.
• Run state selection against a previous manifest.
• Debug a failing test from the failure output and compiled SQL.

Final review phase

In the final review, do not reread everything equally. Focus on scenario triggers:

• If the model is downstream-facing, think governance.
• If the model is expensive and append-only, think incremental.
• If dependencies are invisible, think ref()/source().
• If only changed work should run, think state/defer.
• If source data timeliness is the issue, think freshness.
• If a dashboard breaks, think exposure, model contract/versioning, docs, and lineage.
• If the error is unclear, inspect logs and compiled SQL before changing dbt configs.

4. Core Concepts by Domain

Domain 1 — Developing and Optimizing dbt Models

Concepts

This is the highest-yield domain. You must know how dbt turns modular SQL files into a dependency graph and production data objects.

Key resource types:

ref() and source()

ref() is for dbt models. source() is for raw objects loaded outside dbt.

Exam trap: If the question says models build in the wrong order, do not choose a scheduler workaround. dbt order comes from ref() dependencies.

Materializations

Incremental models

Use incremental when a model has many rows and only a small subset is added or changed each run.

Core reasoning:

• is_incremental() gates logic that should only run on incremental runs.
• The SQL must be valid for both full-refresh and incremental runs.
• Use a reliable event/update timestamp or high-water mark.
• Use unique_key and an incremental strategy when records can update.
• Use --full-refresh when logic changes require rebuilding historical rows.
• Schema changes may require on_schema_change handling or full refresh depending on the warehouse and change type.

Common bad answers:

• “Incremental models are always rebuilt.” False.
• “Incremental models are always best for large tables.” Not if most rows change each run.
• “You never need is_incremental().” Usually false for selective processing.
• “Use ephemeral to make a large dashboard model faster.” Usually wrong; ephemeral can duplicate heavy SQL.

Sources

A source maps to a raw data location, commonly database + schema, with tables underneath. Use sources to centralize raw object naming and document external dependencies.

Good source YAML includes:

• source name;
• database/schema where needed;
• tables;
• source and column descriptions;
• tests on raw data assumptions;
• freshness where timeliness matters;
• loaded timestamp field for freshness checks.

Exam trap: If multiple raw tables are in the same database/schema, they are usually one source with multiple tables, not multiple sources.

Modularity and DRY SQL

Good dbt modeling decomposes SQL into layers:

Use macros for reusable logic patterns, not for hiding business-critical model lineage. Use models when you need DAG visibility and testable transformation steps.

Jinja, variables, and environment config

Python models

Python models are used for transformations easier in Python than SQL, such as advanced data science-style transformations. Exam reasoning remains dbt-native:

• They are still models in the DAG.
• They can use dbt.ref() and dbt.source().
• They are not a replacement for simple SQL transformations.
• Support depends on the adapter/platform.

Git workflow

Expected git skills:

• create feature branches;
• commit changes;
• pull from main/head branch to stay updated;
• resolve conflicts;
• open pull requests;
• use CI before merging.

Exam trap: If the question says your branch is behind main, the correct general action is to pull/reconcile with the head branch, not manually copy files or merge straight into production.

Patterns

• Raw table reference → define source + use source().
• Model-to-model dependency → use ref().
• Repeated business logic → refactor into staging/intermediate models or macros.
• Expensive dashboard model → table or incremental.
• Append-only high-volume data → incremental.
• Static mapping table → seed.
• Source overwrites values but history needed → snapshot.
• Direct warehouse object permissions required → grants.

Traps

• Choosing a materialization only because it is “faster” without considering freshness, cost, and query pattern.
• Using hard-coded schema names in dbt models.
• Making every model a table, which increases rebuild time/storage.
• Making every staging model ephemeral, which can duplicate heavy SQL downstream.
• Treating seeds as ingestion for operational data.
• Using macros where a model would provide better lineage and testing.
• Forgetting that a table model fully rebuilds by default.