dbt Analytics Engineering Certification: Managing dbt Model Governance Practice Questions

dbt supports ref('model_name', v=3) (and the longer keyword version=3) to pin to a specific version. Referencing dim_products_v3 as a bare name is incorrect: the node's name is dim_products, with version as separate metadata — dbt would not resolve it. The version argument does not have to be a quoted string; it matches the v value declared in YAML, which is commonly numeric. The @ syntax does not exist in dbt.

Cross-project references require both that the producer marks the model access: public (protected and private models are not visible outside the project) and that the consumer project declares the producer as a dependency so dbt can resolve ref('project_name', 'model_name'). Versions are optional — a public model may be unversioned. Group ownership metadata is good practice and required if the model is in a group, but a public model does not have to be in a group. Materialization is irrelevant to access; a view can be public.

An unpinned ref() to a versioned model resolves to latest_version — here, v2. Listing order in YAML is irrelevant. dbt explicitly supports unpinned refs (they are how consumers 'float' to the newest version), so it is not an error. Resolution is determined at parse time from the YAML, not from build recency.

On most cloud warehouses, not_null and column data types are actually enforced by the database at build time — a violating row or mismatched cast fails the build. Snowflake, by contrast, accepts primary_key, unique, and foreign_key constraints as metadata only; they are not enforced, so a duplicate key will still load successfully. That is why dbt docs recommend pairing contracts with data tests for uniqueness and referential integrity.

private restricts ref() to models that are members of the same group, which is exactly the requirement for intermediate models owned by a single team. protected would allow any model in the project to reference it, which is broader than required. public would additionally expose it to downstream projects. group_only is not a valid dbt access value — the only valid values are private, protected, and public.