ADA-C01 Question 244
Select 2Create and manage Snowflake storage integrationA company wants Snowflake users to load files from a single Amazon S3 bucket into external stages without embedding long-term AWS keys in stage definitions. The security team also requires that access be limited to only the approved bucket and path, and that trust be established using Snowflake-managed IAM credentials. As the Snowflake administrator, which two actions should you take to implement this correctly?
- A
Create a STORAGE INTEGRATION of type EXTERNAL_STAGE for S3, define the allowed S3 location(s), and then use DESC INTEGRATION to obtain the Snowflake IAM user ARN and external ID needed for the AWS trust policy.
- B
Create the external stage first with AWS_KEY_ID and AWS_SECRET_KEY, then attach a storage integration later so Snowflake can automatically rotate those keys.
- C
In AWS, create or update an IAM role with a trust policy that references the Snowflake IAM user ARN and external ID from the storage integration, and grant that role permission to the approved S3 bucket/prefix.
- D
Grant USAGE on the storage integration to the users or roles that will create or use stages referencing it.
- E
Set STORAGE_ALLOWED_LOCATIONS to '*' so that future buckets can be added without modifying the integration.
Show answer and explanation
Correct answers: A, C
Explanation
To create and manage a Snowflake storage integration for Amazon S3 securely, the administrator should use a STORAGE INTEGRATION rather than embedding AWS access keys in stage definitions. The correct setup has two foundational parts: first, create the integration in Snowflake with restricted STORAGE_ALLOWED_LOCATIONS; second, configure the AWS IAM role and trust policy using the Snowflake-generated IAM user ARN and external ID obtained from DESC INTEGRATION. This pattern supports keyless access from the Snowflake side and aligns with least-privilege access controls. After the integration exists, administrators typically grant USAGE on the integration to appropriate roles so they can create or use stages that reference it, but that is a privilege-management step rather than the primary implementation step asked here. Relevant Snowflake documentation includes CREATE STORAGE INTEGRATION, DESC INTEGRATION, and guidance for configuring an Amazon S3 storage integration and external stages.
- A. Correct.
Correct. For Amazon S3, the recommended approach is to create a storage integration with TYPE = EXTERNAL_STAGE and STORAGE_PROVIDER = S3, and to restrict access using STORAGE_ALLOWED_LOCATIONS. After creation, DESC INTEGRATION returns values such as STORAGE_AWS_IAM_USER_ARN and STORAGE_AWS_EXTERNAL_ID, which are required to configure the AWS trust relationship so Snowflake can assume access through the customer-managed role.
- B. Incorrect.
Incorrect. Supplying AWS keys directly in stage definitions is the older credential-based pattern and does not meet the requirement to avoid embedded long-term credentials. Snowflake does not convert such stages into integration-based stages automatically, and attaching an integration later is not how credential rotation is handled.
- C. Correct.
Correct. For S3 storage integrations, the AWS side must trust Snowflake by using the IAM user ARN and external ID exposed by DESC INTEGRATION. The IAM role also needs permissions scoped to the approved bucket and prefix. This is the core cross-cloud trust configuration that enables Snowflake to access S3 securely without hard-coded keys.
- D. Incorrect.
Incorrect in this scenario. Granting USAGE on the storage integration is often necessary for roles that will create stages using the integration or otherwise reference it, but it is not one of the two core implementation actions that establish the secure integration itself. The question asks which actions implement the requirement correctly; creating the integration and configuring the AWS role are the essential steps. This option reflects an operational privilege step rather than the primary setup.
- E. Incorrect.
Incorrect. Using '*' would broadly allow all storage locations and violates the stated security requirement to limit access to only the approved bucket and path. Best practice is to explicitly list allowed locations and keep the integration scope as narrow as possible.