ARA-C01 Question 114
Single answerSecurity integrationA company uses Okta as its identity provider and wants to centralize authentication for Snowflake users across Snowsight, the Classic Console, and JDBC/ODBC clients. The security team also requires that temporary credentials for AWS resources be issued through Snowflake for external stages, without storing long-term cloud keys in user sessions. Which configuration best meets these requirements with the LEAST operational overhead?
- A
Create a SAML2 security integration for Okta to support federated authentication to Snowflake, and create a separate STORAGE INTEGRATION for AWS external stages so Snowflake can assume an IAM role for cloud access.
- B
Create an OAuth security integration for Okta for all Snowflake access, and configure users to pass AWS access keys in each session when querying external stages.
- C
Create a SCIM security integration for Okta so users can authenticate to Snowflake, and use an external function integration to retrieve temporary AWS credentials when stages are accessed.
- D
Create a SAML2 security integration for Snowsight only, and create individual named stages with embedded AWS credentials owned by each application role.
Show answer and explanation
Correct answer: A
Explanation
The best answer is to use two purpose-built integrations: a SAML2 security integration for federated authentication with Okta, and a STORAGE INTEGRATION for AWS access to external stages. In Snowflake, security integrations support external authentication and related security services such as SAML, OAuth, and SCIM, but each serves a different purpose. SAML2 security integrations are appropriate for enterprise SSO with identity providers like Okta. SCIM is for provisioning, not authentication. For cloud storage access, Snowflake best practice is to use a storage integration so Snowflake can assume a cloud IAM role rather than storing access keys in stage definitions or passing credentials in sessions. This approach minimizes secret sprawl, simplifies operations, and aligns with Snowflake documentation on federated authentication and storage integrations.
- A. Correct.
Correct. A SAML2 security integration is the standard approach for federated SSO from an IdP such as Okta into Snowflake web interfaces and can also support federated authentication patterns used by client connections depending on the client and setup. Separately, a STORAGE INTEGRATION is the recommended Snowflake mechanism for accessing AWS S3 without embedding long-term cloud credentials in stages or user sessions. Snowflake assumes an IAM role using the trust relationship, which reduces credential management overhead and aligns with cloud security best practices.
- B. Incorrect.
Incorrect. OAuth security integrations are primarily used for OAuth-based authorization flows, including external OAuth scenarios, but they are not the default choice for broad SSO across Snowflake interfaces in this scenario. More importantly, requiring users to pass AWS access keys into sessions violates the requirement to avoid long-term cloud keys and increases operational and security risk.
- C. Incorrect.
Incorrect. SCIM security integrations are used for automated provisioning and deprovisioning of users and groups, not for user authentication into Snowflake. External function integrations are for invoking external services, not for brokering storage credentials for stage access. This option confuses identity lifecycle management with authentication and storage access patterns.
- D. Incorrect.
Incorrect. A SAML2 integration limited to Snowsight would not adequately address the requirement for centralized authentication across Classic Console and JDBC/ODBC clients. In addition, embedding AWS credentials directly in stages is less secure and creates higher operational overhead than using a storage integration with an IAM role.