dbt Labs · dbt-AE
Validates a candidate's ability to build, test, and maintain dbt projects by applying engineering best practices to analytics infrastructure. Requires SQL proficiency and at least six months of hands-on experience with dbt or dbt Core.
Practice Questions
600
≈ 9 practice exams
Duration
120 minutes
Passing Score
65%
Difficulty
ProfessionalLast Updated
Aug 2026
Use this dbt-AE practice exam to prepare for dbt Analytics Engineering Certification Exam with realistic questions, detailed explanations, and focused study modes. The practice bank includes 600 questions for dbt Labs dbt-AE, so you can review the exam steadily instead of relying on one long cram session.
As you practice, pay extra attention to recurring topics such as Developing and Optimizing dbt Models, Managing dbt Model Governance, Debugging Data Modeling Errors, Troubleshooting and Optimizing dbt Pipelines, and Implementing dbt Tests. Start with short sessions to identify weak areas, then move into timed quizzes once your accuracy is consistent.
The explanations are especially useful when you want to connect exam wording to the responsibilities and scenarios described in the official certification guidance. Use the free preview first, then unlock the full question bank when you are ready to build a complete study routine.
The dbt Analytics Engineering Certification (dbt-AE) is an official credential issued by dbt Labs that validates a practitioner's ability to build, test, and maintain production-grade dbt projects. The exam covers the full analytics engineering workflow: designing efficient DAG structures, applying appropriate model materializations (view, table, incremental, ephemeral, and microbatch), implementing snapshot strategies for slowly changing dimensions, writing Jinja macros, managing packages, and orchestrating deployments through dbt Cloud. The current exam aligns with dbt version 1.11 and is updated as the framework evolves.
Beyond core modeling, the certification assesses governance capabilities such as model contracts, versioning, and deprecation workflows defined in YAML, as well as operational skills including CI/CD pipeline configuration, Slim CI practices, state-based selection, DAG failure recovery using dbt retry, and source freshness monitoring. Candidates are also expected to debug compiled SQL and YAML configuration errors, making this a well-rounded validation of professional-level dbt proficiency rather than a narrow tool quiz.
This certification is designed for Analytics Engineers, Data Engineers, and Data Analysts who are actively working with dbt in professional environments. It is best suited for practitioners who design and maintain data transformation pipelines, collaborate with data consumers on modeled datasets, and are responsible for data quality and pipeline reliability within their organization.
Job titles commonly held by successful candidates include Analytics Engineer, Data Engineer, Analytics Engineer Lead, and Senior Data Analyst. Those looking to formalize their dbt expertise and differentiate themselves on the job market—particularly when moving into dedicated analytics engineering roles—will benefit most from pursuing this credential.
dbt Labs does not enforce formal prerequisites for exam registration, but strongly recommends that candidates possess SQL proficiency and at least six months of hands-on experience working with dbt or dbt Core before attempting the exam. Completing the free dbt Fundamentals course on dbt Learn is also strongly advised, as the exam assumes working familiarity with core dbt concepts rather than introducing them.
Candidates should be comfortable writing and debugging SQL transformations, structuring dbt projects (sources, models, tests, documentation), using the ref() and source() functions, and understanding the distinction between dbt Core and dbt Cloud. Those who have only theoretical knowledge without practical project experience are unlikely to meet the 65% passing threshold, as many questions are scenario-based and require applied judgment.
The exam consists of 65 scored questions delivered entirely online through the Talview proctored platform. Candidates have 120 minutes (2 hours) to complete the assessment. Questions are a mix of multiple-choice (single correct answer) and multi-select (choose all that apply) formats; multi-select questions are typically where candidates lose the most points, as all selections must be correct to receive credit.
The passing score is 65%, which equates to approximately 42 correct answers out of 65. The exam costs $200 USD and is administered remotely with online proctoring, so no in-person testing center visit is required. No expiration or mandatory recertification period has been published; credentials remain valid indefinitely under current policy. Candidates have access to an official study guide and 10 sample questions prior to sitting the exam.
Holding the dbt Analytics Engineering Certification signals to data-hiring teams that a candidate can independently manage production analytics infrastructure, not merely run dbt commands. The credential is recognized across companies of all sizes that have adopted the modern data stack, and it is commonly listed as a preferred or required qualification in Analytics Engineer and Senior Data Engineer job postings. It serves as a strong differentiating signal on a résumé when competing for roles that explicitly involve dbt, particularly as analytics engineering has become a distinct discipline separate from data engineering and data analysis.
While dbt Labs does not publish official salary data tied to the certification, analytics engineers with demonstrated dbt expertise—especially those who can govern models, implement CI/CD pipelines, and manage data quality at scale—command salaries in the range of $110,000–$160,000 USD annually in the United States, according to 2024–2025 market data. The certification complements cloud platform credentials (such as Snowflake, BigQuery, or Databricks certifications) and is increasingly paired with them by practitioners building a full modern data stack skill profile.
5 sample questions with answers and explanations. The full bank has 600 questions, enough for 9 full-length practice exams.
Preview — answers shown1. Graphic Design Institute's team maintains a two-paragraph explanation of 'customer lifetime value' that must appear identically across 12 different model and column description fields. Copy-pasting the text into each properties file already caused two copies to drift out of sync after an edit. What should the team do instead? (Select one!)
Explanation
A docs block lets the team define reusable documentation text once and reference it from any number of description fields using the doc() Jinja function, similar to how ref() centralizes model dependencies, which eliminates copy-paste drift. Global meta keys in dbt_project.yml are arbitrary key-value configuration and are not rendered as description text on the generated documentation site. SQL comments in model files are not parsed into descriptions by dbt docs generate. Seed files and post-hooks have no built-in mechanism for injecting shared documentation text into the generated site.
2. An analytics engineer at Adatum Analytics is writing internal documentation about how arguments behave in a macro defined as {% macro mask_pii(column_name, mask_char='*') %}. Which TWO of the following statements are accurate? (Select two!)
Multiple correct answersExplanation
Strings passed into a macro must be quoted, since an unquoted token like email_address is interpreted as a reference to an undefined Jinja variable rather than a literal string. Macro arguments also support default values, as shown by mask_char='*', letting callers omit that argument and rely on the fallback. Macro arguments are not always resolved at parse time; execution depends on when and where the macro is invoked, including inside execute-only blocks. dbt does not impose a five-parameter limit on macro signatures. Jinja macros also allow positional and keyword arguments to be mixed in the same call, similar to Python function calls.
3. Adatum Analytics is setting up cross-project references for dbt Mesh and wants a dependency file that supports only static values, with no environment-variable interpolation, for predictable and secure resolution. Which file should they use to declare the dependency? (Select one!)
Explanation
dependencies.yml only supports static values and is the preferred file for declaring dbt Mesh cross-project dependencies because it does not render Jinja. packages.yml does support Jinja templating with env_var(), which is useful for injecting secrets but is not the static, predictable format Mesh cross-project references call for. package-lock.yml is an auto-generated lock file that records resolved versions; engineers do not manually declare dependencies in it. selectors.yml defines reusable node-selection criteria and has nothing to do with declaring package dependencies.
4. A developer at Contoso successfully runs dbt run for the model stg_transactions, which is configured with a custom schema in its config block. When the developer then runs SELECT * FROM analytics.stg_transactions directly in the warehouse's query editor, it fails with 'relation "analytics.stg_transactions" does not exist.' What is the most likely explanation? (Select one!)
Explanation
By default, dbt's generate_schema_name behavior concatenates the connection's target schema with the custom schema specified in the model's config, producing a combined schema name such as analytics_finance rather than placing the table in the bare target schema. This is a naming convention issue, not a permissions problem, so the CREATE privilege explanation does not apply since the run itself succeeded. A --full-refresh is unrelated because the table was already built successfully. Models materialized as tables or views are ordinary database objects and can be queried directly outside of dbt once the correct schema name is used.
5. A teammate at Woodgrove Bank edits models/staging/stg_accounts.yml in an editor that inserts a tab character on one line while the rest of the file uses two-space indentation. Running dbt immediately fails with a YAML parsing error. What is the correct resolution? (Select one!)
Explanation
YAML relies entirely on whitespace to define structure, and mixing tabs with spaces produces inconsistent indentation that the parser cannot resolve, so replacing the tab with spaces to match the surrounding indentation fixes the error. Adding a version key controls dbt's property-file schema expectations, not whitespace parsing, and does not address a malformed indentation character. The .yml and .yaml extensions are treated identically by dbt's parser, so renaming the file changes nothing. Property files are parsed based on their location within models/, not project root, and moving the file does not fix the underlying whitespace problem.
$17.99
One-time access to this exam