ARA-C01 Question 363
Single answerExternal functionsA financial services company stores customer transactions in Snowflake and must enrich each row with a fraud risk score generated by a third-party REST service. The security team requires that Snowflake never call the vendor endpoint directly over the public internet and that all requests be centrally authenticated and monitored. The architect wants the solution to minimize changes if the fraud service endpoint is replaced later. Which design should be implemented?
- A
Create an external function in Snowflake that uses an API integration mapped to a cloud provider proxy service (such as API Gateway or equivalent), and have that proxy invoke the fraud scoring REST service.
- B
Create a JavaScript UDF in Snowflake that sends HTTPS requests directly to the vendor API so the scoring logic executes inline with SQL queries.
- C
Create a secure view over the transactions table and configure the view to call the vendor REST endpoint when queried, because secure views isolate external access.
- D
Use Snowpipe to send each inserted transaction row directly to the fraud scoring endpoint, then query the returned score from the pipe metadata.
Show answer and explanation
Correct answer: A
Explanation
The best design is to use a Snowflake external function backed by an API integration and a cloud proxy layer. External functions are the supported Snowflake feature for invoking external services from SQL. In practice, Snowflake calls a proxy service that you control, and that proxy can authenticate, monitor, transform, and route requests to the actual backend service. This satisfies the requirement that Snowflake not call the vendor directly and supports centralized security and observability. It also improves maintainability because if the fraud service changes, the proxy backend configuration can often be updated without requiring downstream SQL changes.
Key best-practice points from Snowflake documentation and common architecture guidance:
- External functions require an API integration and a remote service endpoint fronted by a supported proxy/service management layer.
- The proxy pattern is important for authentication, authorization, logging, throttling, and backend abstraction.
- UDFs and views do not provide arbitrary outbound REST invocation.
- Snowpipe is for data ingestion, not synchronous API enrichment during SQL execution.
Therefore, option 1 is the only design aligned with Snowflake's supported external function architecture and the stated security and maintainability requirements.
- A. Correct.
Correct. Snowflake external functions are specifically designed to let SQL invoke remote services through a supported proxy layer managed in the cloud platform, typically API Gateway on AWS, Azure API Management on Azure, or Google Cloud API Gateway/Cloud Functions patterns depending on architecture. The API integration provides centralized configuration and secure connectivity controls. This design also decouples Snowflake from the vendor endpoint because the proxy can be updated to route to a new backend without changing SQL callers or the external function definition in many cases.
- B. Incorrect.
Incorrect. Snowflake JavaScript UDFs do not support making arbitrary outbound network calls to external REST endpoints. External access is not how JavaScript UDFs work in Snowflake. This distractor reflects a common misconception that UDF code can behave like general-purpose application code with unrestricted HTTP access.
- C. Incorrect.
Incorrect. Secure views protect sensitive logic and data exposure semantics, but they do not provide a mechanism to invoke external REST services. Views in Snowflake are query abstractions over SQL logic, not integration points for outbound API calls. The misconception here is confusing data security features with integration capabilities.
- D. Incorrect.
Incorrect. Snowpipe is designed for continuous data ingestion into Snowflake, not for making per-row outbound API calls to enrichment services during query execution. Pipe metadata also would not store arbitrary response payloads from an external fraud API in the way described. This option confuses ingestion orchestration with runtime service integration.