SnowPro Advanced: MLOps Engineer free question 8 / 10 · Domain 4: Pipeline Orchestration and Automation (CI/CD)
A GitHub Actions pipeline deploys ML pipeline code to Snowflake. Security wants no long-lived Snowflake credential stored anywhere in GitHub. What does the Snowflake CI/CD page recommend setting up?
- A password for a service user, kept in a GitHub secret and rotated often
- A service user with WORKLOAD_IDENTITY of TYPE = OIDC for the CI issuer
- The lead engineer's own user with MFA, approved at the start of each run
- A key pair for a service user, with the private key in a GitHub secret
Show the answer and explanation
Answer: B
Why this is correct
The section "Authenticate with workload identity federation (OIDC)" says that with OIDC the CI runner obtains a short-lived identity token that Snowflake validates directly. The common setup starts with a service user that the pipeline authenticates as, and for its authentication Snowflake recommends workload identity federation with OIDC so that no long-lived secrets are stored in the CI system. The minimal definition is CREATE USER with TYPE = SERVICE and WORKLOAD_IDENTITY = (TYPE = OIDC, ISSUER = ..., SUBJECT = ...), using the issuer and subject values that the CI platform documents.
Why the other options are wrong
"A key pair for a service user, with the private key in a GitHub secret" … A private key kept as a GitHub secret is a long-lived credential stored in the CI system, which is what security wants to avoid. The page's recommended setup is chosen so that no such secret has to be stored.
"A password for a service user, kept in a GitHub secret and rotated often" … The page says password authentication is supported for legacy workflows but is not recommended for production CI/CD. Rotation is its advice for teams that cannot adopt OIDC, and the password is still stored in GitHub.
"The lead engineer's own user with MFA, approved at the start of each run" … The common Snowflake-side setup starts by creating a service user that the pipeline authenticates as. A person's account with an interactive approval is not something an unattended pipeline can rely on.
Trust the runner, not a stored secret
The issuer and subject tie the Snowflake user to a particular CI identity, such as a repository or environment, so a token minted elsewhere does not match. The first-party GitHub Actions, GitLab and Azure DevOps integrations all list workload identity federation as their recommended authentication.