ADA-C01 Question 85
Single answerManage programmatic authentication tokens and rotationA security team is replacing password-based service account access with key pair authentication for a Snowflake user used by several automation jobs. The team wants to rotate credentials with minimal disruption and ensure old credentials stop working promptly after the cutover. Which approach should the Snowflake administrator take?
- A
Generate a new public/private key pair, set the new public key in RSA_PUBLIC_KEY_2 for the service user, update clients to use the new private key, verify connectivity, and then remove the old key from RSA_PUBLIC_KEY.
- B
Generate a new key pair, replace RSA_PUBLIC_KEY with the new public key immediately, and rely on Snowflake to continue accepting the previous private key for a grace period.
- C
Create a second Snowflake user with the new key pair, because Snowflake does not support having more than one active public key for a user during rotation.
- D
Store the private key in a Snowflake stage, assign USAGE on the stage to the automation role, and rotate the stage file reference when needed.
Show answer and explanation
Correct answer: A
Explanation
For Snowflake programmatic authentication using key pair authentication, the recommended rotation method is to use the two supported public key attributes on the user object: RSA_PUBLIC_KEY and RSA_PUBLIC_KEY_2. This enables phased rotation with minimal service interruption. Administrators typically add the new public key in the unused slot, distribute the new private key securely to clients, test and monitor successful authentication, and then remove the old public key so the former key pair can no longer be used. Replacing the only configured public key too early causes immediate failures for any client that has not yet switched. Creating a separate user is usually unnecessary and complicates governance. Snowflake documentation on key pair authentication and key pair rotation describes the dual-key approach and emphasizes secure private key handling outside Snowflake.
- A. Correct.
Correct. Snowflake supports key pair rotation by allowing two active public keys on a user: RSA_PUBLIC_KEY and RSA_PUBLIC_KEY_2. A practical low-disruption rotation pattern is to add the new public key to the unused slot, update clients to authenticate with the corresponding new private key, validate that all workloads have migrated, and then unset the old public key. This approach minimizes downtime and gives administrators control over the cutover.
- B. Incorrect.
Incorrect. Snowflake does not provide an automatic grace period that allows the old private key to continue working after the corresponding public key is replaced. If RSA_PUBLIC_KEY is overwritten before clients are updated, any job still using the old private key will fail authentication immediately.
- C. Incorrect.
Incorrect. This is a plausible workaround, but it is not the best answer because Snowflake natively supports rotation for a single user by maintaining two public key slots during transition. Creating a second user adds operational complexity, can require privilege duplication, and is unnecessary for standard key pair rotation.
- D. Incorrect.
Incorrect. Private keys should not be stored in Snowflake stages for applications to retrieve and use for authentication. Stages are designed for data files, not secure secret management. Best practice is to keep private keys in an external secrets manager or secure key store and only register the corresponding public key with the Snowflake user.