I85PREP
⌘ K
dbt Architect study materials
dbt Architect study resources

dbt Architect practice questions

One question at a time. Build your dbt Architect 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 1dbt project architecture and modeling

In a dbt project, which file is used to configure project-level settings such as the profile name, model paths, and global variables?

  1. profiles.yml
  2. packages.yml
  3. dbt_project.yml Correct answer.
  4. sources.yml

Explanation

dbt_project.yml is the project manifest that declares the project name, the profile to use, directory paths for models, seeds, snapshots, and macros, plus project-wide variables and configuration defaults. It is read from the project root and is required for dbt to run.

Question 2dbt project architecture and modeling

A dbt model file named stg_customers.sql is placed in the models/staging directory. What is the default materialization for this model when no configuration is applied?

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

Explanation

dbt's built-in default materialization is view, applied to any model that does not receive a configuration from the model file, a schema yml file, or dbt_project.yml. Directory placement alone does not change materialization.

Question 3dbt project architecture and modeling

Which dbt modeling layer typically contains business logic, joins, and transformations that are reused across multiple downstream marts?

  1. staging
  2. marts
  3. intermediate Correct answer.
  4. sources

Explanation

Intermediate models sit between staging and marts and hold reusable, more complex transformations such as joins and business logic that multiple marts share. Keeping this logic in one intermediate layer avoids duplication across marts.

Question 4dbt project architecture and modeling

In dbt, what does a source declaration in a yml file primarily accomplish?

  1. It registers raw tables as references that models can select from with the source() function. Correct answer.
  2. It creates the raw table in the warehouse.
  3. It schedules the raw table load from the upstream system.
  4. It automatically generates staging models for every raw table.

Explanation

A source declaration names a schema and its tables so that models can reference them via source('name','table') instead of hardcoding schema paths. This enables lineage tracking, freshness checks, and testing on raw data.

Question 5dbt project architecture and modeling

Which ref() behavior is correct when a model references another model that is configured as ephemeral?

  1. The ephemeral model is skipped and ref() resolves to the underlying source.
  2. The ephemeral model is built as a table and then dropped after the run.
  3. The ephemeral model's SQL is inlined as a common table expression inside the referencing model. Correct answer.
  4. The ephemeral model is built as a physical view in the warehouse.

Explanation

Ephemeral models are never materialized in the warehouse; dbt injects their compiled SQL as a CTE into each model that references them. This keeps intermediate logic reusable without creating physical objects.

Question 6dbt project architecture and modeling

A team wants every model in the models/marts directory to be built as a table without editing each model file. Where should this be configured?

  1. In each model's config() block individually
  2. In dbt_project.yml under the models key with a path-based configuration Correct answer.
  3. In the schema.yml of the marts directory
  4. In profiles.yml under the target output

Explanation

dbt_project.yml supports hierarchical model configuration keyed by directory, so a path entry can set materialized: table for all models beneath it. Model-level config() calls and schema yml settings override this default.

Question 7dbt project architecture and modeling

Which dbt feature lets you define a model once and parameterize its output across multiple environments or tenants using variables?

  1. exposures
  2. var() with CLI or dbt_project.yml values Correct answer.
  3. model contracts
  4. source freshness

Explanation

The var() function reads variables supplied on the command line or in dbt_project.yml, allowing one model definition to adapt to different values. This is the standard mechanism for parameterizing logic across environments or tenants.

Question 8dbt project architecture and modeling

In a dbt project, what is the primary purpose of a staging model?

  1. To store snapshot history of mutable source rows
  2. To perform one-to-one cleaning, renaming, and casting of a raw source Correct answer.
  3. To define reusable macros for the whole project
  4. To aggregate facts for executive dashboards

Explanation

Staging models map closely to a single source, applying consistent renaming, type casting, and light cleaning so downstream models consume a stable interface. They are the foundation of the layered modeling approach.

Question 9dbt project architecture and modeling

A developer wants a model to be rebuilt only when new rows arrive in the source, keeping existing rows intact. Which materialization and configuration best fits this requirement?

  1. ephemeral inlined into a downstream model
  2. table rebuilt on every run
  3. incremental with a unique_key and an is_incremental() filter Correct answer.
  4. view with a filter on created_at

Explanation

Incremental models insert or merge only new or changed rows on subsequent runs, using unique_key to identify matches and an is_incremental() block to apply the filter only after the first build. This avoids full rebuilds and preserves history.

Question 10dbt project architecture and modeling

In an incremental model, why is the is_incremental() macro used inside the model SQL?

  1. To decide whether to use a view or table materialization
  2. To check whether the source table has new partitions
  3. To detect whether the target table already exists and this is not a full-refresh run, so the filter applies only then Correct answer.
  4. To verify that the model's tests have passed

Explanation

is_incremental() returns true only when the target relation exists and the run is not a full refresh, so the WHERE clause on the watermark is applied on incremental runs but not on the initial build. This prevents the first build from filtering out all historical rows.

Question 11dbt project architecture and modeling

Which configuration correctly restricts an incremental model to merge new rows based on a surrogate key column named order_id?

  1. materialized='incremental', unique_key='order_id' Correct answer.
  2. materialized='incremental', strategy='append'
  3. materialized='view', unique_key='order_id'
  4. materialized='table', unique_key='order_id'

Explanation

Setting materialized to incremental and providing unique_key tells dbt to match incoming rows to existing rows on that key, which produces a merge or delete-insert depending on the adapter. The unique_key must identify a single row per key for correct results.

Question 12dbt project architecture and modeling

A team defines a dbt model in the marts layer that joins three staging models. Which practice best supports maintainability according to dbt modeling conventions?

  1. Embed the join logic in each downstream mart to keep models independent
  2. Join directly to raw source tables to reduce the number of models
  3. Use source() for staging models to skip the ref dependency graph
  4. Reference staging models with ref() rather than hardcoding schema and table names Correct answer.

Explanation

Using ref() to reference upstream models lets dbt build the dependency DAG, resolve environment-specific schemas, and order runs correctly. Hardcoding names breaks lineage and portability across environments.

Question 13dbt project architecture and modeling

Which dbt construct is designed to capture changes to a mutable source table over time by recording valid_from and valid_to style history?

  1. An exposure
  2. A seed file
  3. A dbt snapshot Correct answer.
  4. A model contract

Explanation

Snapshots detect changes in source rows and write new records with timestamp or check columns so that historical states are preserved. This produces slowly changing dimension style history that models can join against.

Question 14dbt project architecture and modeling

A project needs to enforce that a model's output has specific column names and data types, failing the build if they change. Which dbt feature should be used?

  1. Model contracts Correct answer.
  2. Source freshness
  3. Tags
  4. Exposures

Explanation

Model contracts declare the expected columns and data types for a model, and dbt validates the compiled output against them at build time. This protects downstream consumers from unintended schema changes.

Question 15dbt project architecture and modeling

Which selection syntax runs a model named fct_orders plus all of its upstream dependencies?

  1. dbt run --select @fct_orders
  2. dbt run --select +fct_orders Correct answer.
  3. dbt run --select fct_orders
  4. dbt run --select fct_orders+

Explanation

A leading plus sign selects the named node and everything upstream of it, so +fct_orders builds all ancestors before the model itself. A trailing plus instead selects downstream descendants.

Question 16dbt project architecture and modeling

A team wants models tagged as 'finance' to be excluded from a nightly run while everything else builds. Which command accomplishes this?

  1. dbt run --exclude tag:finance Correct answer.
  2. dbt run --select tag:finance+
  3. dbt run --exclude tag:finance+
  4. dbt run --select tag:finance

Explanation

The --exclude flag removes matching nodes from the selected set, so --exclude tag:finance builds all models except those tagged finance. Combining --select and --exclude lets you define a broad set and carve out exceptions.

Question 17dbt project architecture and modeling

Which statement about dbt seeds is accurate?

  1. Seeds automatically infer and enforce primary keys
  2. Seeds are compiled SQL models that run before sources are declared
  3. Seeds are the recommended way to load large transactional extracts
  4. Seeds are CSV files loaded into the warehouse and are best suited to small, static reference data Correct answer.

Explanation

Seeds are version-controlled CSV files that dbt loads as tables, making them useful for small lookup data such as country codes or mappings. They are not intended for large or frequently changing datasets.

Question 18dbt project architecture and modeling

A model depends on a source table declared as source('raw','orders'). How should the model reference that table to preserve lineage and schema resolution?

  1. SELECT * FROM raw.orders
  2. SELECT * FROM {{ ref('orders') }}
  3. SELECT * FROM {{ var('orders') }}
  4. SELECT * FROM {{ source('raw','orders') }} Correct answer.

Explanation

The source() function resolves the declared source to the correct database and schema for the active target while recording lineage in the DAG. Hardcoding the schema breaks portability across environments.

Question 19dbt project architecture and modeling

In a layered dbt project, why should staging models avoid joins to other staging models?

  1. Joins in staging always cause circular dependencies
  2. Staging models should map one-to-one to a source so they remain simple, testable, and independently reusable Correct answer.
  3. Staging models cannot reference other models with ref()
  4. Joins are not supported in the staging layer by dbt

Explanation

Keeping staging models as a one-to-one cleaned view of a single source makes them easy to test for uniqueness and referential integrity and safe to reuse. Combining sources is the job of intermediate or mart models.

Question 20dbt project architecture and modeling

A developer adds a schema.yml test that asserts uniqueness on a column, but the build fails. What does this most likely indicate about the model's data?

  1. The model is materialized as a view rather than a table
  2. The column contains duplicate values that violate the uniqueness assumption Correct answer.
  3. The model has not been assigned a tag
  4. The column is missing a description in schema.yml

Explanation

A uniqueness test fails when more than one row shares the same value in the tested column, revealing duplicates or a grain problem. The fix is usually to correct the model's grain or adjust the test to match the true key.

Question 21dbt project architecture and modeling

Which situation best justifies introducing an intermediate model instead of expanding a mart model?

  1. A model needs to be excluded from a nightly run
  2. A source table has been renamed in the warehouse
  3. The mart model needs a column alias changed
  4. The same multi-table join and business logic are needed by three separate mart models Correct answer.

Explanation

When identical complex logic is required by several downstream marts, extracting it into an intermediate model centralizes the definition and prevents divergence. Single-use logic or simple renames do not warrant a new layer.

Question 22dbt project architecture and modeling

An incremental model uses unique_key='id' but occasionally produces duplicate rows after several runs. Which cause is most consistent with this symptom?

  1. The is_incremental() filter is present in the model
  2. The unique_key column is an integer type
  3. The source contains multiple rows per id and the model does not deduplicate before the merge Correct answer.
  4. The model is configured with materialized='incremental'

Explanation

If the incoming batch has more than one row per unique_key value, the merge cannot match cleanly and duplicates can accumulate. Deduplicating to one row per key before the merge, often with row_number, resolves the issue.

Question 23dbt project architecture and modeling

A project sets materialized: table for the marts directory in dbt_project.yml, but a single model in that directory defines config(materialized='view'). What is the resulting materialization for that model?

  1. view, because dbt_project.yml settings are ignored for marts
  2. table, because conflicting configs cause a build error
  3. table, because dbt_project.yml overrides model configs
  4. view, because the model-level config takes precedence Correct answer.

Explanation

dbt applies configuration with increasing specificity, and a config() call inside the model file overrides directory-level defaults from dbt_project.yml. Conflicting values do not raise errors; the most specific setting wins.

Question 24dbt project architecture and modeling

A team wants to guarantee that a fact model is only built after its staging dependencies succeed, while also allowing independent parallel builds where no dependency exists. Which dbt mechanism provides this behavior?

  1. Configuring every model as ephemeral
  2. The dependency graph built from ref() and source() calls, which dbt uses to order execution Correct answer.
  3. Placing all models in a single SQL file separated by comments
  4. Manually ordering models by renaming files with numeric prefixes

Explanation

dbt constructs a DAG from ref() and source() references and uses it to schedule builds, running independent branches concurrently and respecting dependencies. File naming conventions do not influence execution order.

Question 25dbt project architecture and modeling

A snapshot is configured with a timestamp strategy using updated_at. What condition causes dbt to write a new historical record for a row?

  1. The updated_at value in the source is later than the stored dbt_valid_from for that key Correct answer.
  2. The source table gains a new column
  3. The row's primary key changes between runs
  4. The snapshot table is rebuilt with a full refresh

Explanation

With the timestamp strategy, dbt compares the incoming updated_at to the currently valid record and closes the old record while inserting a new one when the timestamp advances. This captures each change as a new historical version.

Question 26dbt project architecture and modeling

A dbt project has a single model named `fct_orders` that many downstream marts depend on. Which dbt feature lets the team document that model's purpose, owner, and column-level meaning in a way that surfaces in the generated docs site?

  1. A `properties.yml` file placed next to the model containing a `models:` block with `description` and a `columns:` list Correct answer.
  2. A `-- docs` flag passed to `dbt run` that generates descriptions from SQL comments
  3. A `macros/` file that wraps the model SQL and returns a description string
  4. An `exposures:` block in `dbt_project.yml` that maps each column to its consumers

Explanation

Model and column descriptions are declared in YAML properties files (conventionally named `schema.yml` or any `.yml` file under the models path) using a `models:` block with `description` and a nested `columns:` list. `dbt docs generate` reads those files to build the documentation site. SQL comments and dbt_project.yml are not the mechanism for per-column documentation.

Question 27dbt project architecture and modeling

A dbt project needs a reusable set of column transformations applied identically in five mart models. The team wants the logic defined once, version-controlled, and callable from each model. Which project structure element is intended for this?

  1. An exposure declared in a properties file
  2. A macro in the `macros/` directory invoked with Jinja in each model Correct answer.
  3. A singular test file in the `tests/` directory
  4. A seed CSV loaded into the warehouse and joined by each mart

Explanation

Macros are Jinja functions stored under `macros/` and are the standard way to define reusable SQL logic invoked from multiple models. Seeds load static data, tests assert conditions, and exposures describe downstream usage, so none of them share transformation logic across models.

Question 28dbt project architecture and modeling

A dbt project stores its models in `models/staging`, `models/intermediate`, and `models/marts`. Which directory layout convention best supports clear dependency direction between these layers?

  1. Staging models read sources and intermediate models, while marts read sources directly for performance
  2. Marts read sources, intermediate models read marts, and staging models read intermediate
  3. All three layers read from sources so each model is independently testable
  4. Staging models read sources only, intermediate models read staging, and marts read staging or intermediate Correct answer.

Explanation

The layered convention is that staging models select from declared sources with light renaming and typing, intermediate models combine or reshape staging models, and marts consume staging or intermediate models. This keeps dependencies flowing in one direction and avoids marts reaching around the layered logic.

Question 29dbt project architecture and modeling

A dbt project defines many sources in a single YAML file. A developer wants `dbt source freshness` to check only the sources belonging to the `raw` source. Which approach accomplishes this?

  1. Add `freshness: enabled` to each model in the `raw` schema
  2. Run `dbt source freshness --select source:raw` to target that source Correct answer.
  3. Set `materialized: source` on the models that read from `raw`
  4. Create a separate dbt project containing only the `raw` sources

Explanation

The `--select` flag accepts the `source:` method, so `dbt source freshness --select source:raw` limits the freshness check to that named source. Freshness is configured on the source definition, not on models, and materializations do not apply to sources.

Question 30dbt project architecture and modeling

A team wants a mart model to be rebuilt as a view in development but as a table in production, without duplicating the model file. Which configuration approach achieves this?

  1. Define the materialization only in `dbt_project.yml` and never override it at the model level
  2. Hard-code `materialized='table'` in the model and override it with a `--full-refresh` flag in development
  3. Create two model files with identical SQL and enable one per environment using `enabled`
  4. Use a Jinja conditional on `target.name` in the model's config block to set the materialization per environment Correct answer.

Explanation

The `target.name` value reflects the active profile target, so a config block can branch on it to choose a different materialization per environment while keeping one model file. Duplicating files or relying on `--full-refresh` does not change the materialization itself.

Question 31dbt project architecture and modeling

A dbt project sets `+materialized: view` for the `models/staging` directory in `dbt_project.yml`, but one staging model must be a table. Where should the override be placed?

  1. In a `sources:` block in a properties YAML file
  2. In a `config()` block at the top of that model's SQL file Correct answer.
  3. In the `profiles.yml` file under the target definition
  4. In the `packages.yml` file alongside the package version

Explanation

Model-level `config()` blocks take precedence over directory-level defaults set in `dbt_project.yml`, so the override belongs in the model file itself. Profiles, sources, and packages files do not control model materialization.

Question 32dbt project architecture and modeling

A team wants a model to run only when invoked explicitly and never as part of a broad `dbt run` that selects its parent directories. Which configuration accomplishes this?

  1. Place the model in a directory with no `+materialized` setting
  2. Set `materialized: ephemeral` so the model is never executed in the warehouse
  3. Add a `tags: ['manual']` entry and rely on the default selector to exclude it
  4. Set `enabled: false` in the model's config so it is excluded from all runs Correct answer.

Explanation

Setting `enabled: false` removes the model from the project graph so it is not built by ordinary selection, and it can be re-enabled when needed. Tags only matter when a selector references them, ephemeral models still compile into dependent models, and directory placement alone does not exclude a model.

Question 33dbt project architecture and modeling

A dbt project declares `sources` for a raw schema. A developer references the table as `{{ source('raw','orders') }}` in one model and as a hard-coded `raw.orders` in another. Which consequence follows from the hard-coded reference?

  1. dbt automatically rewrites the hard-coded name to the declared source during compilation
  2. dbt cannot resolve the dependency, so lineage and source freshness do not cover that model Correct answer.
  3. dbt raises a compilation error because source tables must always be referenced with `source()`
  4. dbt records lineage for the hard-coded table but marks the source as stale

Explanation

Only `source()` calls create graph edges to declared sources, so a hard-coded table name is invisible to dbt lineage and source freshness. Compilation still succeeds because the SQL is valid, but the model loses dependency tracking and freshness coverage.

Question 34dbt project architecture and modeling

A dbt project has a model that unions ten staging models, each with identical column names and types. Where should the union logic live to keep the marts layer readable?

  1. In an intermediate model that unions the staging models, consumed by the mart Correct answer.
  2. In each staging model, appending the other nine staging models' rows
  3. In the `dbt_project.yml` file as a `+union` configuration key
  4. In a singular test that asserts the staging models have matching schemas

Explanation

Combining multiple staging models is the classic role of an intermediate model, which keeps the union out of the mart and out of the staging layer. Staging models should remain one-to-one with sources, and configuration files cannot express row-level union logic.

Question 35dbt project architecture and modeling

A developer wants to add a column to a mart model only when the target is production, keeping the development output narrower. Which technique fits the dbt project architecture?

  1. Use a `--vars` flag to pass the column name at runtime
  2. Add the column unconditionally and drop it with a post-hook in development
  3. Create a separate production-only project that shares the same models directory
  4. Wrap the column in a Jinja `{% if target.name == 'prod' %}` block inside the model SQL Correct answer.

Explanation

Conditional Jinja on `target.name` is the standard way to vary model SQL by environment within a single project. Post-hooks that drop columns leave schema drift and extra compute, a second project duplicates configuration, and vars would still require the conditional logic to consume them.

Question 36dbt project architecture and modeling

A dbt project uses `dbt_utils` and a custom internal package. A developer wants to pin the internal package to a specific git tag while allowing the public package to float on a version range. Which `packages.yml` structure supports this?

  1. A `packages:` entry with `local:` paths for both packages
  2. A single `packages:` entry listing both packages with one shared `version` field
  3. A `dependencies:` block in `dbt_project.yml` listing both packages
  4. Two `packages:` entries, one with `git:` and `revision:` for the tag, and one with `package:` and `version:` for the range Correct answer.

Explanation

`packages.yml` accepts a list of entries, each with its own install method, so a git package can be pinned with `revision:` while a hub package uses a `version:` range. There is no shared version field across entries, and package installation is not configured in `dbt_project.yml`.

Question 37dbt project architecture and modeling

A team wants a model's compiled SQL to be available for reuse by other models without creating a relation in the warehouse. Which materialization should be used, and what is the trade-off?

  1. `table`, because it persists results for downstream joins
  2. `incremental`, because it appends rows and avoids full rebuilds
  3. `view`, because it stores no data and can be selected from like a table
  4. `ephemeral`, because it is inlined as a CTE, at the cost of recompiling its logic in every downstream model Correct answer.

Explanation

Ephemeral models are not built as relations; their SQL is injected as a CTE into each downstream model, which avoids warehouse objects but repeats the logic and compute in every consumer. Views, incremental models, and tables all create relations in the warehouse.

Question 38dbt project architecture and modeling

A dbt project has grown to hundreds of models, and a nightly job must build only marts tagged `daily` plus everything they depend on. Which selector expression is correct?

  1. `dbt run --select tag:daily+`
  2. `dbt run --select +tag:daily` Correct answer.
  3. `dbt run --select @tag:daily`
  4. `dbt run --select tag:daily-`

Explanation

The leading `+` selects the tagged nodes plus all their ancestors, which is the set of upstream dependencies the marts need. A trailing `+` selects descendants, and `@` selects ancestors plus the direct children of those ancestors, which is a wider set than requested.

Question 39dbt project architecture and modeling

A dbt project uses `dbt build`, which runs tests interleaved with model builds. A model's upstream source test fails. What happens to the model that depends on that source?

  1. The model is skipped because its upstream test failed, and downstream nodes are also skipped Correct answer.
  2. The model is built and the failing test is reported at the end of the run
  3. The model is built with a warning and marked as failed in the run results
  4. The model is rebuilt twice, once before and once after the test is re-run

Explanation

`dbt build` runs tests and models in dependency order, and when a test on an upstream node fails, dependent nodes are skipped rather than built on unvalidated data. This fail-fast behavior is a key reason to use `dbt build` in CI and production jobs.

Question 40dbt project architecture and modeling

A dbt project uses a snapshot with the `check` strategy on a source table that has no reliable `updated_at` column. A developer notices duplicate history rows for unchanged records across consecutive snapshot runs. Which explanation is most consistent with the `check` strategy?

  1. The `check` strategy always writes a new row on every run regardless of column values
  2. The `check` strategy compares only the `dbt_updated_at` column, which changes on every run
  3. The `check` strategy requires a `unique_key` and ignores `check_cols` entirely
  4. The `check` strategy compares the listed `check_cols` and writes a new row whenever any checked column differs, so non-deterministic or frequently changing columns cause extra history Correct answer.

Explanation

With `check_cols`, dbt inserts a new historical row whenever any of the listed columns differs from the most recent stored version, so volatile or non-deterministic columns produce spurious history. Choosing stable columns or switching to the `timestamp` strategy with a reliable column avoids this.

Question 41Data platform and environment design

In a dbt project, which directory is the default location for model SQL files that define the project's core transformations?

  1. analyses/
  2. models/ Correct answer.
  3. snapshots/
  4. macros/

Explanation

dbt discovers model files under the configured model-paths, which default to models/. Snapshots, macros, and analyses each have their own separate default directories, so transformation logic intended as a model belongs in models/.

Question 42Data platform and environment design

A team wants a single dbt project to build against both a Snowflake production warehouse and a Snowflake staging warehouse without editing files between runs. Which mechanism should drive the target selection?

  1. Adding an env_var call inside every model's SQL body
  2. Creating a separate profile target for each warehouse and selecting it with --target Correct answer.
  3. Duplicating the entire project into two repositories
  4. Hardcoding the database name in each model

Explanation

dbt profiles can define multiple targets per output, and the target is selected at runtime via --target or the DBT_TARGET environment variable. This keeps one codebase while routing builds to different warehouses. Hardcoding or duplicating projects breaks portability.

Question 43Data platform and environment design

What is the primary purpose of the profiles.yml file in a dbt deployment?

  1. To declare model dependencies and ref relationships
  2. To define test severity thresholds for the project
  3. To store warehouse connection credentials and target settings Correct answer.
  4. To list which packages to install from the hub

Explanation

profiles.yml holds the connection details (account, credentials, schema, threads) for each target dbt uses to reach the warehouse. It is normally kept outside the project repository or supplied via environment variables to avoid committing secrets.

Question 44Data platform and environment design

Which dbt artifact captures the compiled SQL, configuration, and metadata for every node executed in a run, and is commonly parsed by orchestrators to trigger downstream tasks?

  1. sources.json
  2. manifest.json
  3. run_results.json Correct answer.
  4. catalog.json

Explanation

run_results.json records per-node execution status, timing, and adapter responses from the most recent command, making it the usual artifact for orchestration decisions. manifest.json describes the project graph rather than a run's outcomes.

Question 45Data platform and environment design

A dbt project must run transformations in a schema named after the developer who is working locally, while production uses a fixed schema. Which built-in variable is designed for this per-environment schema naming?

  1. target.schema Correct answer.
  2. this.name
  3. target.name
  4. env_var('DBT_USER')

Explanation

target.schema resolves to the schema configured for the active target in profiles.yml, so a developer profile can set a personal schema while production sets a fixed one. target.name is the target label, not the schema.

Question 46Data platform and environment design

Which dbt feature lets you define a model once but materialize it differently in development versus production without changing the model file?

  1. Source freshness thresholds
  2. Model contracts
  3. Config blocks combined with target-based conditional logic Correct answer.
  4. Exposures

Explanation

A config block can branch on target.name, for example materializing as a view in dev and a table in prod. This keeps one model definition while varying materialization per environment. Source freshness, exposures, and contracts serve unrelated purposes.

Question 47Data platform and environment design

When dbt builds a model, what does the ref function primarily accomplish beyond string substitution of a table name?

  1. It compiles the referenced model's SQL into the current model
  2. It caches the referenced table in memory for the session
  3. It registers a dependency edge in the DAG so build order is correct Correct answer.
  4. It creates a foreign key constraint in the warehouse

Explanation

ref resolves the correct relation name for the target environment and records a dependency so dbt orders builds topologically. Without that edge, downstream models could run before their inputs exist. It does not compile other models inline or alter warehouse constraints.

Question 48Data platform and environment design

A team wants to reuse a common set of column-level tests across many models without copying YAML into every properties file. Which approach best fits dbt's design?

  1. Write a singular test per model in the tests/ directory
  2. Define a generic test in the tests/ or macros/ directory and reference it by name with arguments Correct answer.
  3. Enable the built-in audit helper for every model
  4. Paste the test block into each model's YAML file

Explanation

Generic tests are parameterized macros that can be applied by name to many columns or models, avoiding duplication. Singular tests are one-off SQL files and would still require per-model files, and there is no built-in audit helper that applies automatically.

Question 49Data platform and environment design

Which configuration controls how many models dbt runs in parallel against the warehouse during a build?

  1. materialized in the model config
  2. severity in the test config
  3. full_refresh in the run command
  4. threads in the target definition Correct answer.

Explanation

The threads setting in profiles.yml determines the size of the connection pool and therefore the degree of parallelism dbt uses when building independent nodes. Materialized, full_refresh, and severity govern other behaviors.

Question 50Data platform and environment design

A project stores raw ingestion tables in a schema loaded by an EL tool. Which dbt construct should declare those tables so tests, lineage, and freshness checks can reference them?

  1. Exposures pointing at the raw schema
  2. Seeds loaded with dbt seed
  3. Sources defined in a YAML file with database and schema properties Correct answer.
  4. Ephemeral models that select from the raw tables

Explanation

Sources declare externally loaded tables with their database and schema, enabling lineage, source freshness, and source-based tests. Ephemeral models would wrap rather than declare the raw tables, and seeds are for CSV data dbt loads itself.