ARA-C01 Question 112
Single answerKey-pair authenticationA company is replacing password-based service accounts with key-pair authentication for several CI/CD pipelines that connect to Snowflake through the Python Connector and SnowSQL. Security policy requires that private keys be rotated regularly with no outage, and operations wants a rollback path if a newly deployed key fails. A service user named CICD_SVC already exists and is used by multiple automated jobs. Which approach should the architect recommend to meet these requirements with the least disruption?
- A
Generate a new RSA key pair, update the CICD_SVC user with the new public key in RSA_PUBLIC_KEY, distribute the new private key to all jobs, and remove the old key immediately after deployment.
- B
Generate a new RSA key pair, keep the current public key in RSA_PUBLIC_KEY, add the new public key to RSA_PUBLIC_KEY_2 for CICD_SVC, migrate clients to the new private key in a controlled manner, validate connectivity, and then remove the old key by unsetting the original public key.
- C
Store the private key in an internal Snowflake stage encrypted with a passphrase, grant the CICD_SVC role access to the stage, and configure clients to download the key at runtime so only one copy needs to be rotated.
- D
Create a second Snowflake user named CICD_SVC_NEW with the new public key, switch pipelines over time, and keep both service users permanently to provide continuous rollback capability.
- E
Rotate the key by changing the user's password and enabling MFA temporarily, because key-pair authentication still requires the Snowflake password as the primary credential for non-interactive clients.
Show answer and explanation
Correct answer: B
Explanation
The best answer is to use Snowflake's built-in dual public-key mechanism for key-pair rotation on a single user. Snowflake users can have two public keys associated with them, typically using the RSA_PUBLIC_KEY and RSA_PUBLIC_KEY_2 properties. This design supports zero-downtime rotation: add the new public key while keeping the old one active, update clients gradually to the new private key, test successfully, and then remove the old public key. This provides both continuity and a rollback path. From an architecture and operations perspective, this is preferable to immediate cutovers or creating duplicate service accounts. It also aligns with security best practices: Snowflake stores only public keys, while private keys should remain under customer control in secure secret-management tooling. See Snowflake documentation on key-pair authentication and key rotation for users, including support for assigning and rotating RSA public keys with RSA_PUBLIC_KEY and RSA_PUBLIC_KEY_2.
- A. Incorrect.
Incorrect. Updating only RSA_PUBLIC_KEY with the new key and removing the old key immediately creates a cutover event rather than a no-downtime rotation. Any client still using the old private key will fail as soon as the old public key is replaced. This approach also provides little rollback flexibility because the old key is removed before the new key is fully validated across all jobs.
- B. Correct.
Correct. Snowflake supports key rotation for key-pair authentication by allowing two active public keys on a user: RSA_PUBLIC_KEY and RSA_PUBLIC_KEY_2. This enables a staged migration: keep the existing key active, add the new public key as the secondary key, update clients to use the new private key, validate successful connections, and then remove the old public key. This is the standard approach for seamless rotation and rollback during migration.
- C. Incorrect.
Incorrect. Private keys should not be stored in Snowflake stages for clients to retrieve at runtime. A Snowflake stage is not a secret-management solution for distributing client private keys, and granting a Snowflake role access to retrieve its own authentication material introduces unnecessary risk. Best practice is to store private keys in a secure external secret-management or key-management system and only register the corresponding public keys in Snowflake.
- D. Incorrect.
Incorrect. Creating a second user can work operationally, but it introduces unnecessary identity sprawl, duplicate grants or role mappings, and more administrative overhead. It is not the least disruptive option because Snowflake already provides built-in dual public-key support on a single user specifically for key rotation. Keeping both users permanently also complicates auditing and lifecycle management.
- E. Incorrect.
Incorrect. This reflects a common misconception. With key-pair authentication, the client proves identity using the private key corresponding to the registered public key; it does not use the Snowflake password as the primary credential for these automated connections. MFA is also not a replacement mechanism for rotating a key pair used by non-interactive service clients.