Declaring downstream exposures for a model
Exposures let you document downstream uses of your dbt project—like dashboards, notebooks, or applications—directly in your dbt project so that lineage and impact analysis extend beyond models into the tools that consume them. They are defined in YAML and appear in the dbt docs DAG, helping teams understand what breaks if an upstream model changes.
Must-know
- Exposures are defined in YAML files (typically under an exposures: key) and can live in any .yml file within your models directory, not just a dedicated exposures.yml.
- Each exposure requires a name, type (dashboard, notebook, analysis, ml, or application), owner (with name and/or email), and a
depends_onlist referencing models, seeds, or snapshots via ref() or sources via source(). - Exposures show up as distinct nodes in the DAG and dbt docs site, enabling stakeholders to trace which exposures depend on a given model and assess downstream impact before making changes.
- The
depends_onfield must use ref() or source() function syntax (not hardcoded table names) so dbt can resolve the dependency graph correctly and include exposures in selection syntax like dbt run --select +exposure:my_dashboard. - Exposures do not run any code themselves—they are purely metadata/documentation nodes and have no compiled SQL or materialization.
- Common gotcha: forgetting to update or remove exposures when a downstream tool is deprecated leads to stale lineage information that misrepresents actual dependencies in dbt docs.
A dbt project defines the following exposure:
exposures:
- name: weekly_jaffle_report
type: dashboard
maturity: high
url: https://bi.tool/dashboards/1
depends_on:
- ref('fct_orders')
- ref('dim_customers')
owner:
name: Callum McData
email: [email protected]
You want to build fct_orders, dim_customers, and everything those two models depend on, using the exposure's own lineage instead of typing out each model name. Which command does this?
What you have tried across dbt Analytics Engineering's objectives, not a readiness score.
Developing and optimizing dbt models
- Tracing and confirming a model's upstream raw sources
- How dbt's core materialization types differ
- Keeping models modular and avoiding repeated logic
- What each core dbt command actually does
- Shaping a model's dependency graph so it stays readable
- Setting project-wide configuration in dbt_project.yml
- Pulling in and using a dbt package
- Writing a model in Python instead of SQL
- Granting model access through the grants config
- Configuring a snapshot to track slowly changing data
- Picking the right incremental strategy for a dataset
- Dry-running a model to check its logic and schema before a real build
- Sampling a model run before a full build
- What microbatch and other advanced materializations are for
Managing dbt models governance
Debugging data modeling errors
Troubleshooting and optimizing dbt pipelines
Implementing dbt tests
Implementing and maintaining external dependencies
Coverage checked against the published exam guide on Aug 5, 2026.
These are independent practice questions, written against this certification's published exam guide. They are not the certification vendor's own questions, and not the real exam.