What you will be able to do
- Take a dbt project from source files to a deployed, executed and scheduled dbt project object
- Design a Snowflake CLI pipeline with validate, deploy and verify stages and secure authentication
- Choose between full-build and Slim CI validation for pull requests
- Separate dev and prod environments using profiles, env.yml, service users and per-PR databases
1.dbt Projects on Snowflake: from files to a deployed object
dbt Core is an open-source framework for defining, testing and deploying SQL transformations. dbt Projects on Snowflake runs that whole lifecycle inside Snowflake: develop, deploy, orchestrate and observe. You manage no infrastructure. Snowflake provides managed dbt Core and dbt Fusion runtimes, and you can pin a version or set an account-level default. You can develop in Snowflake Workspaces. Runs use a virtual warehouse at standard compute cost, with no extra licensing or per-user fees.
A valid project needs dbt_project.yml, a profiles file and model files, stored in a workspace or a connected Git repository. There are two possible profiles files, dbt_projects_profiles.yml and profiles.yml. If both are present, Snowflake uses dbt_projects_profiles.yml. From there the lifecycle has a fixed order. First run dbt deps to fill the dbt_packages folder. Then deploy a dbt project object with CREATE DBT PROJECT ... FROM <source> or snow dbt deploy. Run it with EXECUTE DBT PROJECT or snow dbt execute. Finally, schedule it with Snowflake tasks or Apache Airflow, so no external orchestrator is needed. The same deployed object can also run concurrently to keep separate data slices fresh.
Checkpoint 1 of 7· Put it in order
Put the dbt Projects on Snowflake lifecycle in order.
- 1.Run the object with EXECUTE DBT PROJECT or snow dbt execute
- 2.Run dbt deps to populate the dbt_packages folder
- 3.Deploy with CREATE DBT PROJECT ... FROM <source> or snow dbt deploy
- 4.Schedule runs with Snowflake tasks or Apache Airflow
Install dependencies before deploying, deploy before executing, and schedule only once the object exists.
“Deploy a dbt project object with CREATE DBT PROJECT ... FROM <source> or snow dbt deploy.”Source: docs.snowflake.com
You manage a deployed object from its details page in Snowsight. Open it from Transformations » dbt Projects, from Catalog » Explorer, or from Connect » View project in the workspace editor. The page always shows the currently deployed version. It includes an interactive DAG, model, source and test details with compiled SQL, column-level lineage, one-off or partial DAG runs, schedule management, and run history with logs and downloadable artifacts. Some of these features need the object to use the mutable live version.
Checkpoint 2 of 7· Exam question
A data scientist wants to connect an existing Snowflake Notebook to a GitHub repository so that saved changes can be pushed to the remote and teammates can pull the latest version. Before the notebook can sync, what must be true?
Correct answer: D — The notebook file must be saved as `.ipynb` at format version 4.0 or higher, with the repository connection set up from the Files tab.
- A. Converting a notebook into a stored procedure is unrelated to how Snowflake tracks notebook source; notebooks sync as files, not as compiled procedure objects.
- B. Git synchronization is a metadata and API-integration feature, not a compute-sizing requirement, so resizing the warehouse has no effect on whether syncing works.
- C. Git connectivity is established through an API integration scoped to the Git provider, not by disabling the role's network policy, which would weaken account security unnecessarily.
- D. Notebook files must be valid `.ipynb` content at format 4.0 or later, with the repository link created from the Files tab, which is the documented prerequisite for syncing.
2.Deployment pipelines with Snowflake CLI
Snowflake CLI is how code gets from a repository into Snowflake automatically. It can deploy DCM projects, Snowpark applications, Snowflake Native Apps, standalone SQL scripts and dbt project objects. Snowflake maintains first-party integrations that install the CLI on the runner and set up authentication. Any other CI system that can run a shell command can install the CLI directly.
| Integration | Status | Recommended authentication |
|---|---|---|
| GitHub Action | Generally available | Workload identity federation (OIDC) |
| GitLab CI/CD Component | Public preview | Workload identity federation (OIDC) |
| Azure DevOps Extension | Public preview | Workload identity federation (OIDC through Azure service connection) |
uv tool install snowflake-cli
snow --versionOn the Snowflake side, every integration follows the same pattern. Create a service user for the pipeline to authenticate as, configure how it authenticates, and grant it only the roles it needs. The recommended method is workload identity federation with OIDC. The runner gets a short-lived token that Snowflake validates, so the CI system stores no long-lived secret. If OIDC isn't available, use key pair authentication with the private key held as a CI secret. Password authentication still works for legacy workflows but is not recommended for production.
Checkpoint 3 of 7· Fill the gap
Complete the minimal service user definition for a CI pipeline using OIDC.
CREATE USER <username>
TYPE = ?
WORKLOAD_IDENTITY = (
TYPE = OIDC
ISSUER = '<ci-platform-issuer>'
SUBJECT = '<ci-platform-subject>'
);The pipeline authenticates as a service user, and its WORKLOAD_IDENTITY block uses the issuer and subject that your CI platform requires.
Source: docs.snowflake.comPipelines usually commit a config.toml and inject secrets as environment variables. Precedence works like this. Command-line parameters override everything. Next come connection-specific environment variables such as SNOWFLAKE_CONNECTIONS_MYCONNECTION_PASSWORD, then config.toml values. Generic variables such as SNOWFLAKE_USER apply last. The pipeline itself moves through three stages. Validate computes the changes without modifying anything. Deploy applies them after merge, using tools such as snow dcm deploy, snow sql -f <file>, snow snowpark deploy, or snow git execute to run SQL files from a Git integration. Verify confirms the result.
Checkpoint 4 of 7· Match them up
Match each pipeline stage to what it does.
Tap a term, then the definition that fits it.
The pull request is validated, the merge is deployed, and the result is verified. Only the syntax differs between CI platforms.
“A Snowflake CI/CD pipeline typically progresses through three stages: validate proposed changes on a pull request, deploy them on merge, and verify the result.”Source: docs.snowflake.com
Checkpoint 5 of 7· Exam question
An engineer needs to let Snowflake clone a private GitHub repository so that SQL scripts and Snowpark code can be executed straight from the repository stage. Which combination of objects must exist before the `CREATE GIT REPOSITORY` statement will succeed?
Correct answer: B — An API integration authorized for the Git provider's endpoint, plus a secret holding the credentials when the repository is private.
- A. A storage integration authorizes access to a cloud storage bucket for external stages; it has no role in authenticating a Git provider connection.
- B. Creating a Git repository object requires an API integration authorized for the provider's endpoint, plus a secret for credentials when the repository is private, which is exactly what the statement needs to succeed.
- C. Resource monitors cap warehouse credit consumption; Git fetch operations against a repository stage are not gated by a resource monitor.
- D. No such materialized view is required to create or query a repository stage; the stage is browsed with standard stage listing and Git commands instead.
Sources3
3.Testing and validation: full build versus Slim CI
For dbt projects, testing is built into the CI/CD flow. A developer changes models or tests on a branch and opens a pull request. CI then deploys a test instance of the dbt project object to the dev environment and runs it. If any operation fails, the pull request fails and the developer has to fix the code and rerun. Only a passing pull request can be merged. After the merge, CD updates the production dbt project object. The sources describe where these tests run in the pipeline. They do not cover dbt test syntax, apart from noting that CoCo can scaffold dbt data quality tests in schema.yml.
| Path | What runs | Trade-off |
|---|---|---|
| Full build | dbt build against an isolated dev target: every model and test | Thorough and simple, but costs grow with the project |
| Slim CI | Only state:modified+, with unchanged upstream references deferred to production | Faster and cheaper. State comes from the latest successful production run |
Slim CI relies on two native features. First, state is imported straight from a production dbt project object, so no separate artifact store is needed. Second, defer to production builds the changed models in an isolated CI target and resolves unchanged references to existing production relations. Outside dbt, the Snowflake CLI pipeline pattern has its own Verify stage, where snow dcm test runs expectation checks after a deployment.
Checkpoint 6 of 7· Check yourself
A large dbt project's PR validation is slow because every pull request rebuilds every model. Which change targets that cost directly?
Slim CI runs only changed models and their downstream dependencies and defers everything else to production. It imports state directly from the production object.
“Import state from the latest successful production execution, run and test only state:modified+, and defer unchanged upstream references to production.”Source: docs.snowflake.com
4.Managing dev, CI and prod environments
None of the earlier steps work unless environments are kept apart. Snowflake lists a split between a dev environment for CI and a prod environment for CD as a prerequisite, for example separate databases or schemas. In the repository, the dbt_projects_profiles.yml or profiles.yml file defines dev and prod targets such as databases, schemas and warehouse. dbt Projects on Snowflake adds a Git-versioned env.yml file that holds per-developer setups, production environment variables and secrets in one governed place. For stricter pull-request isolation, the Slim CI tutorial creates a zero-copy clone database for each pull request.
Credentials and access are managed per environment as well. Create a dedicated service user for each pipeline environment and grant it only the roles that pipeline needs. Restrict where it can authenticate from with network policies, and allow inbound access from your Git provider. Never commit a config.toml that contains credentials. Commit only the connection skeleton and supply secrets through environment variables. If you can't adopt OIDC, rotate keys and passwords on a schedule.
Checkpoint 7 of 7· Check yourself
Which practice matches Snowflake's guidance for CI/CD environment management?
Least-privilege service users per environment, secrets kept out of committed config, and separate dev and prod targets are the documented practices.
“Create a dedicated service user for each pipeline environment (for example, one user per repository or per environment).”Source: docs.snowflake.com
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.When a project contains both profiles.yml and dbt_projects_profiles.yml, Snowflake reads profiles.yml because it is the standard dbt file.Why is that wrong?
Snowflake gives priority to dbt_projects_profiles.yml when both files are present.
Covered in dbt Projects on Snowflake: from files to a deployed object
2.Storing a service user's password in CI secrets is the recommended way for a pipeline to authenticate to Snowflake.Why is that wrong?
Snowflake recommends workload identity federation with OIDC, which needs no long-lived secrets. Key pair is the fallback, and password authentication is for legacy use only.
Covered in Deployment pipelines with Snowflake CLI
3.Slim CI on Snowflake needs a separate artifact store to keep production manifest state between runs.Why is that wrong?
State is imported directly from the production dbt project object, so no separate artifact store is needed.
Covered in Testing and validation: full build versus Slim CI
Sources
Every claim above is drawn from one of these pages, quoted as it was written on the date shown.
- 1.
“Snowflake provides managed dbt Core and dbt Fusion runtimes. Pin a version or set an account-level default.”
↩︎ dbt Projects on Snowflake: from files to a deployed object“Your project needs a dbt_project.yml, a dbt_projects_profiles.yml or profiles.yml file, and model files, stored in a workspace or a connected Git repository.”
↩︎ dbt Projects on Snowflake: from files to a deployed object“Execute the object with EXECUTE DBT PROJECT or snow dbt execute.”
↩︎ dbt Projects on Snowflake: from files to a deployed object“Manage per-developer setups, production environment variables, and secrets in a single, Git-versioned env.yml file.”
↩︎ Managing dev, CI and prod environments“If both files are present, Snowflake uses dbt_projects_profiles.yml.”
↩︎ Exam trap 1“Import the latest successful state directly from a production dbt project object without managing a separate artifact store.”
↩︎ Exam trap 3“Deploy a dbt project object with CREATE DBT PROJECT ... FROM <source> or snow dbt deploy.”
↩︎ Checkpoint - 2.https://docs.snowflake.com/en/user-guide/data-engineering/dbt-projects-on-snowflake-manageOfficial docs
“It always reflects the currently deployed version of your project, so there’s no generated site to maintain.”
↩︎ dbt Projects on Snowflake: from files to a deployed object - 3.
“Snowflake recommends workload identity federation (WIF) with OpenID Connect (OIDC) so that no long-lived secrets are stored in the CI system.”
↩︎ Deployment pipelines with Snowflake CLI“Command-line parameters override everything.”
↩︎ Deployment pipelines with Snowflake CLI“Refreshes derived data and runs expectation checks to confirm the deployment produced the expected results.”
↩︎ Testing and validation: full build versus Slim CI“Commit only the connection skeleton and supply secrets through environment variables.”
↩︎ Managing dev, CI and prod environments“Password authentication is supported for legacy workflows but is not recommended for production CI/CD.”
↩︎ Exam trap 2“A Snowflake CI/CD pipeline typically progresses through three stages: validate proposed changes on a pull request, deploy them on merge, and verify the result.”
↩︎ Checkpoint“Create a dedicated service user for each pipeline environment (for example, one user per repository or per environment).”
↩︎ Checkpoint - 4.https://docs.snowflake.com/en/user-guide/data-engineering/dbt-projects-on-snowflake-ci-cdOfficial docs
“Continuous Integration (CI) runs your dbt project against a dev schema on each pull request.”
↩︎ Testing and validation: full build versus Slim CI“If an operation fails, the pull request fails.”
↩︎ Testing and validation: full build versus Slim CI“A separation between dev environment (for CI) and prod environment (for CD) in Snowflake (for example, separate databases or schemas for each environment).”
↩︎ Managing dev, CI and prod environments“Import state from the latest successful production execution, run and test only state:modified+, and defer unchanged upstream references to production.”
↩︎ Checkpoint