Snowflake CLI Pipelines and Native Promotion of ML Assets

1.Authenticating a CI runner with a service user

Snowflake CLI is the automation layer for CI/CD. It can deploy DCM projects, Snowpark applications, Native Apps and standalone SQL scripts. Snowflake maintains first-party integrations that install the CLI on the runner and configure authentication. On any other CI system (Jenkins, Bitbucket Pipelines, CircleCI), you install it with a shell command.

Every integration follows the same pattern on the Snowflake side. You create a service user for the pipeline, configure how it authenticates, and grant it only the roles it needs. With OIDC, the runner gets a short-lived identity token that Snowflake validates directly, so the CI system stores no long-lived secret. The ISSUER and SUBJECT values depend on the CI platform.

CREATE USER <username>
  TYPE = SERVICE
  WORKLOAD_IDENTITY = (
    TYPE =  ? 
    ISSUER = '<ci-platform-issuer>'
    SUBJECT = '<ci-platform-subject>'
  );

If OIDC isn't available, use key pair authentication. Store the private key as a CI secret and pass it in through SNOWFLAKE_PRIVATE_KEY_RAW or SNOWFLAKE_CONNECTIONS_<NAME>_PRIVATE_KEY_RAW. Password authentication still works for legacy workflows but is not recommended for production CI/CD.

Sources1

2.Connection precedence and project-definition variables

A typical pipeline commits a config.toml that contains only the connection skeleton and injects secrets through environment variables. When the same setting is supplied in more than one place, these rules decide which value wins:

Values that change between environments, such as the target database or role, go in the env section of the project definition file, snowflake.yml. Commands then refer to them with <% ctx.env.name %>. A shell environment variable with the same case-sensitive name overrides the file's default, so one project definition can serve dev, staging and prod. For example, export database="other" overrides the database value.

definition_version: 2
env:
  database: "dev"
  role: "eng_rl"

snow sql -q "grant usage on database <% ctx.env.database %> to <% ctx.env.role %>"

Sources12

3.Validate, deploy, verify

With authentication and configuration in place, a Snowflake pipeline usually runs three stages. On a pull request it validates, computing the changes without applying them and posting them for reviewers. On merge to main it deploys. Afterwards it verifies, running expectation checks. The pattern is the same on every CI platform. The CLI goes onto the runner with a single install line:

uv tool install snowflake-cli

snow --version

Sources1

4.Promoting ML assets: DCM projects and model versions

Snowflake has two native ways to move ML assets toward production.

For objects such as the tables, schemas and roles behind a feature pipeline, DCM projects are declarative. Definition files state the target state, usually in Git, and Snowflake works out the changes needed to reach it. A DCM project is a schema-level object, and you need one for each target environment. It stores the immutable artifacts of every deployment it runs. PLAN previews the changes and DEPLOY applies them. This also takes care of object dependencies: the order and location of DEFINE statements don't matter, because Snowflake sorts them before applying changes.

For models, promotion happens in the Model Registry. Models are versioned, and one version is the default. The simplest scheme treats the default version as production, so promoting a version means setting it as the default. A version can also carry an alias, and the system alias DEFAULT always refers to the default version. Both are set with ALTER MODEL:

ALTER MODEL [ IF EXISTS ] <name> SET
  [ COMMENT = '<string_literal>' ]
  [ DEFAULT_VERSION = '<version_name>']

ALTER MODEL [ IF EXISTS ] <model_name> SET TAG <tag_name> = '<tag_value>'

ALTER MODEL [ IF EXISTS ] <model_name> UNSET TAG <tag_name> [ , <tag_name> ... ]

ALTER MODEL [ IF EXISTS ] <model_name> VERSION <version_name> SET ALIAS = <alias_name>

ALTER MODEL [ IF EXISTS ] <model_name> VERSION <version_or_alias_name> UNSET ALIAS

Sources34

Exam traps

Each one states something that sounds right. Open it to see what is actually true.

1. 1.DEFINE statements in a DCM project must be ordered so that dependencies are created first.Why is that wrong?

   Snowflake collects and sorts all DEFINE statements before applying them, so file order and placement don't affect the result.

   Covered in Promoting ML assets: DCM projects and model versions

2. 2.Storing a service user's password or private key as a CI secret is the recommended way to authenticate GitHub Actions.Why is that wrong?

   The recommendation is workload identity federation with OIDC, which uses short-lived tokens. Long-lived credentials are the fallback.

   Covered in Authenticating a CI runner with a service user

3. 3.A committed config.toml should hold the full connection, including credentials, so every runner works the same way.Why is that wrong?

   Commit only the connection skeleton and supply secrets through environment variables.

   Covered in Connection precedence and project-definition variables