SnowPro Advanced: Security Engineer Question 90
Single answerCloud provider tokensA security engineer is reviewing how a Snowflake account in AWS accesses data in a private S3 bucket used for external stages. The organization wants to eliminate long-lived cloud credentials, reduce credential management overhead, and ensure Snowflake can obtain temporary AWS credentials only when needed. Which configuration best meets these requirements?
- A
Create the external stage with AWS_KEY_ID and AWS_SECRET_KEY so Snowflake can store the IAM user's permanent access keys and reuse them for every query.
- B
Configure a storage integration that references an AWS IAM role trusted by Snowflake, so Snowflake can assume the role and use temporary cloud provider tokens when accessing the bucket.
- C
Use a Snowflake network policy to restrict access to the S3 bucket from Snowflake's IP addresses, which causes AWS to issue temporary tokens automatically.
- D
Create a database role in Snowflake with USAGE on the stage and grant it to users, because Snowflake database roles generate temporary AWS credentials for stage access.
Show answer and explanation
Correct answer: B
Explanation
For external access to S3, Snowflake best practice is to use a storage integration instead of hard-coded AWS keys. In AWS, Snowflake uses an IAM trust relationship so it can assume a designated IAM role and receive temporary credentials through AWS Security Token Service (STS). This approach reduces the security exposure associated with long-lived access keys and simplifies credential lifecycle management. The scenario specifically asks for elimination of long-lived credentials and use of temporary cloud provider tokens, which maps directly to storage integrations with IAM roles. Relevant Snowflake documentation includes guidance for CREATE STORAGE INTEGRATION, configuring an S3 storage integration, and the AWS IAM trust policy and external ID configuration required for Snowflake to assume the role.
- A. Incorrect.
Incorrect. Using AWS_KEY_ID and AWS_SECRET_KEY embeds long-lived AWS access keys in stage credentials, which does not meet the requirement to eliminate long-lived cloud credentials. While this pattern can work technically, it creates operational and security risks around key rotation, storage, and accidental exposure. Snowflake security best practice is to prefer storage integrations over directly embedded cloud credentials where supported.
- B. Correct.
Correct. A Snowflake storage integration for S3 is designed to let Snowflake use an AWS IAM role, with a trust relationship that allows Snowflake to assume that role and obtain temporary credentials from AWS STS. This reduces reliance on static keys, centralizes access control in AWS IAM, and aligns with the requirement to use temporary cloud provider tokens only when needed.
- C. Incorrect.
Incorrect. Network policies in Snowflake control which client IP addresses can connect to Snowflake; they do not configure AWS credential issuance or token exchange for S3 access. Restricting network access may be part of a broader security posture, but it does not replace the need for Snowflake to authenticate to AWS using an IAM role or credentials.
- D. Incorrect.
Incorrect. Database roles govern authorization inside Snowflake objects such as schemas, tables, and stages, but they do not create or broker AWS credentials. A user still needs the Snowflake privilege to use the stage, and Snowflake still needs a valid cloud authentication mechanism, such as a storage integration backed by an IAM role, to access S3.