ARA-C01 Question 317
Single answerODBCA financial services company uses a legacy reporting application that connects to Snowflake through the Snowflake ODBC driver. During a security review, the architecture team is asked to reduce the risk of credential exposure on analyst workstations while preserving support for federated login through the company identity provider. The application is interactive and runs on domain-joined desktops used by individual analysts. Which approach best meets these requirements?
- A
Configure the ODBC DSN to use the externalbrowser authenticator so users authenticate through the corporate identity provider without storing Snowflake passwords in the DSN.
- B
Store each analyst's Snowflake username and password in the system DSN and rely on TLS encryption in the ODBC driver to protect the credentials.
- C
Use key-pair authentication in the ODBC DSN for each analyst by distributing the same private key file to all desktops and protecting it with a shared passphrase.
- D
Switch the DSN to use the Snowflake account administrator role by default so analysts do not need to reauthenticate when opening the reporting application.
Show answer and explanation
Correct answer: A
Explanation
For interactive desktop users connecting through ODBC, the Snowflake ODBC driver supports SSO and federated authentication using the externalbrowser authenticator. This is commonly recommended when organizations want users to authenticate through an enterprise identity provider and avoid storing Snowflake passwords locally in DSNs or applications. In contrast, TLS only protects data in transit and does not secure secrets at rest on the workstation. Key-pair authentication is useful in some automation and service-account scenarios, but sharing one private key across many users is not an acceptable architecture and does not preserve federated SSO. Finally, role assignment should follow least-privilege principles; using highly privileged roles like ACCOUNTADMIN for convenience is an architectural anti-pattern. These practices align with Snowflake guidance for client connectivity, federated authentication, and secure credential handling.
- A. Correct.
Correct. The Snowflake ODBC driver supports federated authentication using the externalbrowser authenticator. This launches a browser-based sign-in flow against the organization's identity provider, allowing SSO without embedding Snowflake passwords in the DSN or application configuration. For an interactive desktop application used by individual analysts, this is a practical and secure way to reduce credential exposure while preserving federated login.
- B. Incorrect.
Incorrect. TLS protects credentials in transit between the client and Snowflake, but it does not address the primary risk described in the scenario: credential exposure on analyst workstations. Storing usernames and passwords in a DSN leaves secrets on the endpoint and is specifically what the security review is trying to avoid.
- C. Incorrect.
Incorrect. Key-pair authentication can be used with Snowflake clients, but distributing the same private key to all analyst desktops is a poor security design because it eliminates individual accountability and creates a high-impact shared secret. It also does not align well with the requirement to preserve federated login through the corporate identity provider. A candidate might choose this because key-pair authentication is generally stronger than passwords, but in this scenario it does not meet the stated identity and endpoint-risk requirements.
- D. Incorrect.
Incorrect. Assigning ACCOUNTADMIN by default is a severe violation of least-privilege design and does not solve the authentication problem. It increases security risk rather than reducing it. Reauthentication concerns should be addressed through supported authentication methods and session management, not by elevating privileges.