ARA-C01 Question 326
Single answerSnowflake CLIA platform team is standardizing how engineers deploy SQL scripts and Snowflake Native App artifacts from local workstations and CI runners. They want a solution that uses the Snowflake CLI, avoids storing passwords in plain text, supports non-interactive automation, and allows developers to switch between multiple Snowflake environments consistently. Which approach best meets these requirements?
- A
Configure named connections in the Snowflake CLI config file, use a secure authenticator such as key-pair authentication or OAuth for automation, and reference the target connection explicitly in CLI commands or project configuration.
- B
Store each environment's username and password directly in shell scripts and pass them to every Snowflake CLI command with command-line flags so CI jobs remain self-contained.
- C
Use a single shared Snowflake user for all developers and CI pipelines, then switch roles inside SQL scripts so the same Snowflake CLI connection can be reused everywhere.
- D
Rely on Snowsight worksheets for deployments and use the Snowflake CLI only for ad hoc local queries, because the CLI is not intended for environment-based automation.
Show answer and explanation
Correct answer: A
Explanation
The best answer is to use Snowflake CLI named connections combined with secure authentication methods appropriate for automation, such as key-pair authentication or OAuth, instead of embedding passwords. This gives the team a consistent way to target multiple Snowflake environments from developer machines and CI runners while preserving security and repeatability. In practice, architects should separate environment configuration from deployment logic, use explicit connection selection, and avoid shared identities and plain-text secrets. This aligns with Snowflake guidance around secure authentication, least privilege, and automation-friendly tooling in the Snowflake CLI.
- A. Correct.
Correct. The Snowflake CLI supports named connections so teams can define reusable environment-specific connection settings and consistently target dev, test, or prod. For secure non-interactive authentication, best practice is to use mechanisms such as key-pair authentication or OAuth rather than embedding passwords. This approach works well for both local development and CI/CD, and aligns with secure credential management and repeatable deployment patterns.
- B. Incorrect.
Incorrect. Passing usernames and passwords directly in shell scripts or as command-line arguments is not a recommended secure practice. It increases the risk of credential exposure through source control, process lists, logs, and CI job output. Although a team might consider this convenient for automation, it violates the requirement to avoid storing passwords in plain text.
- C. Incorrect.
Incorrect. Using a single shared Snowflake user for all humans and pipelines undermines auditability, accountability, and least-privilege design. Switching roles in SQL does not solve the identity and credential management problem. Snowflake best practices favor separate identities or service principals for automation and distinct user identities for developers, even when the Snowflake CLI is used consistently.
- D. Incorrect.
Incorrect. The Snowflake CLI is specifically designed to support command-line interaction and automation use cases, including working with projects and deployments. Snowsight is useful for interactive tasks, but saying the CLI is not intended for environment-based automation is factually wrong. This option ignores the requirement for standardized, non-interactive deployment workflows.