I85PREP
⌘ K
dbt Analytics Engineering study materials
dbt Analytics Engineering study resources

dbt Analytics Engineering practice questions

One question at a time. Build your dbt Analytics Engineering understanding.

First 50 of 200 questions. Each one lists the choices, the correct answer, and an explanation. The checker at the top of this page saves progress in this browser when it is available.

Continue in the practice tool above to load more questions, 50 at a time.

Question 1Data Modeling and Transformation with dbt

In a dbt project, which configuration key in dbt_project.yml sets the default materialization for every model in the project?

  1. model-defaults:\n materialization: view
  2. dbt_project:\n default_materialization: view
  3. models:\n my_project:\n materialized: view
  4. models:\n my_project:\n +materialized: view Correct answer.

Explanation

Model configurations in dbt_project.yml are nested under the models: key and prefixed with a plus sign, so +materialized: view applies the materialization to all models in the named project path. The plus prefix is what marks a key as a configuration rather than a folder path.

Question 2Data Modeling and Transformation with dbt

A model is materialized as a view. What does dbt create in the warehouse when the model is built?

  1. A snapshot table that tracks column history
  2. A physical table whose rows are stored on disk
  3. A database view containing the model's compiled SELECT statement Correct answer.
  4. An incremental table with a merge key

Explanation

The view materialization wraps the model's compiled SQL in a CREATE VIEW statement, so the warehouse stores only the query definition and evaluates it at read time. No rows are persisted, which is why views stay cheap to rebuild but can be slow to query.

Question 3Data Modeling and Transformation with dbt

Which ref() call correctly references a model named stg_orders from another model in the same dbt project?

  1. {{ ref('models', 'stg_orders') }}
  2. {{ ref('stg_orders') }} Correct answer.
  3. {{ var('stg_orders') }}
  4. {{ source('stg_orders') }}

Explanation

ref() takes the model name as its argument and resolves it to the correct relation while recording a dependency edge in the DAG. That dependency is what lets dbt order builds correctly and select downstream models.

Question 4Data Modeling and Transformation with dbt

What is the primary purpose of a dbt source definition in a YAML file?

  1. To copy raw tables into the analytics schema
  2. To schedule the warehouse's native load jobs
  3. To declare and document raw tables that dbt does not build, enabling source() references and freshness checks Correct answer.
  4. To generate surrogate keys for staging models

Explanation

Sources describe tables loaded by an external tool so models can reference them with source() instead of hard-coded relation names. Declaring them also unlocks source freshness checks and lineage visibility for raw data.

Question 5Data Modeling and Transformation with dbt

In a dbt model, what does the Jinja expression {{ this }} resolve to when the model is compiled?

  1. The name of the currently running dbt command
  2. The current relation for the model being compiled, such as database.schema.model_name Correct answer.
  3. The path to the model's SQL file on disk
  4. The target profile's connection credentials

Explanation

this is a Relation object representing the model's own target relation, including database, schema, and identifier. It is essential in incremental models, where the compiled query must reference the existing table.

Question 6Data Modeling and Transformation with dbt

Which dbt test would best verify that every order_id value in a model is unique?

  1. A relationships test from order_id to a parent model
  2. A unique test on order_id Correct answer.
  3. A not_null test on order_id
  4. An accepted_values test on order_id

Explanation

The built-in unique test asserts that no value appears more than once in the column, which is exactly the uniqueness requirement for a key. Combining it with not_null is common practice for primary keys.

Question 7Data Modeling and Transformation with dbt

What file extension and location does dbt expect for a model's SQL definition by default?

  1. A .yml file inside the models directory
  2. A .sql file inside the analyses directory
  3. A .py file inside the macros directory
  4. A .sql file inside the models directory Correct answer.

Explanation

Models are .sql files placed anywhere under the models path configured in dbt_project.yml. The file name becomes the model name unless an alias overrides it.

Question 8Data Modeling and Transformation with dbt

A staging model should rename a raw column customer_id to customer_key. Where does the alias belong in the model's SQL?

  1. In the SELECT list of the final CTE, as customer_id AS customer_key Correct answer.
  2. In the FROM clause of the source CTE
  3. In the schema.yml description field
  4. In the WHERE clause of the final CTE

Explanation

Column renaming happens in a SELECT list using the AS keyword, and staging models conventionally perform this in the final CTE so earlier CTEs keep the raw names. Descriptions in YAML document columns but never change their names.

Question 9Data Modeling and Transformation with dbt

A model uses the incremental materialization with a filter such as {% if is_incremental() %} WHERE updated_at > (SELECT MAX(updated_at) FROM {{ this }}) {% endif %}. What happens on the first run?

  1. The filter block is skipped, so the full query runs and the table is created Correct answer.
  2. The filter is applied against an empty relation and returns no rows
  3. dbt creates an empty table and waits for the next run to load data
  4. dbt raises an error because {{ this }} does not exist yet

Explanation

is_incremental() returns false when the target relation does not exist or is not configured as incremental, so the first run executes the full unfiltered query. Subsequent runs see the existing table and apply the filter to load only new rows.

Question 10Data Modeling and Transformation with dbt

Which statement about dbt's default schema naming for a model is correct?

  1. dbt requires an explicit schema for every model in its YAML properties
  2. Models are created in a schema named after the folder depth
  3. Every model is created in the target profile's schema unless a custom schema is configured Correct answer.
  4. Each model automatically receives its own schema named after the model

Explanation

By default all models land in the schema defined by the active target, and dbt appends any custom schema to that base schema using the generate_schema_name macro. Custom schemas are opt-in through config or properties.

Question 11Data Modeling and Transformation with dbt

A developer wants one model to expose a column named order_total while the underlying SQL selects total_amount. Which configuration achieves this without editing the SQL?

  1. Set alias: order_total on the column in the model's properties YAML Correct answer.
  2. Set rename: order_total on the model in dbt_project.yml
  3. Add a column_types entry mapping total_amount to order_total
  4. Use a persist_docs setting for the column

Explanation

The alias property on a column in the properties YAML changes the column name in the built relation without touching the model SQL. It is applied by dbt when the relation is created.

Question 12Data Modeling and Transformation with dbt

Which scenario is the strongest justification for choosing the table materialization over a view?

  1. The model performs expensive joins and aggregations and is queried frequently by BI tools Correct answer.
  2. The model must avoid storing any data in the warehouse
  3. The model is a thin rename-and-cast layer over a single source
  4. The model is queried rarely and must always reflect the latest raw data instantly

Explanation

Tables pay a build-time cost to persist results, which pays off when the transformation is expensive and the output is queried often. Views defer compute to query time, which hurts repeated expensive reads.

Question 13Data Modeling and Transformation with dbt

A dbt run fails with a Database Error about a column that does not exist in a model that references an upstream model. What is the most likely root cause?

  1. The upstream model was changed and the downstream model still references the old column name Correct answer.
  2. The downstream model's materialization is set to view
  3. The project lacks a packages.yml file
  4. The downstream model's schema.yml is missing a description

Explanation

dbt compiles models against the current warehouse state, so renaming or dropping a column upstream breaks any downstream SQL that still selects the old name. The fix is to update the downstream reference or restore the column.

Question 14Data Modeling and Transformation with dbt

What is the effect of setting enabled: false in a model's config block?

  1. The model is built only in the production target
  2. The model is built but skipped during tests
  3. The model is moved to the analyses directory automatically
  4. The model is excluded from the DAG and is not built or tested by dbt Correct answer.

Explanation

Disabling a model removes it from the project graph, so dbt neither runs nor tests it. Downstream models that ref() it will also fail to resolve unless they are updated.

Question 15Data Modeling and Transformation with dbt

Which dbt feature lets you define a reusable, parameterized SQL snippet that models call like a function?

  1. A seed CSV file
  2. An exposure defined in YAML
  3. A macro defined in the macros directory Correct answer.
  4. A source freshness block

Explanation

Macros are Jinja functions stored in the macros directory and invoked with {{ macro_name(args) }}, which makes them ideal for repeated logic such as currency conversion or surrogate key generation.

Question 16Data Modeling and Transformation with dbt

A model needs to reference a raw table that is loaded into the warehouse by an EL tool but should not be built by dbt. Which approach is correct?

  1. Use ref() with the fully qualified table name
  2. Create a model that selects from the raw table with no transformation
  3. Add the table to seeds and run dbt seed
  4. Declare the table under sources in a YAML file and reference it with source() Correct answer.

Explanation

Declaring the table as a source documents it, enables freshness checks, and lets models reference it with source('source_name', 'table_name') without dbt trying to build it. This keeps raw and modeled layers clearly separated.

Question 17Data Modeling and Transformation with dbt

Which test configuration correctly applies a relationships test that verifies every customer_id in orders exists in the customers model?

  1. columns: [customer_id] with tests: [relationships: {to: ref('customers'), field: customer_id}] Correct answer.
  2. columns: [customer_id] with tests: [accepted_values: {values: [customers]}]
  3. columns: [customer_id] with tests: [unique]
  4. columns: [customer_id] with tests: [not_null]

Explanation

The relationships test requires a to argument naming the parent relation and a field argument naming the parent column. This asserts referential integrity between the child and parent keys.

Question 18Data Modeling and Transformation with dbt

A team wants each model's build to run in a schema named after its layer, such as staging or marts, while keeping the target schema as a prefix in development. Which mechanism should they customize?

  1. The profiles.yml threads setting
  2. The generate_schema_name macro Correct answer.
  3. The packages.yml dependency list
  4. The dbt_project.yml name field

Explanation

dbt resolves schemas through the generate_schema_name macro, so overriding it lets a project control how custom schema names combine with the target schema. This is how teams keep developer-specific prefixes while still separating layers.

Question 19Data Modeling and Transformation with dbt

What does the dbt build command do that dbt run does not?

  1. It only compiles SQL without executing it
  2. It uploads artifacts to the dbt Cloud API
  3. It drops all existing relations before rebuilding
  4. It runs models, tests, seeds, and snapshots together in DAG order Correct answer.

Explanation

dbt build interleaves models, tests, seeds, and snapshots in dependency order, so a failing test can block downstream models in the same invocation. dbt run executes only models.

Question 20Data Modeling and Transformation with dbt

A model must produce one row per customer with the most recent order date. Which SQL pattern inside a dbt model is the most reliable approach?

  1. Use SELECT DISTINCT on customer_id and order_date
  2. Use a CROSS JOIN between customers and orders
  3. Select all orders and deduplicate later in the BI layer
  4. Use a window function such as ROW_NUMBER() partitioned by customer ordered by order_date descending, then filter to row 1 Correct answer.

Explanation

ROW_NUMBER() with a descending date ordering and a filter on row number 1 deterministically selects the latest order per customer. Deduplicating downstream pushes correctness into the BI layer and risks inconsistent results.

Question 21Data Modeling and Transformation with dbt

An incremental model uses the append strategy but source records can be updated after insertion. What is the consequence?

  1. Updated records appear twice, because append inserts new rows without replacing existing ones Correct answer.
  2. dbt automatically converts append to merge when duplicates are detected
  3. The updated records overwrite the originals in place
  4. The model fails because append requires a unique_key

Explanation

The append strategy simply inserts filtered rows, so a later update to an existing record creates a second row rather than replacing the first. Models that must reflect updates need merge or delete+insert with a unique_key.

Question 22Data Modeling and Transformation with dbt

A project defines a custom schema for a model via config(schema='marts') while the target schema is analytics. Assuming the default generate_schema_name macro, where is the model created?

  1. marts
  2. analytics_marts Correct answer.
  3. analytics
  4. marts_analytics

Explanation

The default macro concatenates the target schema and the custom schema with an underscore, producing analytics_marts. Teams override the macro when they want the custom schema alone.

Question 23Data Modeling and Transformation with dbt

A dbt test on a large fact model is slow because the relationships test scans the entire table on every run. Which approach best preserves correctness while reducing cost?

  1. Change the test to not_null on the foreign key
  2. Remove the test and rely on manual spot checks
  3. Disable the test in production and enable it only in development
  4. Configure the test with a where clause that limits rows to a recent date window Correct answer.

Explanation

Adding a where argument restricts the rows the test evaluates, which keeps the referential integrity check meaningful for recent data at lower cost. The trade-off is that older rows are no longer continuously validated.

Question 24Data Modeling and Transformation with dbt

A model references {{ ref('stg_orders') }} inside a Jinja for loop that builds a UNION ALL across three upstream models. What dependency does dbt record for the current model?

  1. A dependency only on the model named in the first iteration
  2. No dependency, because ref() inside a loop is not tracked
  3. A dependency on each model passed to ref() during rendering Correct answer.
  4. Only the last ref() evaluated during rendering

Explanation

dbt captures every ref() call made while rendering the model, so a loop that calls ref() three times records three dependency edges. This ensures the model builds only after all referenced upstream models exist.

Question 25Data Modeling and Transformation with dbt

A team wants a model to be rebuilt as a table in production but as a view in development to save cost. Which configuration pattern is appropriate?

  1. Use a conditional such as materialized: '{{ "table" if target.name == "prod" else "view" }}' in the model config Correct answer.
  2. Hard-code materialized: table in the model and edit it before each environment switch
  3. Create two separate models with identical SQL and enable one per environment
  4. Set the materialization in profiles.yml under the target

Explanation

Target-aware configuration lets a single model choose its materialization based on target.name, which dbt evaluates at compile time. This avoids duplicated SQL while matching cost and performance needs per environment.

Question 26Data Modeling and Transformation with dbt

In dbt, which materialization persists a model's query result as a physical table in the warehouse and rebuilds it from scratch on each run?

  1. ephemeral
  2. table Correct answer.
  3. view
  4. incremental

Explanation

The table materialization issues a create-table-as-select each time the model runs, so the full result set is recomputed and stored physically. This is why it is the default choice for marts that are queried frequently and are cheap enough to rebuild.

Question 27Data Modeling and Transformation with dbt

A dbt model file must satisfy which condition for dbt to build it as a model?

  1. It must include a primary key column named id
  2. It contains a single SELECT statement or a WITH clause ending in SELECT Correct answer.
  3. It must begin with a {{ config() }} block
  4. It contains only DDL such as CREATE TABLE or ALTER TABLE

Explanation

dbt wraps a model's SQL in the DDL needed for the chosen materialization, so the file itself must be a query that returns rows, typically a SELECT or a WITH ending in SELECT. Statements that create or alter objects directly conflict with dbt's generated DDL.

Question 28Data Modeling and Transformation with dbt

Which statement best describes the purpose of a dbt source definition in a sources YAML file?

  1. It replaces ref() for all upstream models in the project
  2. It declares raw warehouse tables loaded outside dbt so they can be referenced with source() and tested Correct answer.
  3. It copies raw tables into the dbt project directory for version control
  4. It creates the raw tables automatically during dbt run

Explanation

Sources give dbt a name for tables that dbt does not build, enabling source() references, freshness checks, and tests. They document lineage from ingestion to the models that consume the raw data.

Question 29Data Modeling and Transformation with dbt

A model's YAML declares a column test of not_null on order_id. What does dbt do when the test finds rows with a null order_id?

  1. The test is skipped because not_null only applies to sources
  2. The test automatically deletes the null rows from the model
  3. The test passes but logs a warning without failing the run
  4. The test fails and reports the offending rows, and dbt build marks the run as errored Correct answer.

Explanation

A singular or generic data test fails when its query returns any rows, and dbt surfaces those rows for debugging. Under dbt build, a failing test marks the run as failed and can block downstream models depending on severity.

Question 30Data Modeling and Transformation with dbt

What is the role of the profiles.yml file in a dbt project?

  1. It defines the project's package dependencies
  2. It holds the SQL macros shared across models
  3. It lists every model and its description for documentation
  4. It stores connection credentials and target settings that dbt uses to reach the warehouse Correct answer.

Explanation

profiles.yml maps a profile name to outputs, each with a target type, credentials, and schema, and the active target selects which output is used. It is kept outside the project repository because it contains secrets.

Question 31Data Modeling and Transformation with dbt

In a dbt model, what does the ref() function return when the model is compiled?

  1. The number of rows the referenced model last produced
  2. The fully qualified relation name of the referenced model for the active target Correct answer.
  3. The path to the referenced model on disk
  4. The raw SQL text of the referenced model's file

Explanation

ref() resolves to the database, schema, and identifier of the referenced model so that the correct environment's relation is used. It also registers the dependency so dbt builds models in the right order.

Question 32Data Modeling and Transformation with dbt

Which dbt command compiles the project and writes the resulting SQL to the target directory without executing anything in the warehouse?

  1. dbt build
  2. dbt run
  3. dbt compile Correct answer.
  4. dbt seed

Explanation

dbt compile renders Jinja and resolves ref() and source() calls, producing runnable SQL in the target directory for inspection. It performs no warehouse writes, which makes it useful for debugging generated SQL.

Question 33Data Modeling and Transformation with dbt

Which dbt feature records the history of how a mutable source table's rows changed over time by capturing new and changed records on each run?

  1. exposures
  2. snapshots Correct answer.
  3. seeds
  4. analyses

Explanation

Snapshots compare the current state of a source with the previously captured state and insert new rows with dbt_valid_from and dbt_valid_to timestamps. This preserves slowly changing dimension history that the source overwrites in place.

Question 34Data Modeling and Transformation with dbt

A staging model must trim whitespace and lowercase the value of a raw column named email. Where should that transformation be expressed?

  1. In the sources YAML as a column-level transformation property
  2. In the downstream mart model only, leaving staging as a pure passthrough
  3. In the SELECT list of the staging model, aliased to a clean column name Correct answer.
  4. In profiles.yml as a target setting

Explanation

Staging models are the conventional place for light, one-to-one cleaning such as trimming and case normalization, expressed in the SELECT list with a clear alias. Sources YAML holds metadata and tests, not transformation logic.

Question 35Data Modeling and Transformation with dbt

A model needs to branch on the value of a project variable supplied at runtime with --vars. Which Jinja construct reads that variable?

  1. target.name
  2. env_var('my_var')
  3. var('my_var') Correct answer.
  4. this.name

Explanation

The var() function retrieves a project variable, optionally with a default, and respects values passed via --vars at runtime. It is the standard way to parameterize model logic per invocation.

Question 36Data Modeling and Transformation with dbt

A developer writes a macro that generates a CASE expression and wants to call it inside a model. What is the correct invocation syntax in the model's SQL?

  1. [[ my_macro('column_name') ]]
  2. ${ my_macro('column_name') }
  3. {{ my_macro('column_name') }} Correct answer.
  4. {% my_macro('column_name') %}

Explanation

Macros are called with the Jinja expression delimiters {{ }}, which output the rendered SQL into the model. Statement delimiters {% %} are for control flow such as if and for, not for emitting a return value.

Question 37Data Modeling and Transformation with dbt

A team wants a model to be built only when explicitly selected, never as part of a plain dbt run. Which configuration achieves this?

  1. config(enabled=false) combined with a separate always-enabled wrapper model Correct answer.
  2. config(materialized='ephemeral')
  3. config(alias='disabled_model')
  4. config(tags=['manual'])

Explanation

Setting enabled to false removes the model from the DAG so a plain dbt run skips it, and selection cannot build a disabled node. To build it on demand, teams keep the logic in a macro or an always-enabled model gated by a variable.

Question 38Data Modeling and Transformation with dbt

Which configuration correctly limits how many rows dbt samples for a column's data profiling in dbt docs?

  1. Set materialized='sample' on the model
  2. Set full_refresh=true in profiles.yml
  3. Add a limit clause to the model SQL
  4. Set the column's meta property and configure sampling in the project's dbt_project.yml Correct answer.

Explanation

dbt controls documentation sampling through project-level configuration rather than model SQL, so the setting belongs in dbt_project.yml or related config. Materializations and query limits do not govern docs sampling.

Question 39Data Modeling and Transformation with dbt

A model uses config(materialized='incremental', unique_key='id') and the adapter supports merge. What happens to a source row whose id already exists in the target table but whose other columns changed?

  1. The entire target table is rebuilt from scratch
  2. The existing row is updated with the new column values Correct answer.
  3. The row is ignored because the id already exists
  4. A duplicate row with the same id is inserted

Explanation

With a unique_key and a merge-capable adapter, dbt matches incoming rows to existing rows and updates the matched records. Unmatched rows are inserted, so the target converges on the latest source state without duplicates.

Question 40Data Modeling and Transformation with dbt

A developer wants to apply the same column-level tests to dozens of models that share a naming convention. Which dbt mechanism is designed for this?

  1. A pre-hook on each model
  2. A source freshness check
  3. A singular test written once in the tests directory
  4. A generic test defined in the macros directory and applied via YAML Correct answer.

Explanation

Generic tests are parameterized macros that can be attached to many columns or models through YAML, optionally with arguments. This avoids duplicating near-identical SQL across models.

Question 41Data Modeling and Transformation with dbt

Which dbt artifact lets a BI tool or orchestrator read the project's model dependency graph after a run?

  1. manifest.json in the target directory Correct answer.
  2. packages.yml in the project root
  3. profiles.yml in the user's home directory
  4. dbt_project.yml at the project root

Explanation

dbt writes manifest.json, along with run_results.json and catalog.json, into the target directory as machine-readable artifacts. The manifest contains the full DAG, node metadata, and compiled code used by integrations.

Question 42Data Modeling and Transformation with dbt

A model joins orders to customers and the result contains duplicate order_id values because a customer has multiple active records. Which modeling approach most directly resolves the fan-out?

  1. Switch the model to the view materialization
  2. Add DISTINCT to the final SELECT of the joined model
  3. Deduplicate the customer dimension to one row per customer before the join Correct answer.
  4. Add a not_null test on order_id

Explanation

Fan-out occurs because the dimension side of the join is not unique on the join key, so reducing it to one row per key before joining fixes the grain. DISTINCT on the result hides the problem and can still drop legitimately repeated rows.

Question 43Data Modeling and Transformation with dbt

A model must apply different WHERE clauses depending on whether the target is development or production. Which approach keeps the logic inside the model?

  1. Use source freshness thresholds to control the filter
  2. Create two separate projects with duplicated SQL
  3. Use a Jinja if block on target.name to conditionally include the filter Correct answer.
  4. Set enabled=false for the development target

Explanation

target.name exposes the active target so a Jinja conditional can add or omit a filter per environment while keeping one model definition. This is a common pattern for limiting data volume in development.

Question 44Data Modeling and Transformation with dbt

A dbt project has a model that selects from a seed file of country codes. What must be true for the model to reference the seed with ref()?

  1. The seed must be declared in sources YAML
  2. The seed CSV must exist in the seeds directory with a matching name and be loaded by dbt seed or dbt build Correct answer.
  3. The seed must be registered in profiles.yml
  4. The seed must be materialized as ephemeral

Explanation

Seeds are CSV files in the seeds directory that dbt loads as tables, and ref() resolves them by file name once loaded. They are part of the project DAG and can be tested like models.

Question 45Data Modeling and Transformation with dbt

A developer needs every model in the marts folder to default to the table materialization while a single model overrides it to view. Which configuration placement achieves this?

  1. Set materialized: table under the marts path in dbt_project.yml and config(materialized='view') in the one model Correct answer.
  2. Set materialized: view in dbt_project.yml and materialized: table in the one model
  3. Set the materialization in packages.yml
  4. Set the materialization only in profiles.yml

Explanation

Project-level configuration in dbt_project.yml applies defaults by directory, and an in-model config() block takes precedence for that model. This layered precedence lets a folder default be overridden locally.

Question 46Data Modeling and Transformation with dbt

An incremental model filters on updated_at > (SELECT MAX(updated_at) FROM this) and a late-arriving row has an updated_at earlier than the current maximum. What is the outcome?

  1. The late row triggers an automatic full refresh
  2. The late row is never processed and is silently missing from the model Correct answer.
  3. The late row is routed to a separate archive table
  4. The late row is merged because unique_key is set

Explanation

A high-water-mark filter only selects rows newer than the stored maximum, so rows arriving with older timestamps fall outside the window and are skipped. Teams address this with a lookback window or by keying on an ingestion timestamp.

Question 47Data Modeling and Transformation with dbt

A team wants tests on a critical model to warn without failing the pipeline, while tests on a payment model must halt the run. Which configuration accomplishes this?

  1. Set limit: 10 on the payment model's tests
  2. Set store_failures: true on the critical model's tests
  3. Set enabled: false on the payment model's tests
  4. Set severity: warn on the critical model's tests and severity: error on the payment model's tests Correct answer.

Explanation

Test severity controls whether a failure is treated as a warning or an error, so warn lets the run continue while error stops it. Severity can be set per test in YAML or in the generic test's config.

Question 48Data Modeling and Transformation with dbt

A model's SQL references {{ ref('stg_payments') }} inside a Jinja for loop that unions three payment methods. What does dbt do with the dependency graph when the model is parsed?

  1. It records no dependency because ref() is inside a loop
  2. It fails to parse because ref() cannot appear inside a loop
  3. It records a single dependency on stg_payments and builds that model first Correct answer.
  4. It records three separate dependencies, one per loop iteration

Explanation

dbt statically parses ref() calls during compilation, so a ref() inside a loop still registers one edge to the referenced model. The DAG reflects the dependency and ensures stg_payments builds before the union model.

Question 49Data Modeling and Transformation with dbt

A snapshot of a customers table uses the timestamp strategy with updated_at as the key. A source row's updated_at is corrected to an earlier value than previously recorded. What risk does this create for the snapshot?

  1. The change may not be captured because the timestamp moved backward relative to the stored history Correct answer.
  2. The snapshot will automatically delete the prior version row
  3. The snapshot will switch to the check strategy
  4. The snapshot will fail because timestamps must be unique

Explanation

The timestamp strategy compares updated_at against the last recorded values, so a backward correction can fall outside the comparison and be missed. This is why monotonic timestamps or the check strategy are preferred when source timestamps can move backward.

Question 50Data Modeling and Transformation with dbt

A mart model aggregates orders to one row per customer per month. Which test most directly guards the model's declared grain?

  1. A not_null test on customer_id
  2. A dbt_utils.unique_combination_of_columns test on customer_id and order_month Correct answer.
  3. An accepted_values test on order_month
  4. A relationships test from orders to customers

Explanation

The grain is the combination of customer_id and order_month, so a uniqueness test across both columns verifies one row per combination. Single-column tests cannot detect duplicates that differ only in the other key column.