ARA-C01 Question 185
Single answerSnowflake CLIA data platform team is standardizing how developers deploy SQL scripts and manage Snowflake objects from local workstations and CI/CD runners. They want to use Snowflake CLI so that deployments can run non-interactively in pipelines, while individual developers can still authenticate securely from their laptops. The architects want to minimize hard-coded credentials, support multiple connection profiles, and ensure commands can be executed against the intended account, user, role, warehouse, and database context. Which approach BEST meets these requirements?
- A
Configure named connections in the Snowflake CLI configuration file, use a non-interactive authenticator suitable for CI/CD such as key-pair authentication for service users, and allow developers to select the appropriate connection profile when running CLI commands.
- B
Require every developer and CI/CD runner to pass the account, username, password, role, warehouse, and database as command-line arguments for every Snowflake CLI command so that no local configuration file is needed.
- C
Use a single shared Snowflake user with a stored password for all developers and all CI/CD jobs, and rely on changing the active role after login to separate responsibilities.
- D
Use SnowSQL connection files instead of Snowflake CLI configuration because Snowflake CLI does not support multiple connection definitions or execution context settings.
Show answer and explanation
Correct answer: A
Explanation
The best answer is to use Snowflake CLI named connections together with secure, non-interactive authentication for automation and profile-based access for developers. In real-world architecture, this pattern reduces credential sprawl, supports environment separation, and improves operational safety. Snowflake best practices emphasize avoiding shared credentials, using least privilege, and selecting authentication methods appropriate to the execution context. For CI/CD, key-pair authentication is commonly used because it supports unattended execution. For developers, multiple connection profiles help ensure commands run in the intended account and context. This is preferable to repeatedly passing secrets on the command line or using a shared user. Candidates should recognize that Snowflake CLI is designed to support configurable connections and practical deployment workflows rather than requiring ad hoc credential entry for each command.
- A. Correct.
Correct. Snowflake CLI supports connection profiles in its configuration, which is a practical way to manage multiple environments and execution contexts without repeatedly supplying parameters on every command. For CI/CD, non-interactive authentication such as key-pair authentication for a service principal-style Snowflake user is a common best practice because it avoids embedding passwords in pipeline steps. Developers can use separate named connections on their workstations and select the correct profile for dev, test, or prod workflows. This approach aligns with secure credential handling and operational consistency.
- B. Incorrect.
Incorrect. While Snowflake CLI can accept command parameters, forcing all connection details and credentials to be supplied on every invocation is operationally brittle and increases the chance of credential exposure in shell history, process listings, or pipeline logs. It also does not meet the requirement to minimize hard-coded credentials. Using named connections and secure authentication mechanisms is the more appropriate architectural pattern.
- C. Incorrect.
Incorrect. A single shared user for all humans and automation is a poor security and governance design. It weakens accountability, complicates auditing, and violates least-privilege principles. Changing roles after login does not solve the core issue of shared identity and broad credential distribution. In practice, separate users or identities should be used for developers and CI/CD automation, with tightly scoped privileges.
- D. Incorrect.
Incorrect. This option is based on a false premise. Snowflake CLI does support connection definitions and context-related settings through its own configuration model. Reverting to SnowSQL solely because of assumed CLI limitations would not address the stated goal of standardizing on Snowflake CLI. The misconception is that Snowflake CLI lacks profile-based configuration, which it does support.