COF-C03 Question 157
Single answerKey-pair authenticationA data engineering team uses a service account to run nightly ETL jobs against Snowflake from a Linux host. The security team has banned storing passwords for non-interactive accounts and requires stronger authentication with periodic key rotation. The team wants to move the service account to key-pair authentication with minimal disruption to scheduled jobs. Which action should the Snowflake administrator take to support this requirement?
- A
Generate an RSA key pair, assign the public key to the Snowflake user with ALTER USER, and configure the ETL client to authenticate with the corresponding private key.
- B
Upload the private key to the Snowflake user object and keep the public key only on the ETL host so Snowflake can validate the client during login.
- C
Create a network policy for the service account and continue using a password, because network policies provide the same security benefits as key-pair authentication.
- D
Store the service account password in an internal stage and configure the ETL client to retrieve it at runtime, because staged credentials are encrypted by Snowflake.
Show answer and explanation
Correct answer: A
Explanation
For Snowflake key-pair authentication, the correct implementation is to generate an RSA public/private key pair, keep the private key securely on the client side, and assign the public key to the Snowflake user with ALTER USER. This is commonly used for service accounts and automated workloads because it avoids password storage in scripts or schedulers. Snowflake also supports key rotation by allowing two public key slots on the user object (RSA_PUBLIC_KEY and RSA_PUBLIC_KEY_2), which helps rotate keys with minimal disruption to running jobs. Network policies, stages, and password storage are separate concerns and do not replace asymmetric authentication. These practices align with Snowflake documentation for key-pair authentication and user security administration.
- A. Correct.
Correct. In Snowflake key-pair authentication, the client holds the private RSA key and Snowflake stores the associated public key on the user object. The administrator typically uses ALTER USER ... SET RSA_PUBLIC_KEY = '<public_key>' (or RSA_PUBLIC_KEY_2 for rotation). The ETL tool or driver is then configured to use the private key for non-interactive authentication. This aligns with best practices for service accounts and supports passwordless automation.
- B. Incorrect.
Incorrect. This reverses the trust model. Snowflake never stores the user's private key. The private key must remain under the client's control, while the public key is registered with the Snowflake user. Uploading a private key to Snowflake would defeat the purpose of asymmetric authentication and is not how Snowflake key-pair authentication works.
- C. Incorrect.
Incorrect. A network policy can restrict where connections originate, but it does not replace authentication. Password authentication still requires storing and managing a password for the service account, which violates the stated requirement. Network policies are complementary security controls, not substitutes for key-pair authentication.
- D. Incorrect.
Incorrect. Storing a password in a stage does not convert password authentication into key-pair authentication and still leaves the organization managing a reusable secret. Although Snowflake encrypts staged data, using an internal stage as a credential vault is not the intended pattern for service-account authentication and does not satisfy the requirement for stronger asymmetric authentication with key rotation.