Free dbt Architect Certification Exam practice test: 30 questions with answers

Warehouses that restrict inbound addresses must allow the egress IPs dbt Cloud uses, so adding them keeps the restriction in place while letting dbt connect. Turning the policy off removes a security control, a role grant does not get around network-level checks, and a region change does not alter the source addresses dbt Cloud uses.

OAuth delegates sign-in to the warehouse's identity provider, so each user's queries run under their own grants and appear in the warehouse audit trail. A shared password, a token committed to a repository, or trusting an IP address does not tie access to an individual identity.

The connection test checks credentials and reachability directly, which is the quickest and safest check. A scheduled production run delays the answer and can touch live data, an email confirmation does not test the network path, and a full build is far heavier than a connection check.

dbt Cloud keeps development credentials, which each user supplies for their own sessions, separate from the deployment credentials that scheduled jobs use. The other options either share one identity everywhere or make production depend on personal accounts, which weakens auditing and access control.

Native integrations let the git provider notify dbt Cloud of pull request events, which enables automatic CI, and let job status be reported back to the pull request. The other two statements describe things dbt Cloud does not do with the git provider or the warehouse.

A deploy key is scoped to a single repository and can be limited to read access, which is enough for cloning. A personal key ties the connection to one person, a shared password is an unnecessary exposure, and a public repository exposes source code to everyone.

dbt Cloud checks out the code when a run starts and builds from that snapshot, so a later push does not change the run in progress. The other options describe re-reading the branch mid-run, reusing an earlier run's code, or switching to the default branch, none of which happen.

Building only the changed models against production state validates a change cheaply, and requiring passing CI as a merge condition stops broken models from reaching main. Merging before checks finish and building in the production schema both undermine that safety.

Registering the new public key before switching lets both keys work during the overlap, so jobs keep authenticating while the credential in dbt Cloud is updated and the old key is removed afterward. Stopping jobs causes avoidable downtime, while emailing or committing a private key exposes the credential.

Environments can be configured with a custom branch, which tells dbt Cloud which branch that environment builds from without changing the repository layout. Renaming the release branch to main would disrupt the team's workflow, a second project is unnecessary, and dbt_project.yml does not choose which git branch an environment checks out.

Environment variables are set per environment in dbt Cloud and read with the env_var() function, so one codebase adapts to each environment. Hardcoded copies, per-environment branches, and duplicated projects all create drift and extra maintenance.

Deferral tells dbt to resolve references to unbuilt models against the production environment, so CI builds only what changed. A full build repeats work unnecessarily, copying the production schema is slow and costly, and hardcoding table names bypasses ref() and breaks lineage.

Commands in a job run one after another, and a failed command ends the run, so the later test command does not execute. The other options describe independent execution, parallel runs, or an automatic retry, none of which happen within a single job run.

Job chaining starts a downstream job when an upstream job completes, so the dependency follows actual completion rather than a guessed clock time. A fixed offset can start too early or too late, manual runs depend on someone remembering, and polling every minute wastes runs.

Generating docs during a run produces the catalog artifacts that dbt Cloud uses to show descriptions, columns, and lineage, so they reflect the latest build. The other options describe results storage, schema locking, or file compression, none of which this setting does.

Self-deferral points unchanged references at the last successful run of the same job, which suits a CI loop that keeps its own baseline. Deferral to production uses a different baseline, a full build ignores the baseline entirely, and a manual schema copy is slow and error-prone.

Service tokens carry only the permission sets assigned to them, and regular rotation with revocation limits the damage from a leaked credential. A shared document and reuse of an administrator's personal token both widen exposure and tie automation to one person.

Permission sets define what a user can do, so a read-only set matches the need without granting edit or run rights. Administrator access exceeds the requirement, a shared login removes individual accountability, and a write-enabled service token gives more power than the contractor needs.

License mappings take the group information the identity provider sends during SSO and assign the matching dbt license, so assignments follow group membership. Manual changes do not scale, service tokens do not act as user licenses, and outbound webhooks send notifications rather than change account settings.

SSO hands authentication to the identity provider, and group-based role mapping lets access follow directory membership, which keeps onboarding and offboarding in one place. The other options keep local passwords, require manual per-project grants, or store role data in the warehouse, which is not how dbt Cloud access works.

Failure notifications on the production job push the event to the people who must act as soon as the run fails. Running more often does not make the failure visible, a morning check is manual and late, and removing tests hides the problem instead of detecting it.

Outbound webhooks send event payloads from dbt Cloud to a URL the team controls, which lets the incident tool react to run events. dbt Cloud does not poll external endpoints for tickets, a test table is an indirect and fragile route, and an environment only defines where models are built.

Scoping failure alerts to production jobs that need action cuts the noise and keeps each alert meaningful, while development results stay visible in the UI. A weekly review, muted shared channels, and day-long delays all let production problems go unnoticed for too long.

Job notifications can be set for success as well as failure, so the owners hear when the report's inputs are ready. Adding email steps to every model is unnecessary, manual log checks arrive too late, and turning off failure alerts removes the signal that matters most.

Private models are limited to their own group, protected is the default and allows references within the project, and public models are the ones other projects can reference. Private models are not open to other projects and public models are meant to be discoverable, so the last two statements are false.

A two-argument ref names the project and the model, which is how dbt resolves a public model from another project. A source reference points at raw tables rather than dbt models, a one-argument ref searches only the current project, and this refers to the current model's own relation.

A model contract declares the expected column names and data types, and dbt checks the model against that definition at build time so drift causes a failure. An exposure documents a downstream use without enforcing anything, a singular test checks data rather than schema shape, and a snapshot records history.

Lineage in dbt Catalog traces the dependency graph from a node to its downstream models and exposures, which is what impact analysis requires. Run history records what executed, query history shows warehouse activity rather than model dependencies, and environment variables do not describe relationships between models.

The logs and compiled SQL from the failed run show the error message and the exact statement the warehouse rejected, which is the starting point for a fix. Descriptions, edit history, and old row counts do not explain why the most recent execution failed.

Incremental models process only new or changed rows on each run, which suits append-heavy data that rarely changes. A view pushes the cost to every read, an ephemeral model only inlines SQL without reducing the work, and a full nightly rebuild repeats the same work.