ADA-C01 Question 83
Select 2Manage key-pair authentication and rotationA security team requires quarterly rotation of service account credentials used by an ETL application that connects to Snowflake with key-pair authentication. The application must remain available during the rotation window, and rollback must be possible if the new private key is deployed incorrectly. As the Snowflake administrator, which actions should you take to support a zero-downtime key rotation?
- A
Assign the new public key to the user’s RSA_PUBLIC_KEY_2 property, keep the existing public key in RSA_PUBLIC_KEY, update the ETL application to use the new private key, and after validation remove the old key.
- B
Replace the existing public key in RSA_PUBLIC_KEY with the new key, then immediately invalidate all existing sessions so the application is forced to reconnect with the new private key.
- C
Create a second Snowflake user for the ETL application, assign the new public key to that user, and run both users permanently to achieve seamless rotation.
- D
If the new key fails, switch the application back to the old private key while the old public key remains on the Snowflake user, then troubleshoot and retry the rotation later.
- E
Store the private key directly in Snowflake and use ALTER USER to point the service account to the active private key version.
Show answer and explanation
Correct answers: A, D
Explanation
For Snowflake key-pair authentication, the client proves possession of the private key, while Snowflake stores the corresponding public key on the USER object. To support rotation, Snowflake provides two public key properties: RSA_PUBLIC_KEY and RSA_PUBLIC_KEY_2. The practical zero-downtime pattern is to keep the current public key in one slot, place the new public key in the other slot, update the application to use the new private key, validate successful authentication, and only then remove the old public key. This method supports both continuity and rollback. Overwriting the only active key too early is risky because any deployment or configuration issue can interrupt service. Creating separate users is usually unnecessary and complicates administration. Also, Snowflake never stores the private key for this authentication method; private key custody remains with the client side. These practices align with Snowflake documentation for key-pair authentication and key rotation using ALTER USER with RSA_PUBLIC_KEY and RSA_PUBLIC_KEY_2.
- A. Correct.
Correct. Snowflake supports two public key slots on a user: RSA_PUBLIC_KEY and RSA_PUBLIC_KEY_2. This design is specifically intended to support key rotation with minimal or no downtime. By placing the new public key in the unused slot, you can update the client to use the corresponding new private key, validate connectivity, and then remove the old public key after confirming success. This approach also preserves rollback during the transition.
- B. Incorrect.
Incorrect. Replacing the only configured public key removes rollback capability and can cause an outage if the application is not updated correctly or if the new private key is malformed or inaccessible. For zero-downtime rotation, best practice is to use the second public key attribute rather than overwriting the active one immediately.
- C. Incorrect.
Incorrect. While creating a second user might appear to reduce risk, it is not the recommended way to rotate a key-pair for the same service identity. It introduces additional governance, role, audit, and privilege management complexity and changes the identity used by the application. Snowflake provides RSA_PUBLIC_KEY_2 specifically to avoid this pattern.
- D. Correct.
Correct. Rollback is a key operational requirement in the scenario. As long as the old public key remains configured on the Snowflake user and the client still has access to the old private key, the application can be switched back quickly without changing the Snowflake user definition again. This is why keeping both public keys during the transition is a best practice.
- E. Incorrect.
Incorrect. Snowflake does not store or manage the client private key for key-pair authentication. The private key is generated and stored securely outside Snowflake, typically in the application environment or a secrets management system. Snowflake stores only the public key value on the user object.