ARA-C01 Question 327
Single answerSnowflake CLIA data platform team is standardizing how developers deploy Snowflake objects from local workstations and CI pipelines. They want to use Snowflake CLI so that developers can keep connection definitions in a local configuration file, switch between environments such as DEV and PROD, and execute SQL deployments non-interactively in automation. The security team also requires avoiding hard-coded passwords in deployment commands whenever possible. Which approach best meets these requirements?
- A
Define named connections in the Snowflake CLI configuration file, reference the target connection when running CLI commands, and use a non-interactive authenticator supported by the environment instead of embedding passwords directly in command arguments.
- B
Store SQL deployment scripts inside a Snowflake internal stage and use Snowflake CLI only to download them locally before manually executing each file in Snowsight for each environment.
- C
Create a separate Snowflake account for each environment and rely on the CLI default connection only, because Snowflake CLI does not support multiple named connections in configuration.
- D
Pass the username, password, role, warehouse, database, and schema as command-line arguments in every CI job, because Snowflake CLI requires full connection details on each execution and does not support reusable connection profiles.
Show answer and explanation
Correct answer: A
Explanation
The best answer is to use Snowflake CLI named connections in the CLI configuration and invoke commands against the appropriate connection for each environment. This matches real-world deployment patterns where architects need consistent environment targeting across developer laptops and CI/CD systems. From a security perspective, avoiding hard-coded passwords in command lines is a best practice; automation should use a supported non-interactive authentication mechanism such as key-pair authentication where appropriate. Snowflake CLI is designed to let users define and reuse connection profiles rather than re-specifying credentials and session context on every command. This makes deployments more maintainable, less error-prone, and more secure.
- A. Correct.
Correct. Snowflake CLI supports reusable named connections in its configuration, allowing teams to define environment-specific connection profiles and select them when executing commands. This is well aligned with local development and CI/CD patterns. Using a supported non-interactive authentication method, such as key-pair authentication, is preferable to hard-coding passwords in command lines because it reduces credential exposure and supports automation more securely.
- B. Incorrect.
Incorrect. While scripts can be stored in stages for some workflows, this does not address the stated need to standardize environment-specific CLI connections and non-interactive automated execution. Requiring manual execution in Snowsight also conflicts with the goal of automation in CI pipelines.
- C. Incorrect.
Incorrect. Snowflake CLI does support multiple named connections in its configuration, so forcing a single default connection is unnecessary and operationally limiting. Also, separate Snowflake accounts may be used for environment isolation in some organizations, but that is not required by the scenario and does not solve the connection-management requirement by itself.
- D. Incorrect.
Incorrect. Snowflake CLI does not require all connection properties to be passed on every command invocation. Reusable connection definitions are specifically intended to avoid repetitive parameters and reduce the risk of exposing secrets. Passing passwords directly as command-line arguments is generally a poor security practice because they may be exposed in shell history, process listings, or CI logs.