ARA-C01 Question 113
Single answerKey-pair authenticationA financial services company uses a custom ETL application running on virtual machines to load data into Snowflake with a service user. Security policy now requires non-interactive authentication without embedding passwords, and the operations team also wants a way to rotate credentials with minimal disruption if a private key is suspected to be compromised. Which approach should the architect recommend?
- A
Configure the Snowflake service user for key-pair authentication, assign the current public key to RSA_PUBLIC_KEY, keep the private key on the ETL hosts, and use RSA_PUBLIC_KEY_2 during key rotation so the application can transition to a new key without downtime.
- B
Store the Snowflake username and password in the ETL application configuration file, encrypt the file at rest, and rotate the password monthly to satisfy the non-interactive authentication requirement.
- C
Use external browser authentication for the ETL service user because it avoids storing credentials locally and supports automated rotation of browser tokens for unattended jobs.
- D
Generate a single key pair for all Snowflake users in the environment and distribute the same private key to each application host so key management is centralized and easier to audit.
Show answer and explanation
Correct answer: A
Explanation
For service-to-Snowflake connectivity, key-pair authentication is a best-practice alternative to password-based authentication because it removes the need to embed passwords in code or configuration and uses asymmetric cryptography. In Snowflake, the public key is associated with the user object, while the private key remains under customer control in the client environment. A key operational advantage is built-in support for rotation using two public key properties on the user: RSA_PUBLIC_KEY and RSA_PUBLIC_KEY_2. This allows an architect to stage key rotation with minimal downtime by temporarily trusting both the old and new keys during transition. External browser authentication is designed for interactive users, not headless services. Reusing the same private key across multiple identities undermines isolation and expands blast radius in the event of compromise. These recommendations align with Snowflake documentation on key-pair authentication and key rotation for users.
- A. Correct.
Correct. Snowflake supports key-pair authentication for programmatic clients and service accounts, allowing the client to authenticate with a private key while Snowflake stores only the public key on the user object. For rotation, Snowflake supports two public key slots, RSA_PUBLIC_KEY and RSA_PUBLIC_KEY_2, which enables a staged cutover: add the new public key, update the client to use the new private key, validate connectivity, and then remove the old key. This meets the requirement for non-interactive authentication and minimizes disruption during key compromise or routine rotation.
- B. Incorrect.
Incorrect. Although password storage can be improved with encryption, this still relies on password-based authentication and does not satisfy the requirement to avoid embedded passwords. It also increases operational risk because passwords are shared secrets that are harder to rotate safely across distributed automation compared with asymmetric key pairs.
- C. Incorrect.
Incorrect. External browser authentication is intended for interactive user sign-in flows, not unattended ETL services. It requires user interaction with a browser and is therefore not appropriate for non-interactive service accounts running scheduled jobs on servers.
- D. Incorrect.
Incorrect. Reusing one key pair across multiple Snowflake users or hosts is a poor security practice. If that private key is compromised, every dependent user or application is affected. Best practice is to use separate key pairs per service identity or application boundary to support least privilege, better auditability, and more targeted rotation.