Tracing and confirming a model's upstream raw sources
Raw object dependencies are references to source tables/views in the underlying data platform (not other dbt models) that a dbt project relies on. Before building or optimizing models, analytics engineers must identify these upstream raw dependencies and verify they exist, are accessible, and are correctly declared so the DAG builds accurately and lineage stays trustworthy.
Must-know
- Raw dependencies should be declared using source() functions in models, pointing to tables/views defined in a sources.yml file rather than hardcoded schema.table references.
- Running dbt source freshness checks whether raw source tables are being loaded on the expected schedule, helping surface stale or broken upstream dependencies.
- The dbt docs generate command combined with dbt docs serve lets you inspect the DAG and confirm which raw sources feed into which models, making it easier to spot missing or unused dependencies.
- Using source() instead of direct table references ensures raw dependencies appear correctly in the DAG and enables features like source freshness and lineage graphs.
- A model that references a raw table directly (e.g., via a raw SQL FROM clause) bypasses dbt's dependency tracking, which can break run order and make impact analysis unreliable.
- The dbt list (or ls) command with selectors like source:* can be used to verify which sources exist in the project and confirm they are referenced as expected before development or refactoring begins.
A model's compiled SQL contains the following FROM clause, written directly against the raw table instead of using the source() function:
select *
from "analytics_raw"."stripe"."payments"
The payments table is already correctly declared under a stripe source block in sources.yml. What is the practical consequence of referencing the raw table this way instead of with source('stripe', 'payments')?
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 4, 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.