Free dbt Analytics Engineering Certification Exam practice test: 30 questions with answers

An incremental model builds the full table once and, on later runs, its is_incremental() block limits the work to new rows, so history is kept without a full scan. A view stores no data, an ephemeral model is only inlined SQL that is never persisted, and a full-rebuild table reprocesses every row on every run.

Microbatch splits the input into time-based batches using the event_time column and batch_size, and each batch is processed as its own unit. A unique_key merge describes a different incremental approach, a staging-table rename is not how microbatch works, and a per-value Jinja loop is not part of the strategy.

A Python model defines a model(dbt, session) function, uses dbt.ref() and dbt.source() to read upstream relations, and returns one dataframe that dbt writes to the warehouse. It runs on the platform's Python runtime rather than being compiled to SQL, and it returns only one dataframe per model.

A YAML snapshot with the timestamp strategy adds a new version of a row when updated_at changes and records dbt_valid_from and dbt_valid_to, which gives slowly changing history. A merge overwrites rows so history is lost, a view stores no history, and an ephemeral model is only a CTE that is never persisted.

A merge incremental strategy with unique_key uses the key to update an existing row or insert a new one, so each order_id stays unique. Append adds rows without checking keys, which creates duplicates, a snapshot keeps dated versions and so several rows per key, and an ephemeral model is never stored.

With an enforced model contract, dbt compares the model's columns and declared data types with the YAML during the build and fails when they do not match. Null tests check values rather than structure, descriptions only document the model, and a table materialization does not keep schema history.

Model versions let a consumer reference a specific version with ref('orders', v=1), while an unversioned ref resolves to the latest_version. A single project can hold several versions, and the warehouse does not delete an older version because a newer one exists.

A deprecation_date marks a version as being retired, and dbt issues warnings to consumers who still reference it, which gives them time to move to a newer version. Deleting the version does not rewrite refs, ephemeral materialization hides nothing from consumers, and renaming breaks existing references.

Constraints in YAML become part of the model's DDL only when its contract is enforced, and some platforms accept constraints as metadata without enforcing them. Constraints are not run as tests, are not checked during parse, and cannot replace unique tests on every warehouse.

When a contract is enforced, dbt compares the SQL output with the declared columns and data types during the build and fails on any mismatch. dbt never edits YAML on its own, and an enforced contract neither drops columns silently nor lets the build pass with a warning.

dbt writes the Jinja-expanded SQL to target/compiled and the statement it executes to target/run, which is what the warehouse actually received. The raw model file still contains Jinja the warehouse never sees, and dbt_project.yml and the seeds folder do not store model SQL.

A missing node error is raised at compile time when a ref() name cannot be matched to any model or package node, usually because of a typo or a package that is not installed. The other options describe Database Errors or connection failures, which only occur once SQL reaches the warehouse.

A YAML parse problem, such as a wrong indent or a key in the wrong place, is reported with the file and line before dbt runs any SQL. A rotated password fails when dbt connects, a missing macro is a SQL compile error inside a model file, and --full-refresh only changes how incremental models build.

The --fail-fast flag (also -x) makes dbt stop after the first failure rather than continuing with independent nodes. --warn-error only changes how warnings are treated, --no-partial-parse forces a full parse, and --debug only increases log detail.

When a node fails in dbt build, dbt skips the descendants that depend on it, while parents that already completed are unaffected. Upstream sources are not skipped, schema membership does not decide skipping, and child models do not keep running when their parent fails.

dbt clone uses a state manifest to identify production relations and creates clones of them in the target schema, zero-copy where the platform supports it. A full refresh rebuilds tables from sources, seeds reload static CSV files, and snapshots record history instead of copying tables.

The threads setting in the target profile controls how many nodes dbt runs in parallel, as long as their upstream dependencies are complete. batch_size applies to microbatch models, full refresh changes what incremental models rebuild, and skipping tests does not add concurrency.

run_results.json records each node's status from the last invocation, and dbt ls with a graph operator lists a suspect model together with its upstream nodes. Deleting target does not rebuild the DAG from the catalog, lowering threads does not speed up reproduction, and dbt deps only installs packages.

The unique and not_null generic tests are built-in checks declared on a column in YAML, and they fail when duplicate or null values exist. Snapshots record history rather than validate keys, accepted_values cannot practically list every valid ID, and severity only changes how a failure is reported.

Singular tests are standalone SQL files whose returned rows count as failures, which suits rules spanning several columns or tables. A column-level YAML block describes a generic test, custom generic tests are macros, and tests run during dbt test or dbt build rather than during parse.

A custom generic test is a macro with a test block that accepts model and column arguments, so YAML can apply it to any column with a different threshold. Copied singular tests duplicate the logic, severity does not create a check, and exposures describe downstream uses rather than data rules.

Unit tests give a model fixed mock inputs and compare its result to an expected output, so the logic is checked without relying on warehouse data. Freshness checks measure load age, snapshots store history, and the singular test reads production tables, which the team wants to avoid.

An exposure is a YAML definition of a downstream use such as a dashboard, and its depends_on references place it in the lineage graph. Listing the dashboard as a source puts it upstream, a materialized view is a model rather than an exposure, and seeds hold static data rather than describe consumers.

Exposures document consumers such as dashboards, notebooks, and applications, and they appear in the DAG and docs without dbt building anything for them. They do not declare sources, dbt run does not execute them, and they are not freshness checks.

Source freshness uses loaded_at_field to measure the age of the latest load and applies the warn_after and error_after thresholds when dbt source freshness runs. A not_null test checks for empty values, materialization applies to models rather than sources, and a snapshot records history instead of measuring age.

Freshness compares the newest loaded_at_field value with the current time against the warn_after and error_after thresholds, and it runs through dbt source freshness rather than as part of dbt build. Row counting is not a freshness method, freshness results are reported by the source freshness command rather than as test failures, and no snapshot is required.

The state:modified+ selector picks the changed nodes and their downstream children, and --state gives dbt the earlier manifest to compare against. state:modified alone omits the children, a full refresh rebuilds everything, and result:error selects nodes that failed in the previous run.

State selectors compare the project being run with a previously saved manifest.json, supplied through --state, to find new, modified or unchanged nodes. Row counts, run results and git history are not what state:modified compares.

With --defer and a state manifest, dbt resolves references to nodes that were not built in the current run to their production relations, so only the changed mart is built in dev. Building every upstream model defeats the goal, hand-copied tables are error-prone, and dbt compile does not store results in the warehouse.

dbt retry uses the last invocation's results to rerun only the nodes that errored or were skipped. A full refresh rebuilds nodes that already succeeded, dbt deps only installs packages, and dbt compile does not execute models.