ADA-C01 Question 84
Single answerManage key-pair authentication and rotationA company uses a service account named ETL_SVC for automated Snowflake loads through a JDBC client configured for key-pair authentication. Security policy now requires rotating the RSA public key with no downtime, because nightly loads cannot be interrupted. The current public key is already assigned to the user and the new key pair has been generated and validated by the security team. What should the Snowflake administrator do to complete the rotation with minimal risk and no service interruption?
- A
Set the new public key on the user with ALTER USER ETL_SVC SET RSA_PUBLIC_KEY = '<new_key>'; then immediately update the client to use the new private key during the same maintenance window.
- B
Assign the new public key to the secondary key slot on the user, update the client to use the new private key, verify successful authentication, and then remove or replace the old key.
- C
Create a second Snowflake user with the new public key, grant it the same roles as ETL_SVC, switch the JDBC connection to the new username, and then drop the original user after validation.
- D
Temporarily disable key-pair authentication for ETL_SVC and use a password during the rotation, then re-enable key-pair authentication after the client has been updated.
Show answer and explanation
Correct answer: B
Explanation
For Snowflake user key-pair authentication, administrators can manage rotation with minimal downtime by using the two supported public key properties on a user: RSA_PUBLIC_KEY and RSA_PUBLIC_KEY_2. The practical best practice is to add the new public key to the unused slot, move the client to the matching private key, validate successful authentication, and then retire the old key. This approach supports rollback and avoids interrupting automated processes. Replacing the only configured key in a single step is riskier because any timing mismatch between Snowflake and the client can break authentication. Creating a new user is generally unnecessary and complicates security administration and auditing. Snowflake documentation on key-pair authentication and rotation describes the use of the two key slots for seamless rotation.
- A. Incorrect.
Incorrect. Replacing RSA_PUBLIC_KEY directly can cause an outage if the client has not yet switched to the new private key or if rollback is needed. Snowflake supports key rotation using two public key slots so clients can continue authenticating during transition. Using only the primary slot for an immediate cutover introduces unnecessary risk.
- B. Correct.
Correct. Snowflake supports key-pair rotation by allowing two public keys on a user: RSA_PUBLIC_KEY and RSA_PUBLIC_KEY_2. The recommended no-downtime approach is to place the new public key in the unused slot, update the client to authenticate with the corresponding private key, confirm successful logins, and only then remove the old key or promote the new one as part of standard rotation hygiene. This minimizes service interruption and provides rollback capability.
- C. Incorrect.
Incorrect. Although this might work operationally, creating a second user is not the recommended approach for key rotation and can introduce unnecessary complexity around ownership, grants, audit trails, integrations, and client configuration. Snowflake provides built-in support for seamless rotation on the same user via the two RSA public key properties.
- D. Incorrect.
Incorrect. This weakens the authentication posture and is unnecessary. Snowflake key-pair rotation does not require falling back to password authentication. Introducing a password for a service account can violate security policy, create credential sprawl, and increase operational risk.