What you will be able to do
- Put job commands in an order where gating checks run before the work they protect
- Choose between a separate dbt run and dbt test sequence and a single dbt build
- Place source freshness as a checkbox, a first step, a last step or a separate job, depending on whether stale data should block models
- Predict whether a later run step will execute after a test warning, a failed node or a selector that matches nothing
Key concept
Chained run steps — A dbt job runs its commands one after another as run steps. As soon as one step fails, none of the steps after it run. This makes the order of commands a design decision: whatever sits early in the list can stop everything that comes after it.
1.Why the position of a command decides what runs
A dbt job executes its commands as a chain of run steps. The full anatomy of those steps is covered in [run steps within a dbt job](lesson:4.2). One rule from that lesson drives every ordering choice here: when a step fails, the commands after it are not executed, and the job ends with an Error status and a non-zero exit code.
That rule turns the command list into a set of gates. A step placed first can stop everything below it, and a step placed last can fail without costing you anything that already ran. So the first question to ask about any command is whether a failure in it should stop the rest of the job. If it should, for example a check that your inputs are good enough to build on, put it early. If it should not, for example a report you only want for information, put it late or move it to a job of its own.
You don't need to fit the setup work into this order. Every job already includes dbt deps and a step that reclones the repository and connects to the data platform, so you never add those yourself. The list you control must still contain at least one dbt command. A new deploy job starts with dbt build as its only command, and you add commands around it.
Checkpoint 1 of 7· Check yourself
A job has four commands. The second one fails. What happens to commands three and four?
The run steps are chained, so a failure stops every step after it and the whole job is marked Error.
“then the next commands aren't executed, and the entire job fails with an "Error" job status.”Source: docs.getdbt.com
Checkpoint 2 of 7· Exam question
An architect reviews a job's run history and notices `dbt deps` executing before any configured commands, even though no one added it to the command list. Which statement best describes why this step appears and how it is scoped?
Correct answer: A — dbt Cloud automatically inserts `dbt deps` as the first chained step in every job run, so package dependencies install before any configured commands execute.
- A. dbt Cloud auto-inserts `dbt deps` and the repository/connection setup as chained steps before any configured commands run, and this happens for every job unconditionally.
- B. This is incorrect because `dbt deps` is inserted for every job run regardless of whether `packages.yml` changed; there is no differential check controlling whether it executes.
- C. This is incorrect because the automatic step applies to all job types, including deploy and merge jobs, not only PR-triggered CI jobs; deploy jobs never need to add it manually.
- D. This is incorrect because the automatic step is not tied to a dbt version override; it always runs first regardless of any version setting on the job or environment.
2.dbt run before dbt test, or one dbt build
dbt test checks things that must already exist. It runs data tests against models, sources, snapshots and seeds that earlier commands built. If a job lists dbt test before dbt run, the tests either query stale tables from the previous run or fail because a new model doesn't exist yet. With separate commands, the order is always: build first, test second.
That two-step order has a weakness. Every model is built before any test runs, so a model that fails its unique test has already fed its bad rows into the models downstream of it by the time the test reports. dbt build closes this gap. It runs models, tests, snapshots and seeds in DAG order, and a failed test on an upstream resource makes its downstream resources skip. If model_b depends on model_a and a unique test on model_a fails, model_b is never built.
Unit tests sharpen the ordering inside dbt build. For each SQL model, the unit tests run first, then the model is materialized, then its data tests run. A model whose logic fails a unit test is never written to the warehouse, which also saves warehouse spend.
| Command sequence | What it covers | What a failed test does |
|---|---|---|
| dbt run, then dbt test | dbt run builds models only; dbt test then tests what already exists | Fails the test step after every model is already built |
| dbt build | Models, tests, snapshots and seeds in DAG order | Downstream resources skip, and the command exits with code 1 |
Checkpoint 3 of 7· Put it in order
Inside dbt build, put the work done for one SQL model that has unit tests and data tests in execution order.
- 1.Data tests run on the model
- 2.Unit tests run on the SQL model
- 3.The model is materialized
Unit tests act as a gate before materialization, and data tests then check the table that was built.
“This saves on warehouse spend as the model will only be materialized if the unit tests pass successfully.”Source: docs.getdbt.com
Checkpoint 4 of 7· Exam question
A data platform team enables the 'Run source freshness' checkbox on a deploy job that also has two custom commands configured: `dbt build` and `dbt test --select tag:critical`. Where does the source freshness check execute relative to the custom commands, and what happens to the job if it fails?
Correct answer: A — Source freshness runs as the first configured run step, before the custom commands, and a freshness failure does not fail the job as long as the subsequent steps succeed.
- A. This is correct because the checkbox inserts source freshness as the first run step before the configured command list, and its failure does not fail the whole job when the later steps still succeed.
- B. This is incorrect because freshness does not slot between custom commands; it always runs first, before any command in the configured list executes.
- C. This is incorrect because freshness is not appended last; it precedes the custom commands, and a failure there specifically does not force the job into an Error status by itself.
- D. This is incorrect because dbt Cloud job steps execute sequentially as chained steps rather than concurrently on separate threads, so there is no parallel freshness check.
3.Where source freshness belongs
Source freshness never runs unless you add it. dbt build does not include freshness checks, so a job that should know whether its source data is current needs one of two mechanisms. The two look alike in the job settings, but they behave in opposite ways when a source is stale.
The Run source freshness checkbox in Execution settings always runs dbt source freshness as the first step, and its failure does not break later steps. Freshness becomes a report: you see the result, and the models still build. A job dedicated only to freshness checks still needs at least one placeholder command, such as dbt compile, because a job cannot have an empty command list.
Adding dbt source freshness as a run step makes it a gate. Out-of-date data fails the step, and every step after it is skipped. Its position therefore depends on what stale data should mean for the job. Put it first when you would rather publish nothing than publish models built on late data. Otherwise, put it last or give it a separate job, so that a late source never stops a build that would have succeeded.
| Configuration | Where it runs | If sources are stale | Use when |
|---|---|---|---|
| Run source freshness checkbox | Always the first step | Later steps still run | You want visibility without blocking builds |
| dbt source freshness as the first run step | First, before dbt build | Step fails; later steps do not run | Models must not run on out-of-date data |
| dbt source freshness as the last run step | After the build steps | Step fails after the build has finished | Freshness should be reported but never block the build |
| Separate freshness job | In its own job, with a placeholder such as dbt compile if only the checkbox is used | Only that job is affected | Checks must run more often than the build |
Checkpoint 5 of 7· Check yourself
Your team would rather skip a nightly build than publish models built on late source data. How should freshness be configured?
As a run step, freshness fails when sources are stale, and the chain stops every later step. The checkbox never blocks later steps, and dbt build does not check freshness.
“it could be a good idea to run dbt source freshness as the first step in your job”Source: docs.getdbt.com
Checkpoint 6 of 7· Exam question
A developer opens a pull request, triggering the project's CI job configured with the default command. The job fails immediately with an error about being unable to resolve `state:modified+`. What is the most likely cause?
Correct answer: A — No deferred environment is configured for comparison, so `dbt build --select state:modified+` has no prior manifest to diff against and cannot determine which models changed.
- A. This is correct because `state:modified+` compares the PR's manifest against a deferred environment's last successful run, and without that deferral configured there is nothing to diff against, causing resolution to fail.
- B. This is incorrect because `state:modified+` detects changes across any tracked project file, including YAML configuration, not only SQL models, so a YAML-only change would still resolve.
- C. This is incorrect because the selector behaves the same whether the CI job was triggered by opening a PR or by a subsequent push to it; the trigger type does not affect selector resolution.
- D. This is incorrect because dbt Cloud plan tier does not disable state-based selectors; deferral configuration, not plan tier, is what `state:modified+` depends on to resolve.
Sources5
4.Which outcomes stop the next step
Placing a gating command early only helps if you know which outcomes count as a failure. Some results that look bad leave the chain intact, and some results that look small stop it.
These cases decide whether the next command runs:
- One failed node in a selection. If a selector matches several nodes and one of them fails, the command exits with code 1 and the next command does not run.
- A test that warns. Tests can pass, fail or warn. Unless warnings are treated as errors, only an error fails the command, so a warn-severity test lets the chain continue.
- A selector that matches nothing. This is not a failure. A dbt test --select one_specific_model step after a rename still passes, without testing anything.
- **--fail-fast.** The first failure stops the entire connection for any models still in progress, instead of letting parallel models finish.
Inside a single dbt run or dbt build, a failed model skips the models downstream of it by default. From dbt v1.12, setting on_error: continue on a model lets its downstream models still attempt to run. That setting changes behaviour inside one command only. A failed command still stops the commands after it in the job.
Checkpoint 7 of 7· Check yourself
Step one of a job is dbt test --select legacy_orders, but legacy_orders was deleted last week. Step two is dbt build. What happens?
A selector that matches no nodes does not count as a failure, so the chain continues. Note that nothing was tested.
“If a selector doesn't match any nodes, it's not considered a failure.”Source: docs.getdbt.com
Sources1
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.The Run source freshness checkbox and a dbt source freshness run step do the same thing, so either one will stop models from building on stale data.Why is that wrong?
The checkbox runs first and never breaks later steps. Only a run step fails the chain, and to block models it has to come before them.
Covered in Where source freshness belongs
2.A job with only dbt run also tests the models it builds.Why is that wrong?
dbt run materializes models and nothing else. Tests need dbt test after the build, or dbt build, which runs them in DAG order.
Covered in dbt run before dbt test, or one dbt build
3.A run step whose selector matches no models fails and stops the rest of the job.Why is that wrong?
A selector that matches nothing is not a failure. The step succeeds without doing any work, and later steps run.
Covered in Which outcomes stop the next step
4.dbt deps has to be added as the first command so that packages are installed before dbt build.Why is that wrong?
Every job invocation already includes dbt deps, so it never needs a place in the command list.
Sources
Every claim above is drawn from one of these pages, quoted as it was written on the date shown.
- 1.https://docs.getdbt.com/docs/deploy/job-commandsOfficial docs
“then the next commands aren't executed, and the entire job fails with an "Error" job status.”
↩︎ Why the position of a command decides what runs“every job will include a run step to reclone your repository and connect to your data platform”
↩︎ Why the position of a command decides what runs“However, you need to have at least one dbt command.”
↩︎ Why the position of a command decides what runs“If you specified the --fail-fast flag, then the first failure will stop the entire connection for any models that are in progress.”
↩︎ Which outcomes stop the next step“Unless you set warnings as errors, only an error fails the command.”
↩︎ Which outcomes stop the next step“In dbt v1.12+, you can set on_error: continue on a model to allow its downstream models to still attempt to run despite the failure.”
↩︎ Which outcomes stop the next step“During a job run, the commands are "chained" together and executed as run steps.”
↩︎ Key concept“If a selector doesn't match any nodes, it's not considered a failure.”
↩︎ Exam trap 3“Every job invocation automatically includes the dbt deps command, meaning you don't need to add it to the Commands list in your job settings.”
↩︎ Exam trap 4“If a selector doesn't match any nodes, it's not considered a failure.”
↩︎ Checkpoint - 2.https://docs.getdbt.com/docs/deploy/deploy-jobsOfficial docs
“By default, it includes the dbt build command.”
↩︎ Why the position of a command decides what runs - 3.https://docs.getdbt.com/reference/commands/testOfficial docs
“It expects that you have already created those resources through the appropriate commands.”
↩︎ dbt run before dbt test, or one dbt build - 4.https://docs.getdbt.com/reference/commands/buildOfficial docs
“In DAG order, for selected resources or an entire project.”
↩︎ dbt run before dbt test, or one dbt build“If model_b depends on model_a, and a unique test on model_a fails, then model_b will SKIP.”
↩︎ dbt run before dbt test, or one dbt build“This saves on warehouse spend as the model will only be materialized if the unit tests pass successfully.”
↩︎ dbt run before dbt test, or one dbt build - 5.https://docs.getdbt.com/docs/deploy/source-freshnessOfficial docs
“dbt build does not include source freshness checks when building and testing resources in your DAG.”
↩︎ Where source freshness belongs“will run dbt source freshness as the first step in your job and won't break subsequent steps if it fails.”
↩︎ Where source freshness belongs“you still need to include at least one placeholder step, such as dbt compile.”
↩︎ Where source freshness belongs“Otherwise, we recommend adding dbt source freshness as the last step in the job, or creating a separate job just for this task.”
↩︎ Where source freshness belongs“will run dbt source freshness as the first step in your job and won't break subsequent steps if it fails.”
↩︎ Exam trap 1“it could be a good idea to run dbt source freshness as the first step in your job”
↩︎ Checkpoint
Also cited
“The dbt run command only applies to models. It doesn't run tests, snapshots, seeds, or other resource types.”
↩︎ Exam trap 2“The dbt run command only applies to models. It doesn't run tests, snapshots, seeds, or other resource types.”
↩︎ Prediction