This page stays focused on that single task: helping candidates answer dbt Analytics Engineering practice questions with a clean mental model instead of trying to memorize disconnected facts. The official exam page is the anchor for every study session, and the best way to use practice content is to compare each scenario against the exam's current structure, supported version, question count, and passing score. Start with the exam hub here: dbt Analytics Engineering, then return to it whenever a question feels vague or when an answer choice tries to hide a hard-coded shortcut.
Official exam facts
| Detail | Current info |
|---|---|
| Exam name | dbt Analytics Engineering |
| Vendor | dbt |
| Exam slug | dbt-dbt-analytics-engineering |
| Questions | 65 |
| Duration | 2 hrs |
| Passing score | 65% |
| Supported version | 1.11 |
| Study entry point | dbt Analytics Engineering |
| Official source | dbt Analytics Engineering Certification Exam |
| Official certification page | dbt Certification |
| Cert-Pass price starting point | EUR 29 |
| Full access price starting point | EUR 39 |
| Article focus | exam-style practice, answer logic, and scenario recognition |
| Last verified | 2026-06-01 |
The exam page is the best place to confirm the current wording of the certification, and the official page should be the final authority when a detail changes. This article uses that page as the source of truth and then translates the exam into the kind of thinking that shows up in practice questions.
What this page is trying to solve
The strongest dbt practice questions do not ask candidates to recite syntax in isolation. They ask what to do when a model breaks, when a dependency is missing, when a source is stale, when a team wants a public interface, or when a pipeline needs to be cheaper in CI. That means the best answer is usually the one that protects the DAG, keeps the project maintainable, and uses dbt features in the correct layer.
This page is intentionally narrow. It is not a broad study guide, a career guide, or a general dbt overview. It stays on one job: helping the reader answer dbt Analytics Engineering practice questions with better judgment. That narrow focus matters because many candidates lose points not from lack of knowledge, but from choosing an answer that is technically plausible yet wrong for the scenario.
If you want the broader prep route after this page, compare it with the main study guide here: dbt Analytics Engineering Certification Study Guide 2026. If you want a different style of reinforcement, review dbt Analytics Engineering Exam Tips 2026 and then come back to this page for question logic.
How to use practice questions the right way
A lot of candidates use practice questions passively. They read the prompt, pick an answer, and move on. That produces a false sense of progress because it rewards recognition instead of reasoning. The better method is more deliberate.
Use this three step loop for every question:
- Identify the layer being tested.
- Match the layer to the dbt feature or command that belongs there.
- Eliminate every answer that solves the wrong problem.
That loop sounds simple, but it is the core skill behind most dbt scenarios. For example, if the prompt is about a raw warehouse table, the layer is source management. If the prompt is about a downstream dashboard, the layer is exposure and governance. If the prompt is about only rebuilding changed models in pull request validation, the layer is state and defer. If the prompt is about a business rule on rows, the layer is testing.
The key is to move from nouns to functions. Do not ask only what objects are mentioned. Ask what those objects are doing in the project. A table can be raw data, a transformed model, or a downstream asset. The exam cares about the role, not the label alone.
High-yield domain priorities
| Priority | Domain | What the questions usually test | Common distractor |
|---|---|---|---|
| 1 | Developing dbt models | ref(), source(), model layers, materializations, DAG order, modular SQL |
Hard-coded relation names or a scheduler workaround |
| 2 | Implementing dbt tests | generic tests, singular tests, custom tests, test config, failure handling | Using a freshness check as a data-quality test |
| 3 | Debugging data modeling errors | compiled SQL, YAML structure, logs, Jinja issues, profile config | Editing warehouse SQL directly without tracing the dbt cause |
| 4 | Managing dbt models governance | contracts, versions, access, groups, grants, deprecation | Treating a model change as safe just because the SQL still runs |
| 5 | Managing data pipelines | run order, job design, CI, orchestration, retries, fail fast behavior | Rebuilding everything every time |
| 6 | Leveraging dbt state | state:modified, defer, slim CI, artifact based selection |
Assuming state is the same thing as source freshness |
| 7 | External dependencies | packages, dbt deps, exposures, source freshness, downstream awareness |
Treating dependencies as optional documentation only |
This table is a good first filter before the reader starts a practice block. If a question feels like it lives in the top half of the table, it probably belongs to model design or testing. If it feels like a release or production question, governance and state usually matter more than raw SQL detail.
A clean answer framework for scenario questions
The best dbt answers often sound boring because they are the least risky and most dbt native. That is useful. The exam is usually not asking for a clever trick. It is asking for the feature that fits the problem cleanly.
Use this framework when reading choices:
| If the scenario mentions | Think about | Usually correct direction |
|---|---|---|
| Raw warehouse tables | Sources | Declare the source and use source() |
| One model depending on another | Lineage | Use ref() |
| A large table that grows over time | Incremental logic | Filter new rows safely and keep the unique key strategy consistent |
| A small static lookup file | Seeds | Version controlled reference data |
| A change history requirement | Snapshots | Track record changes over time |
| A dashboard or notebook depending on data | Exposure | Document the downstream asset and owner |
| Public schema stability | Contracts and versions | Protect consumers before changing the shape |
| CI that should avoid rebuilding everything | State and defer | Select only changed nodes and trust the known graph where appropriate |
| A stale or late source feed | Freshness | Check arrival time, not column nullness |
| A failure that looks like SQL but might be config | Compile and logs | Inspect compiled SQL before guessing |
This matrix is a useful asset on its own because it forces the reader to match the language of the question to the layer of the project. The exam usually gives enough clues to identify that layer if the reader slows down long enough to look for them.
Scenario pattern 1: model dependency order
A common practice question describes models building in the wrong order, or a downstream model referencing an upstream model that has not yet been created. The wrong answer choices often offer a schedule change, a warehouse order tweak, or a manual job dependency. Those choices are attractive because they sound operational. They are still wrong.
The dbt answer is usually about lineage, not orchestration. If model A depends on model B, the SQL should use ref() so dbt can build the DAG. That gives dbt enough information to order execution, compile relation names for the target environment, and keep the project portable across dev, CI, and production.
What the reader should look for:
- a model that names another model directly;
- a downstream object that depends on an upstream transformation;
- a question that asks how to make order automatic or safe;
- an answer choice that mentions
ref().
Why distractors are wrong:
- manually ordering jobs does not encode lineage in the project;
- hard-coding a production schema breaks environment portability;
- using a warehouse-specific shortcut may work once but does not keep the DAG visible;
- changing the scheduler does not fix the model relationship inside dbt.
If the prompt mentions a raw table rather than another model, the answer changes to source(). That difference is one of the most tested distinctions in the whole exam. Candidates who mix up ref() and source() tend to lose easy points.
Scenario pattern 2: raw tables and source definitions
Another frequent pattern asks what to do when a model reads directly from a raw warehouse object. The phrase may appear as a schema name, a feed name, or a loaded table from an external system. The trap is that the direct relation may look harmless. It is not. A raw dependency should normally be declared as a source.
The correct answer is to define the raw object in source YAML and then access it with source(). That gives the project lineage, documentation, and a place to attach freshness checks and column tests. It also keeps the raw dependency in one obvious place instead of hiding it inside model SQL.
The question is often trying to see whether the candidate knows the difference between a raw data object and a dbt model. Raw data belongs in sources. Transformed dbt-managed relations belong in ref() chains.
Practical signals:
- the data came from an ingestion tool or external system;
- the prompt says the table is loaded before dbt runs;
- the issue involves missing documentation or freshness checks;
- the answer choice that adds a source YAML file is usually best.
A strong practice habit is to read raw data scenarios as governance scenarios, not just SQL scenarios. Once a table becomes a source, it can be tested and monitored in a way that makes the whole project more reliable.
Scenario pattern 3: choosing view, table, incremental, or ephemeral
Materialization questions are common because they test the candidate's ability to match cost, freshness, and usage patterns. The exam rarely wants a generic answer like “table is better.” It wants the materialization that fits the usage pattern.
| Materialization | Best use | Watch out for |
|---|---|---|
| View | Light logic, fresh query time evaluation, lower storage need | Can be slow when many downstream users query it often |
| Table | Expensive transformation, frequent downstream reads, stable output | Rebuild cost can be high if the logic changes often |
| Incremental | Large datasets with small new or changed subsets | Needs careful filtering and unique key logic |
| Ephemeral | Small reusable transformation that should stay inside downstream SQL | Can bloat compiled SQL if overused |
The exam usually hides the right choice behind the use pattern:
- If many users query the result often, performance matters and table or incremental tends to be better than view.
- If only a thin reusable logic layer is needed, ephemeral can be fine.
- If the dataset is huge and append like, incremental is often the answer.
- If the model is tiny and must stay live, a view may fit.
What is not safe is making everything incremental. Incremental models are powerful, but they are not a universal default. If the model changes heavily on every run, or if the logic cannot isolate new and changed rows safely, another materialization may be cleaner.
When practicing, ask one extra question: what is the business behavior of the data? That often points to the correct materialization faster than looking at size alone.
Scenario pattern 4: snapshot versus incremental
Candidates often confuse incremental models with snapshots because both can involve change over time. They are not the same thing. Incremental is mainly about processing efficiency and stored transformation output. Snapshot is about tracking historical changes in mutable source data.
If the question says the source overwrites a customer status, account type, or similar attribute and the business wants history, snapshot is the strong signal. That means the exam is asking for historical record preservation, not just fast loading.
Useful distinction:
- Incremental answers the question, “How do we process new or changed rows efficiently?”
- Snapshot answers the question, “How do we preserve history when source values change?”
The trap is to pick incremental just because the source changes. Many systems change often. That does not mean the goal is efficient appending. Sometimes the goal is to know what the value was last month, last quarter, or before a business event.
A good practice question will include wording like changed values, previous version, point in time, history, or slowly changing attributes. When that happens, snapshot should move up the candidate's list quickly.
Scenario pattern 5: testing assumptions instead of guessing them
Testing questions are often easy to overcomplicate. The simplest answer is usually the best one when the scenario is about a clear column rule.
| Need | Best fit |
|---|---|
| Value should never be null | not_null |
| Key should not repeat | unique |
| Child value must exist in parent | relationships |
| Status or category should stay in a defined list | accepted_values |
| A one off business rule needs custom SQL | singular test |
| A reusable business rule should apply in many places | custom generic test |
| Only recent rows should be checked | test where config |
| Failed rows should be saved for review | store_failures |
The most common wrong answer is to use freshness when the scenario is about row quality, or to use row tests when the scenario is about source arrival time. Freshness belongs to timeliness. Tests belong to data rules.
Example thinking:
- If the prompt says a source file is arriving late, use freshness.
- If the prompt says a status column has invalid categories, use accepted values.
- If the prompt says a foreign key should link to a parent model, use relationships.
- If the prompt says an amount should never be negative after a business rule, a singular or custom generic test may fit.
Good practice questions also ask about severity. In that case, the candidate should read whether the problem should warn or fail. The exam likes to test whether the candidate can prioritize a soft signal versus a hard stop in production.
Scenario pattern 6: YAML and compiled SQL debugging
When a dbt model fails, the answer is not always in the warehouse. Many questions test whether the candidate knows where to look first. YAML issues, Jinja issues, config issues, and package issues can all create a failure before the warehouse ever finishes the query.
The strongest sequence is:
- inspect logs;
- inspect compiled SQL;
- check YAML structure and resource properties;
- check the model SQL and any macros;
- then inspect warehouse specific error details.
The trap is to jump straight to the database and edit a table or query manually. That may patch the symptom, but it does not fix the dbt project. The exam cares about the project structure.
A practice question may mention:
- bad indentation in YAML;
- a missing closing Jinja brace;
- a source or model reference that does not compile;
- a macro generating unexpected SQL;
- a package update that changed behavior.
In those cases, compiled SQL is often the fastest truth source. It shows what dbt actually sent to the warehouse. That is much more useful than guessing from the source file alone.
A strong candidate thinks in layers. Source SQL, macro logic, dbt compilation, and warehouse execution are not the same thing. The right answer is the one that fixes the layer where the failure truly exists.
Scenario pattern 7: governance, access, contracts, and versions
Governance questions matter because dbt is not just a transformation tool. It is also a way to manage stable data interfaces. That means some questions are really about how to protect downstream consumers when a model changes.
The clue words are usually public, shared, downstream, team owned, breaking change, deprecate, version, contract, or access.
| Situation | Strong governance idea |
|---|---|
| Other teams rely on a model | Document ownership, add exposure, consider access settings |
| Column names or shapes may change | Version the model and deprecate the old one carefully |
| Public interface must stay stable | Use a contract where appropriate |
| Permission boundaries matter | Apply grants and model access correctly |
| A model belongs to a domain team | Use groups and ownership metadata |
The wrong answer is usually to change the model in place and hope nobody notices. That is operationally risky and is exactly the kind of bad behavior governance features exist to prevent.
Practice questions in this area often blend three ideas together: who owns the model, who can reference it, and what the downstream consumer expects. A strong answer keeps the interface stable until consumers are ready for change.
Scenario pattern 8: state, defer, and slim CI
State based questions are some of the most practical ones on the exam. They are about using previous artifacts to make CI smarter.
The main idea is simple: if only one model changed, there is no reason to rebuild the entire graph from scratch in every validation job. dbt state artifacts let the project compare the current branch with a previous known state and select only the impacted resources.
Useful patterns:
state:modifiedselects changed resources.state:modified+can include downstream children.--deferlets unchanged references resolve to a trusted prior state when appropriate.
The question usually tries to see whether the candidate knows that state and freshness are different concepts. State is about comparing project artifacts. Freshness is about source arrival timing.
Good answers use state to:
- reduce unnecessary build cost;
- keep CI fast;
- test impacted models only;
- trust unchanged upstream dependencies when the workflow allows it.
Bad answers rebuild everything or ignore existing artifacts. That wastes time and money. It also ignores one of the main reasons dbt is useful in real teams.
Scenario pattern 9: packages and external dependencies
Another practice cluster focuses on packages and outside dependencies. The key question is whether the project should install a reusable dependency, pin its version, or diagnose a mismatch.
The phrase dbt deps matters here because it installs package dependencies. But that command alone is not a magic fix. The candidate should still think about versioning, adapter compatibility, and whether the package actually solves the underlying problem.
What to watch for:
- a macro is missing from a package;
- a package works locally but not in CI;
- an adapter specific behavior changes between platforms;
- a package version is not pinned and the build shifts unexpectedly;
- documentation or exposure metadata is missing for a downstream dependency.
Good practice answers are careful rather than enthusiastic. They verify the package version, review the changelog, and test the behavior in the target environment.
The test writer is often looking for whether the candidate understands that external dependencies need governance too. They are not just code copies. They are project assets with their own compatibility and maintenance risk.
Scenario pattern 10: exposures and downstream consumers
Exposures tend to appear in questions about dashboards, notebooks, and business users. They are there to show that downstream assets are part of the data ecosystem.
If the prompt mentions a dashboard that depends on a model, exposure is usually the right concept. The exposure does not execute the dashboard and does not grant permissions. It documents the dependency and ownership so people can see the impact of upstream changes.
This matters because many candidates mistake exposure for a runtime control. It is not that. It is lineage and documentation for a downstream asset.
Strong clues include:
- a BI dashboard depending on one or more models;
- a business owner needing visibility into data dependencies;
- a request to show impact when a model changes;
- a need to keep the data graph honest beyond the warehouse tables themselves.
Exposures are especially useful when combined with docs and governance. The more critical a model becomes to business reporting, the more it needs a visible owner and a clear dependency path.
Scenario pattern 11: documentation questions that are really governance questions
The current exam structure does not separate documentation into its own domain, but documentation keeps showing up in practical scenarios. That is because docs are part of trust.
A question may ask about column descriptions, source descriptions, docs generation, or why downstream users cannot understand a model. The obvious answer is to add the documentation artifact that fits the resource.
What to remember:
- descriptions should explain what a model or column means;
- sources should be documented so raw dependencies are visible;
- docs generation helps publish the project graph;
- docs do not replace tests or contracts;
- docs are part of the answer when visibility is the problem.
The best practice questions on this topic tend to reward answers that connect documentation to actual project behavior. Documentation does not make data correct, but it makes the project understandable, which is a serious production feature.
Scenario pattern 12: when dbt build is the better answer
Some questions compare dbt run, dbt test, and dbt build. The simple logic is that dbt run builds models, dbt test runs tests, and dbt build handles build plus tests in dependency order.
If the question asks for a more complete project execution that respects model dependencies and validates the result, dbt build is often the clean choice. It is especially strong when the scenario wants both resources and tests handled together.
The exam may try to distract the candidate by splitting build and test into separate steps when the scenario really wants one unified command. A well tuned candidate reads the operational need and chooses the command that best matches that need.
This also matters in CI and in controlled release workflows. The project should not rely on random manual ordering when a command exists that already understands the DAG.
How to eliminate wrong answers faster
Many dbt practice questions become easier when the candidate eliminates answers that solve the wrong layer.
| Wrong answer pattern | Why it is wrong |
|---|---|
| Hard coding warehouse names in model SQL | Breaks portability and lineage |
| Using a scheduler to fix model dependency issues | dbt should encode dependencies with refs |
| Using freshness for invalid row values | Freshness checks recency, not content correctness |
| Using a test for a history problem | Snapshots handle history better |
| Using ephemeral for a heavy user facing model | Can create large repeated SQL and poor performance |
| Rebuilding everything in CI | Slower than needed and ignores state selection |
| Changing a public model in place | Risks downstream consumers |
| Treating docs as a substitute for tests | Documentation explains, tests validate |
| Treating contracts as a substitute for change management | Contracts help, but versions and deprecation still matter |
| Relying on package output without checking version compatibility | Dependency drift can break builds |
This elimination method saves time because many distractors are not fully wrong in isolation. They are wrong for the scenario. The candidate should resist any answer that sounds like a generic best practice if the question is clearly asking for a specific dbt feature.
A 7 day practice plan for this exam
If the reader wants a structured way to use this page, the following short plan works well.
| Day | Focus | What to do |
|---|---|---|
| 1 | Model graph basics | Review ref(), source(), and the role of sources versus models |
| 2 | Materializations | Compare view, table, incremental, ephemeral, seeds, and snapshots |
| 3 | Testing | Practice generic tests, singular tests, freshness, and test configs |
| 4 | Debugging | Work through YAML, compiled SQL, logs, and package issues |
| 5 | Governance | Study access, contracts, versions, deprecation, and groups |
| 6 | State and CI | Review state:modified, defer, and changed only pipelines |
| 7 | Mixed scenarios | Do mixed practice questions and explain why each wrong answer fails |
This is a useful asset because it shows that practice is not just repetition. It is sequencing. The exam rewards candidates who understand the project as a system.
Readiness checklist
A candidate is probably ready for dbt Analytics Engineering practice questions when the following feel automatic:
- choose
ref()for model to model dependencies; - choose
source()for raw warehouse inputs; - choose
snapshotwhen the question is really about history; - choose
incrementalwhen the question is about efficient growth; - choose the right test type for a row rule;
- choose freshness when the issue is about late source arrival;
- choose compiled SQL when debugging a compilation problem;
- choose versions and deprecation when a public model changes;
- choose state and defer when CI should be narrow but safe;
- choose exposure when a downstream dashboard is part of the story.
If those choices are still fuzzy, return to the scenario patterns above and work them one by one. dbt questions become much easier once the candidate stops seeing each prompt as a syntax quiz and starts seeing it as a design decision.
Related reading and next steps
For the broader study route, compare this page with the main guide: dbt Analytics Engineering Certification Study Guide 2026.
For a more tactical review of common exam behavior, read: dbt Analytics Engineering Exam Tips 2026.
For a career and outcome angle, see: dbt Analytics Engineering Certification Worth It 2026.
For a topic that often trips candidates up, compare this page with: dbt Analytics Engineering vs Databricks Data Engineer Certification.
If the reader wants to move back to the source of truth at any point, use the exam hub: dbt Analytics Engineering.
FAQ
Are these practice questions meant to match the live exam exactly?
No. They are exam style questions aligned to the current dbt Analytics Engineering blueprint and the kinds of decisions the exam expects candidates to make.
What is the main skill this page is training?
The main skill is scenario recognition. The reader should learn to identify whether the problem is about sources, models, tests, governance, state, dependencies, or downstream consumers.
Why do some questions feel more like architecture questions than SQL questions?
Because dbt is a project system, not just a query runner. The exam often checks whether the candidate understands how data models fit together in production.
What should the reader do when two answers both sound plausible?
Choose the one that fits the dbt layer described in the prompt and eliminate the option that solves the wrong problem, even if it sounds impressive.
How should a candidate study after finishing this page?
Return to the study guide, review the exam page, then use more mixed practice. Repetition helps most when it is paired with explanation, not just answer memorization.
Does the official dbt page still matter if this page already summarizes the exam?
Yes. The official page is still the source of truth for current facts, supported version, and certification wording.
Final CTA
For a quick reset before another practice block, go back to dbt Analytics Engineering and then revisit the sections above that feel weakest.
