dbt Analytics Engineering Certification: Troubleshooting and Optimizing dbt Pipelines Practice Questions

By default in dbt Cloud, when a command in a job step fails (returns a non-zero exit code), the subsequent commands in that job do not execute and the overall job is marked as failed. dbt snapshot would not run. Option C incorrectly describes a 'continue on error' behavior that is not the default. Option D is incorrect — dbt Cloud does not automatically retry individual commands within a job by default. Option A is incorrect; there is no built-in 'warning-only' mode for test failures at the job level.

By default, dbt test uses --no-fail-fast, meaning dbt runs ALL tests even after encountering failures. However, when a step in a dbt Cloud job exits with a non-zero return code (because tests failed), the job halts and does not proceed to any subsequent commands. Option A is wrong — dbt does not stop mid-step on the first failure unless --fail-fast is explicitly set. Option C is wrong — subsequent job commands are NOT executed after a step fails. Option B is wrong — failed tests are recorded as errors (or warnings only if warn_if / error_if thresholds are configured), not silently skipped.

Goal 3 (reference prod outputs without rebuilding) requires deferral to the production environment (Option C). Goal 1 and 2 (only changed models and descendants, no full rebuild) require --select state:modified+ (Option A). Together these two settings implement the standard Slim CI pattern. Option D (--full-refresh) is the opposite of cost-saving — it forces a full rebuild of all selected models. Option E does not exist as a dbt Cloud toggle. Option B using manual tag:ci does not dynamically adapt to what changed in each PR and requires constant maintenance.

result:failed+ selects nodes that failed in the prior run plus all their downstream dependents (which were likely skipped due to upstream failure). Combined with --defer and --state, unchanged upstream models are referenced from their existing prod materializations rather than rebuilt. This is the precise pattern for targeted retries. Option C (state:modified+) compares file state, not run result state — it would not correctly identify which models errored at runtime. Option B (result:error result:skipped) is close but misses the + to include downstream dependents of failed models; also using dbt run skips tests. Option A is tempting — dbt retry is a real command introduced in dbt v1.6 that re-runs failed and skipped nodes from the last run — however, it does not support the --defer flag for cross-environment deferral, making it less suitable for a separate retry job that needs to reference production state artifacts explicitly. Option D represents the fully explicit and controllable production pattern.

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 B uses dbt test alone, which skips the model build step — changed models would not be rebuilt before testing. Option D omits --defer, meaning dbt would try to build all upstream models rather than reusing production artifacts, and state:modified (without +) misses downstream impacts. Option A uses path:modified, which is not a valid dbt selection method — state:modified is the correct selector.