ARA-C01 Question 186
Single answerSnowflake CLIA data platform team is standardizing deployments of Snowflake objects across development, test, and production. They want developers to use Snowflake CLI from local workstations and CI/CD runners without hardcoding credentials in scripts. The team also wants each environment to be selectable at runtime from a configuration file so the same command can target different accounts, roles, warehouses, and databases. Which approach best meets these requirements?
- A
Create separate SQL files for each environment and embed the username and password directly in each file so Snowflake CLI can execute them without prompting.
- B
Define multiple named connections in the Snowflake CLI configuration file and invoke Snowflake CLI commands with the appropriate connection/profile for the target environment, using supported authentication methods instead of embedding credentials in scripts.
- C
Use a single shared connection for all environments and switch databases inside SQL scripts with USE statements, because Snowflake CLI cannot select different accounts or roles from configuration at runtime.
- D
Package all deployment logic into a stored procedure and call it from Snowflake CLI, because Snowflake CLI does not support environment-specific connection settings.
Show answer and explanation
Correct answer: B
Explanation
The best solution is to use multiple named connections in the Snowflake CLI configuration and select the appropriate one at execution time. This is the practical pattern for teams managing multiple Snowflake environments from developer machines and CI/CD systems. It keeps environment-specific connection details externalized, avoids insecure credential hardcoding in scripts, and allows consistent command usage across environments. In practice, architects should pair this with supported authentication approaches and secret-management practices in CI/CD pipelines. This aligns with Snowflake CLI usage patterns documented by Snowflake, where connections are centrally configured and commands can be run against a selected connection/profile rather than embedding account context and credentials into SQL artifacts.
- A. Incorrect.
This is incorrect because embedding usernames and passwords directly in SQL files or deployment scripts is not a recommended practice and does not meet the requirement to avoid hardcoded credentials. Snowflake CLI supports configuration-based connections and supported authentication mechanisms, which are better suited for secure local and CI/CD execution.
- B. Correct.
This is correct because Snowflake CLI supports defining named connections in its configuration and selecting the desired connection when running commands. This allows the same command pattern to target different environments while varying account, user, role, warehouse, database, and schema context through configuration. It also aligns with the requirement to avoid hardcoded credentials by using supported authentication methods and externalized connection settings.
- C. Incorrect.
This is incorrect because a single shared connection does not satisfy the requirement to target different environments cleanly, especially when accounts, roles, or other connection properties differ. Snowflake CLI is designed to work with multiple configured connections, so claiming it cannot select different accounts or roles from configuration is a misconception.
- D. Incorrect.
This is incorrect because while stored procedures can encapsulate deployment logic, they do not replace the need for environment-specific connection handling from the client side. Snowflake CLI does support environment-specific connection settings through configuration, so this option is based on a false limitation.