Deployment and orchestration: free practice questions

In dbt Cloud, Development environments are tied to individual developers who can work on custom branches and override credentials (e.g., personal schemas), while Deployment environments are used for scheduled jobs that run against a canonical branch (often `main`) with service-account credentials. Option B is wrong — both environment types support all dbt commands. Option C is partially true (schemas can differ) but misrepresents how it works; schema separation is a profiles/environment variable setting, not a hard platform restriction. Option D is false — both use dbt Core execution under the hood in dbt Cloud.

Option A is correct: `dbt build` runs tests on each node before building its downstream dependents, preventing bad data from propagating — the split approach does not offer this guarantee. Option B is correct: `dbt build` handles seeds, snapshots, models, and tests in a unified dependency-aware execution, whereas separate `dbt run` + `dbt test` commands would not naturally interleave snapshot and seed execution in the right order. Option C is incorrect — Slack notifications are not a built-in feature of `dbt build`; they require external integrations. Option D is incorrect — both `dbt run` and `dbt build` compile SQL before executing each model. Option E is a misconception; connection usage depends on thread settings and model count, not the specific command used.

`result:error` is a dbt node selection method that selects models whose previous run resulted in an error, using the `run_results.json` from that prior run (pointed to by `--state`). This allows targeted re-execution of only failed models. Option A uses `state:modified`, which compares the current project code against a prior manifest — it selects models whose code changed, not models that failed. Option B (`dbt retry`) is a valid dbt Cloud UI feature and a CLI command (added in dbt v1.6), but it is less precise than `result:error` for scripted use and not always available in all dbt Core workflows — however, note that `dbt retry` IS a correct modern answer; if the exam context is dbt Cloud specifically, both B and C could be considered correct, but the most universally applicable and explicit command is C. Option D uses `last_run:failed`, which is not a valid dbt selection syntax.

`dbt build` is the preferred command for Slim CI because it runs models, tests, seeds, and snapshots together. `state:modified+` selects all modified models AND their downstream dependents (ensuring nothing downstream of a change is missed). `--defer` tells dbt to resolve references to unmodified upstream nodes from the production manifest rather than rebuilding them. `--state` points to the directory containing the production `manifest.json`. Option A uses `dbt test` alone, which skips the model build step — changed models would not be rebuilt before testing. Option C omits `--defer`, meaning dbt would try to build all upstream models rather than reusing production artifacts, and `state:modified` (without `+`) misses downstream impacts. Option D uses `path:modified`, which is not a valid dbt selection method — `state:modified` is the correct selector.

The `+` prefix operator selects a model and all of its upstream ancestors (parents, grandparents, etc.). This ensures all dependencies of `orders` are also run. Option B describes the `orders+` syntax (suffix `+`), which selects descendants. Option C is wrong — `+orders` includes all ancestors at all depths, not just direct parents, and it does include `orders` itself. Option D is wrong — the `+` operator is a graph traversal operator, not a directory-scoped selector.