ADA-C01 Question 86
Single answerManage programmatic authentication tokens and rotationA security team is replacing password-based service accounts with key pair authentication for several unattended ETL jobs that connect to Snowflake through the Python connector. The team has a policy requiring regular credential rotation with minimal job interruption. One ETL service user already exists and currently authenticates successfully with an RSA public key. During the next rotation window, administrators want to introduce a new key, validate that jobs can use it, and still preserve the ability to fall back quickly if a deployment issue occurs. Which approach best meets these requirements?
- A
Set a second public key on the same Snowflake user, deploy the matching new private key to the ETL jobs, validate connectivity, and then remove the old public key after cutover is confirmed.
- B
Create a second password for the same Snowflake user, keep both the password and the key active during rotation, and remove the password after validation.
- C
Create a clone of the ETL user with the new public key, run jobs against both users in parallel, and then merge the authentication state back to the original user.
- D
Replace the existing public key on the user immediately, because Snowflake automatically retains the prior key for rollback until the next successful login.
Show answer and explanation
Correct answer: A
Explanation
For Snowflake programmatic authentication using key pair authentication, the practical rotation strategy is to use Snowflake's support for two public keys on a user during the transition period. This allows staged deployment: add the new public key, update clients to the corresponding private key, test successfully, and then remove the old public key once the change is stable. This minimizes downtime and preserves a fast rollback path if client deployment issues occur. In Snowflake documentation, this is covered under key pair authentication and key pair rotation for users, including use of the user-level RSA public key properties for rotation. From an administrator perspective, this is the most secure and operationally sound approach for rotating programmatic credentials for unattended jobs.
- A. Correct.
Correct. Snowflake supports key pair rotation by allowing two public keys to be associated with a user during transition, commonly using the primary public key field and the secondary/rotation public key field. This enables administrators to add the new public key first, update clients to use the new private key, validate successful authentication, and then remove the old key after the cutover. This is the recommended approach for minimizing downtime and providing a rollback path during programmatic authentication rotation.
- B. Incorrect.
Incorrect. Password-based authentication is a separate authentication method and does not represent proper key pair rotation. Reintroducing passwords weakens the intended security model and does not address controlled rotation of the RSA key pair used by the unattended jobs. A candidate might choose this because it seems like a fallback mechanism, but it is not the best-practice approach when the goal is to manage and rotate programmatic key pair credentials.
- C. Incorrect.
Incorrect. Cloning users is not how Snowflake manages authentication key rotation, and user state such as ownership, grants, and integrations is not something you 'merge back' after parallel authentication testing. This adds unnecessary operational complexity and risk. The realistic and supported method is to rotate keys on the existing user rather than creating duplicate service identities for the same workload.
- D. Incorrect.
Incorrect. Snowflake does not automatically preserve the prior public key for rollback just because a key was replaced. If administrators overwrite the existing key without using the supported dual-key rotation pattern, they risk immediate authentication failures for jobs still using the old private key. This option reflects a common misconception that Snowflake keeps an implicit authentication history for rollback.