What you will be able to do
- Choose between a deploy job, a CI job and a merge job based on its purpose, trigger and destination
- List what must exist before a job can be created and where in dbt you create it
- Fill in the Job settings section and predict the commands each job type starts with
- Recognise which run steps dbt adds to every job without being asked
Key concept
dbt job — A dbt job bundles three things that run together against your data platform: an ordered list of dbt commands (its run steps), the settings those commands run with, and a trigger that starts it. Creating a job means choosing all three, inside a deployment environment that supplies the connection, code and dbt version.
1.What a dbt job is and what each run records
A job is how dbt runs your project without a person at a keyboard. A developer runs dbt build by hand from the command line or the Studio IDE; a job runs the same commands on a trigger, in a deployment environment, and keeps a record of every run. That record is what makes a job useful in production. When something breaks at 3 a.m., you open the run instead of trying to reproduce it.
Every run gets an entry in the job's run history and its own run overview. The overview shows the trigger type that started the run, the commit SHA it ran against, and the environment name. It also has timing data for the run and for each model, the artifacts the run produced, and every run step with its logs and status. Two runs of the same job can differ in commit and trigger, and the overview tells you which ones a given run used.
A job does not bring its own warehouse connection or code. Those come from the environment it belongs to. A deployment environment decides the dbt version, the warehouse connection and target schema, the credentials, and the version of your code to execute. That is why every job is created from inside an environment. One hard limit applies to every job type: a single run may last at most 24 hours.
Checkpoint 1 of 8· Check yourself
A deploy job failed overnight and an engineer needs to know which commit it built. Where do they find it?
Each job run gets its own run overview, which records the trigger type, the commit SHA and the environment name for that run.
“Each job run in dbt will have an entry in the job's run history and a detailed run overview”Source: docs.getdbt.com
2.Choosing a deploy, CI or merge job
You pick the job type before anything else, because it fixes what can trigger the job and where it builds. Any of the three can run dbt commands. What differs is when each one runs and what it is allowed to touch.
| Aspect | Deploy job | CI job | Merge job |
|---|---|---|---|
| Purpose | Builds production data assets | Builds and tests new code before merging changes into production | Builds merged changes into production or updates state for deferral |
| Trigger | A schedule, API, or the successful completion of another job | A commit to a PR, or API | A successful merge into the environment's branch, or API |
| Destination | Production database and schema | Staging database and ephemeral schema, lived for the lifetime of the PR | Production database and schema |
| Execution mode | Runs execute sequentially | Runs execute in parallel | Runs execute sequentially |
A deploy job is the workhorse, for example a daily build that refreshes production tables. It runs on a timetable, by API, or after another job finishes. A CI job protects production instead of building it. It runs when someone opens or updates a pull request, builds into a throwaway schema that lasts as long as the PR, and runs in parallel so several developers' PRs do not queue behind each other. A merge job is continuous deployment: when a PR merges into the environment's branch, it pushes the change into production without anyone starting a run.
Execution mode follows from the destination. Deploy and merge jobs write to the same production schema, so their runs execute one after another to avoid collisions on the DAG. CI runs each write to their own PR schema, so they can safely overlap. Each type also has its own way to avoid wasted runs. A deploy job detects over-scheduled runs and cancels the unnecessary ones. A CI job cancels its existing run when a newer commit is pushed.
Checkpoint 2 of 8· Match them up
Match each job type to the event that starts it automatically
Tap a term, then the definition that fits it.
All three can also be started by API. Without the API, a deploy job runs on time or after another job, a CI job on PR activity, and a merge job on a completed merge.
“Merge jobs — Deploy merged changes into production. Runs after a successful PR merge or by API.”Source: docs.getdbt.com
Checkpoint 3 of 8· Exam question
A dbt Cloud deploy job runs three chained steps in order: `dbt seed`, `dbt run --select stg_orders+`, and `dbt test --select stg_orders+`. During a scheduled run, the second step fails with a compilation error before the third step starts. What happens to the job run?
Correct answer: B — The third step is skipped and the run is marked Error, because chained run steps stop executing once any earlier step fails.
- A. This is incorrect because dbt Cloud run steps are chained, not independent: once a step fails, dbt Cloud does not continue on to steps that were listed after it.
- B. This is correct. Run steps execute in the order they are configured, and a failure in any step stops the remaining steps from running and sets the overall job status to Error.
- C. This is incorrect because dbt Cloud does not automatically retry a failed run step; a failed step simply halts the rest of that run.
- D. This is incorrect because dbt Cloud job execution has no manual-approval gate between run steps; the job either continues automatically or stops on failure.
Sources4
3.Prerequisites and where you create the job
A job can only be created once four things are in place:
- A dbt account with a Developer seat license - A dbt project connected to a data platform - Permission to view, create, modify or run jobs - A deployment environment for the job to run in
The environment is the requirement people forget. If you are setting up a project from scratch, [creating the deployment environment](lesson:3.5) comes first, because that environment's page is where the Create job button sits.
Create job opens a menu with one entry per type: Deploy job, Continuous integration job and Merge job. Whichever you pick, the new job belongs to the environment you started from. That makes the choice of environment a design decision, not a formality. For CI, dbt Labs recommends a dedicated deployment environment connected to a staging database, which keeps temporary PR schemas apart from production builds.
CI and merge jobs both need a connection to your Git provider first, because dbt reacts to Git events on your behalf. A merge job adds two more conditions. It relies on push events, so those must be enabled in the Git provider, which is worth checking on an older integration. And because a merge job defers by default, the environment it defers to needs at least one successful run. Deferral means comparing the code being built against the project state, the manifest.json, left by the last successful run in that environment, so that only changed models are built. With no successful run there, the merge job has no state to compare against.
Checkpoint 4 of 8· Put it in order
Put the steps for creating a project's first deploy job in order
- 1.Fill in the Job settings section, starting with the job name
- 2.Click Create job > Deploy job
- 3.Open that deployment environment's page
- 4.Set up a deployment environment
A deployment environment is a prerequisite, and the Create job menu lives on its page. The Job settings section is the first part of the form that opens.
“On your deployment environment page, click Create job > Deploy job to create a new deploy job.”Source: docs.getdbt.com
Checkpoint 5 of 8· Exam question
A data platform team wants pull requests opened against their GitLab repository to automatically trigger a CI job in dbt Cloud, without any code merging first. Which configuration makes this trigger possible?
Correct answer: A — Connect the project to GitLab through dbt Cloud's native Git integration, so dbt Cloud registers the webhook needed to detect pull requests.
- A. This is correct. A native GitLab integration lets dbt Cloud auto-register the webhook that notifies it when pull requests are opened or updated, which is what actually fires a CI job.
- B. This is incorrect because a time-based schedule is not event-driven; it cannot detect a pull request the moment it is opened and is not how CI triggers work in dbt Cloud.
- C. This is incorrect because merge jobs fire on merge to a branch, not on pull request creation, so switching job type does not produce the requested pull-request trigger.
- D. This is incorrect because on_merge fires when code is merged into a branch, not when a pull request is first opened, so it does not match the stated requirement.
4.Job settings and the commands each type starts with
Every job type opens with the same Job settings section: a job name, an optional description, and an Environment field already set to the environment you came from. Use the description to say what the job consumes and what it produces. Whoever opens a failing run months later will read that before anything else.
Next comes the Execution settings section, where dbt has already filled in a command. The pre-filled command tells you what each job type is for:
- A deploy job starts with dbt build.
- A CI job starts with dbt build --select state:modified+.
- A merge job also starts with dbt build --select state:modified+.
The state:modified+ selector builds only new or changed models and their downstream dependents. To know what changed, it needs something to compare against, and that is what deferral supplies: dbt compares the project's code with the manifest.json of the last successful run in a chosen environment, and builds only the modified code instead of the entire DAG. Without a deferred environment, state comparison cannot happen. That is why CI and merge jobs come with deferral switched on: CI defaults to the Production environment, and merge defaults to the environment the job was created from.
Checkpoint 6 of 8· Fill the gap
Complete the default command a new CI job starts with
Commands — By default, this includes the dbt build --select ? command.The trailing + adds downstream dependents, so the CI job builds every changed model and everything that depends on it.
Source: docs.getdbt.comYou can edit the default or click Add command to add more, but a job must keep at least one dbt command. Some steps you never add yourself. Every run automatically runs dbt deps, and every run includes a step that reclones the repository and connects to the data platform. Those steps can fail too, and when they do they affect the job status. Commands run as a chain, so if one run step fails, the remaining ones are skipped and the job ends in Error. [Steps within a job](lesson:4.2) and [command order](lesson:4.4) cover that chain in detail.
One checkbox on a deploy job behaves differently from the commands. Run source freshness runs dbt source freshness before the job, but a failure in that step does not doom the run: the job can still succeed if the later steps pass. Further down the form are the trigger and the optional settings. Each has its own lesson: [scheduling](lesson:4.3), [running after another job](lesson:4.8), and [overrides such as threads, target name and dbt version](lesson:4.6).
Checkpoint 7 of 8· Check yourself
A new deploy job's Commands list contains only dbt build. A teammate says it will fail on the first run because dbt deps was never added. What actually happens?
Every job invocation includes dbt deps automatically, so you do not need to add it to the Commands list.
“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.”Source: docs.getdbt.com
Checkpoint 8 of 8· Exam question
An analytics engineering team wants production models to rebuild automatically the moment a pull request is merged into `main`, without waiting for the next scheduled run. Which job type fits this requirement?
Correct answer: C — A merge job, which triggers automatically when a pull request is merged to the configured branch and defers to build only modified models.
- A. This is incorrect because a fixed cron interval only approximates immediacy and still depends on plan-specific scheduling limits rather than reacting to the merge event itself.
- B. This is incorrect because a CI job with github_webhook triggers on pull request activity, not on a merge into the target branch, so it does not fire at the merge moment described.
- C. This is correct. A merge job is the job type built to trigger automatically when a pull request merges into the environment's configured branch, and it defers to build only what changed.
- D. This is incorrect because a chained job depends on another dbt Cloud job finishing, not on a Git merge event, so it does not directly satisfy the stated trigger requirement.
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.You must add dbt deps as the first command of every job, or package-dependent models will fail.Why is that wrong?
dbt runs dbt deps automatically on every job invocation, alongside a step that reclones the repository and connects to the data platform.
Covered in Job settings and the commands each type starts with
2.A new CI job starts with the same plain dbt build command as a deploy job.Why is that wrong?
CI and merge jobs start with dbt build --select state:modified+, which builds only changed models and their dependents. Only deploy jobs start with plain dbt build.
Covered in Job settings and the commands each type starts with
3.If the Run source freshness step fails, the whole deploy job fails with Error status, like any other failed step.Why is that wrong?
Source freshness enabled through the checkbox is the exception to the chain: the job can still succeed if the later steps pass.
Covered in Job settings and the commands each type starts with
4.A merge job only needs pull request events from the Git provider, like a CI job.Why is that wrong?
Merge jobs depend on push events, which must be enabled in the Git provider. This is especially worth checking on an existing integration.
Covered in Prerequisites and where you create the job
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/deploy-jobsOfficial docs
“Each job run in dbt will have an entry in the job's run history and a detailed run overview”
↩︎ What a dbt job is and what each run records“You must have access permission to view, create, modify, or run jobs.”
↩︎ Prerequisites and where you create the job“dbt will compare against the project representation (which is stored in the manifest.json) of the last successful deploy job run”
↩︎ Prerequisites and where you create the job“Commands — By default, it includes the dbt build command.”
↩︎ Job settings and the commands each type starts with“dbt will compare against the project representation (which is stored in the manifest.json) of the last successful deploy job run”
↩︎ Job settings and the commands each type starts with“If the step fails, the job can succeed if subsequent steps pass.”
↩︎ Exam trap 3“On your deployment environment page, click Create job > Deploy job to create a new deploy job.”
↩︎ Prediction - 2.https://docs.getdbt.com/docs/deploy/job-commandsOfficial docs
“rather than running dbt commands manually from the command line or Studio IDE”
↩︎ What a dbt job is and what each run records“You can add or remove as many dbt commands as necessary for every job. However, you need to have at least one dbt command.”
↩︎ Job settings and the commands each type starts with“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 1“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.”
↩︎ Checkpoint - 3.
“To execute dbt, environments determine the settings used during job runs, including:”
↩︎ What a dbt job is and what each run records - 4.https://docs.getdbt.com/docs/deploy/jobsOfficial docs
“Limit is 24 hours.”
↩︎ What a dbt job is and what each run records“Deploy jobs — Build production data assets. Runs on a schedule, by API, or after another job completes.”
↩︎ Choosing a deploy, CI or merge job“Runs execute in parallel to promote team velocity.”
↩︎ Choosing a deploy, CI or merge job“Cancels existing runs when a newer commit is pushed to avoid redundant work.”
↩︎ Choosing a deploy, CI or merge job“Merge jobs — Deploy merged changes into production. Runs after a successful PR merge or by API.”
↩︎ Checkpoint - 5.https://docs.getdbt.com/docs/deploy/ci-jobsOfficial docs
“dbt Labs recommends that you create your CI job in a dedicated dbt deployment environment that's connected to a staging database.”
↩︎ Prerequisites and where you create the job“Importantly, state comparison can only happen when there is a deferred environment selected to compare state to.”
↩︎ Job settings and the commands each type starts with“Commands — By default, this includes the dbt build --select state:modified+ command.”
↩︎ Exam trap 2 - 6.https://docs.getdbt.com/docs/deploy/merge-jobsOfficial docs
“For deferral (which is the default), make sure there has been at least one successful job run in the environment you defer to.”
↩︎ Prerequisites and where you create the job“Merge jobs require push events so make sure they've been enabled in your Git provider”
↩︎ Exam trap 4
Also cited
“A collection of run steps, settings, and a trigger to invoke dbt commands against a project in the user's cloud data platform.”
↩︎ Key concept