SnowPro Advanced: Security Engineer Question 44
Single answerImplement key-pair authenticationA security engineer is replacing password-based service accounts with key-pair authentication for a production ETL application that connects to Snowflake through the Python connector. The application runs in two regions for high availability, and the team wants a key rotation approach that avoids downtime during deployment. Which action should the engineer take to meet these requirements?
- A
Generate a new RSA key pair, assign the new public key to the service user with ALTER USER ... SET RSA_PUBLIC_KEY, and immediately remove the old key before updating the application instances.
- B
Generate a new RSA key pair, assign the new public key to the service user with ALTER USER ... SET RSA_PUBLIC_KEY_2, update application instances to use the new private key, and then remove the old public key after cutover is complete.
- C
Store the private key in a Snowflake internal stage and reference it in the connection string so both regions can retrieve it during authentication.
- D
Enable SSO for the service user and keep the existing private key configured as a fallback because Snowflake requires both for connector-based authentication.
Show answer and explanation
Correct answer: B
Explanation
For Snowflake key-pair authentication, the client holds the private key and Snowflake stores the corresponding public key on the USER object. To support rotation with minimal or no downtime, Snowflake provides two public key properties: RSA_PUBLIC_KEY and RSA_PUBLIC_KEY_2. Best practice is to add the new public key to the unused slot, deploy the matching private key to client applications in phases, validate connectivity, and then remove the old public key. This is especially important in distributed deployments where not all application instances switch at the same time. Relevant Snowflake documentation includes user authentication with key-pair authentication and ALTER USER support for RSA_PUBLIC_KEY and RSA_PUBLIC_KEY_2 rotation workflows.
- A. Incorrect.
This is incorrect because replacing the existing RSA_PUBLIC_KEY directly and removing the old key before the application instances are updated creates a deployment race condition. Any instance still using the old private key will fail authentication. This does not meet the requirement for rotation without downtime.
- B. Correct.
This is correct. Snowflake supports key rotation for key-pair authentication by allowing two public keys on a user: RSA_PUBLIC_KEY and RSA_PUBLIC_KEY_2. A common zero-downtime rotation pattern is to add the new public key in the secondary slot, roll out the new private key to clients, verify successful authentication, and only then remove the old key. This supports staged deployment across multiple regions or instances.
- C. Incorrect.
This is incorrect because Snowflake does not use an internal stage as a mechanism for connector authentication keys. The client must present the private key during authentication, and the private key should be stored securely in the organization's secret-management system or protected filesystem, not in Snowflake for retrieval by the client.
- D. Incorrect.
This is incorrect because SSO is not required for service accounts using key-pair authentication, and Snowflake does not require both SSO and key-pair authentication simultaneously for Python connector authentication. This option mixes authentication models and adds unnecessary complexity.