ARA-C01 Question 318
Single answerODBCA company is migrating a legacy reporting application to Snowflake. The application connects through the Snowflake ODBC driver and must use key-pair authentication because service-account passwords are no longer allowed. During testing, the team confirms that the public key is correctly assigned to the Snowflake user, but connections from the ODBC client still fail during authentication. The architect wants a solution that aligns with Snowflake ODBC driver requirements for private key handling and minimizes operational issues across Windows and Linux client hosts. Which action should the architect recommend?
- A
Configure the ODBC DSN or connection string to reference an unencrypted private key file so the Snowflake ODBC driver can use it directly for key-pair authentication.
- B
Store the private key in the Snowflake stage and configure the ODBC driver to download it at connection time.
- C
Convert the private key to a public key fingerprint and place that fingerprint in the ODBC connection string instead of the private key path.
- D
Use browser-based SSO in the ODBC driver and map it internally to the service account so key-pair authentication is no longer required.
Show answer and explanation
Correct answer: A
Explanation
This question tests practical knowledge of how Snowflake ODBC clients authenticate using key pairs. In Snowflake, the user object stores the public key, while the client must possess and use the matching private key. When the public key is already configured correctly but authentication still fails, architects should verify how the ODBC driver is being given access to the private key and whether the private key format and handling are compatible with the driver on the target operating systems. Best practice is to configure the DSN or connection string correctly and manage the private key securely at the OS or secrets-management level. Snowflake documentation for key-pair authentication and ODBC driver configuration emphasizes that the client must provide the private key locally; Snowflake stages, public key fingerprints, and interactive browser SSO do not replace that requirement for service-account ODBC authentication.
- A. Correct.
Correct. For Snowflake key-pair authentication with the ODBC driver, the client must provide access to the private key material in a format the driver can use. A common implementation approach is to specify the private key file in the DSN or connection string, and operationally this often means using an unencrypted private key because the driver does not rely on an interactive prompt for a passphrase in the same way a user-driven tool might. This is the most practical recommendation when the public key is already set correctly on the Snowflake user but ODBC authentication is still failing due to private key handling.
- B. Incorrect.
Incorrect. Snowflake stages are for data files, not for securely distributing authentication private keys to ODBC clients at login time. The ODBC driver does not support a pattern where it fetches the private key from a Snowflake stage and then uses it to authenticate. This option confuses data staging with credential management.
- C. Incorrect.
Incorrect. Snowflake stores and validates a user's public key on the server side, but the ODBC client still must sign authentication data with the actual private key. A public key fingerprint is not a substitute for the private key and cannot be used by the driver to perform key-pair authentication. This distractor reflects a misunderstanding of asymmetric authentication.
- D. Incorrect.
Incorrect. Browser-based SSO is a different authentication method intended for interactive user sign-in, not for headless service accounts that are explicitly required to use key-pair authentication. Mapping browser SSO to a service account would not satisfy the stated requirement and is not an appropriate replacement in this scenario.