ARA-C01 Question 302
Single answerConnectorsA retail company uses a partner-built Snowflake Native App and needs to integrate it with an external SaaS system through a Snowflake connector. The security team requires that outbound connectivity be tightly controlled, secrets are not hard-coded in SQL objects, and the provider must be able to deploy the integration consistently across customer accounts. Which design should the architect recommend?
- A
Create an EXTERNAL ACCESS INTEGRATION that allows network access only to approved endpoints, store credentials in a SECRET, and have the app reference these objects when making outbound calls.
- B
Embed the SaaS API key directly in a stored procedure and use a standard network policy to restrict which external hosts the connector can call.
- C
Use a SECURITY INTEGRATION to define the outbound destinations and store the SaaS password in a session variable that the connector reads at runtime.
- D
Create an API INTEGRATION for the SaaS endpoint and let the Native App use it for arbitrary outbound HTTPS requests, storing the token in a user-defined function definition.
Show answer and explanation
Correct answer: A
Explanation
The best design is to use EXTERNAL ACCESS INTEGRATION with tightly scoped network rules and SECRET objects. This is the Snowflake-supported approach for allowing Snowflake handlers or application components to call external network locations while enforcing explicit egress controls and proper secret management. It is especially relevant in connector and Native App scenarios where the provider needs a repeatable, secure deployment model across consumer accounts. A common misconception is to use network policies for outbound control; however, network policies govern inbound client connections to Snowflake, not egress from Snowflake code. Another misconception is to use API INTEGRATION for arbitrary outbound calls, but API INTEGRATION serves different integration patterns, such as external functions, and is not the general mechanism for connector-style outbound HTTPS access. Snowflake documentation on external network access, EXTERNAL ACCESS INTEGRATION, network rules, and SECRET objects provides the relevant implementation guidance and best practices.
- A. Correct.
Correct. For outbound access from Snowflake code to external services, the recommended pattern is to use EXTERNAL ACCESS INTEGRATION together with network rules and SECRET objects. This design supports controlled egress to approved external endpoints and avoids embedding credentials in code. It also aligns with how Snowflake Native Apps and connector-based solutions can securely manage outbound access in customer environments.
- B. Incorrect.
Incorrect. Hard-coding API keys in stored procedures is a poor security practice and does not meet the requirement to avoid embedding secrets in SQL objects. In addition, network policies in Snowflake control client access to Snowflake, not outbound destinations from Snowflake code to external services.
- C. Incorrect.
Incorrect. SECURITY INTEGRATION objects are used for authentication/security relationships such as federated auth, OAuth, or external token-related configurations, not for defining outbound network destinations for connector calls. Session variables are also not an appropriate secret-management mechanism for deployable, secure connector architectures.
- D. Incorrect.
Incorrect. API INTEGRATION is used for specific integration patterns such as external functions or cloud eventing-related integrations, not as a general-purpose outbound HTTPS mechanism for arbitrary connector traffic from app code. Storing tokens in a UDF definition would also violate the requirement to avoid hard-coded secrets.