SnowPro Advanced: Security Engineer Question 48
Single answerImplement external API authentication and secretsA security engineering team is building a Snowflake external function that calls a third-party fraud detection REST API through API Gateway. The API requires a bearer token that must be rotated periodically, and the team does not want developers to embed credentials in function definitions or application code. They also want administrators to centrally manage the secret and allow only approved integrations to use it. Which approach best meets these requirements?
- A
Create a SECURITY INTEGRATION for external API authentication, store the bearer token in a SECRET object, and reference both from the API integration used by the external function.
- B
Store the bearer token in a session variable and configure the external function to read the variable at runtime so each developer can manage their own token.
- C
Embed the bearer token directly in the EXTERNAL FUNCTION definition so Snowflake can pass it to API Gateway in the request headers.
- D
Store the bearer token in a table encrypted with masking policies, and have the external function query the table before invoking the external API.
Show answer and explanation
Correct answer: A
Explanation
The best solution is to use Snowflake-native secret management and authentication integration rather than application-managed or hardcoded credentials. In Snowflake, SECRET objects are designed to store authentication material securely, while SECURITY INTEGRATION objects define how authentication is handled for external connectivity scenarios. This supports centralized governance, easier rotation, and least-privilege access patterns. By contrast, session variables and embedded tokens are operationally brittle and insecure, and using tables plus masking policies is a misuse of data protection features rather than a proper secret-management design. Snowflake documentation on secrets, security integrations, and external access/authentication patterns emphasizes separating credential storage from code and using managed objects for secure outbound authentication.
- A. Correct.
Correct. For external access and authenticated outbound calls, Snowflake supports using SECRET objects to securely store credentials and SECURITY INTEGRATION objects for the authentication configuration. This approach avoids embedding secrets in code, allows centralized administration, and supports controlled use through approved integrations. It aligns with Snowflake best practices for managing external API authentication and secrets.
- B. Incorrect.
Incorrect. Session variables are not an appropriate or secure mechanism for managing external API credentials for external functions. They are user-scoped, hard to govern centrally, and do not provide the controlled secret-management model required for production security. This also creates operational inconsistency because each developer would manage credentials separately.
- C. Incorrect.
Incorrect. Embedding a bearer token directly in the EXTERNAL FUNCTION definition violates the requirement to avoid hardcoding credentials and makes rotation difficult. It also increases the risk of credential exposure through DDL access, change management processes, or copied code.
- D. Incorrect.
Incorrect. Although storing sensitive values in a protected table may seem workable, this is not the intended Snowflake mechanism for outbound API authentication. External functions do not query a table to retrieve secrets during invocation, and masking policies protect query results rather than serving as a secure secret distribution model for external API calls.