SnowPro Advanced: Security Engineer Question 233
Single answerRe-establish security configurations for external resources, for example trust relationships for external stagesA company uses a Snowflake storage integration for an S3 external stage that loads regulated data. During an AWS security review, the IAM role used by the integration was deleted and recreated with a new role ARN. After the change, COPY INTO commands from the external stage fail with access errors. The Snowflake engineer must re-establish the trust relationship with the least operational disruption while maintaining the existing stage design. What should the engineer do?
- A
Create a new storage integration that points to the new IAM role, and recreate all external stages that use the original integration.
- B
Use DESC INTEGRATION to retrieve the Snowflake IAM user and external ID for the existing storage integration, update the AWS IAM role trust policy to trust that Snowflake principal with the required external ID, and ensure the integration references the current role ARN.
- C
Grant USAGE on the external stage to the loading role again, because access errors after IAM changes usually indicate missing Snowflake object privileges rather than a broken cloud trust relationship.
- D
Run ALTER STAGE to set new AWS key ID and secret key credentials directly on the stage so Snowflake no longer depends on the storage integration trust relationship.
Show answer and explanation
Correct answer: B
Explanation
When an external stage uses an S3 storage integration, access depends on a trust relationship between Snowflake and an AWS IAM role. If that IAM role is deleted and recreated, the trust policy and sometimes the referenced role ARN must be revalidated. The practical recovery path is to inspect the existing integration with DESCRIBE INTEGRATION, obtain the Snowflake-generated IAM user and external ID, and update the AWS IAM role trust relationship so Snowflake can assume the role again. If the role ARN changed, the storage integration must point to the current ARN. This approach aligns with Snowflake best practices for storage integrations and least-privilege access, while avoiding unnecessary recreation of stages. Relevant Snowflake documentation includes topics on CREATE/ALTER STORAGE INTEGRATION, DESCRIBE INTEGRATION, and configuring an Amazon S3 storage integration, including the AWS trust policy and external ID requirements.
- A. Incorrect.
This is unnecessary and more disruptive than required. If the stage design already uses a storage integration, the preferred approach is to repair the integration and the cloud-side trust relationship rather than replacing the integration and recreating dependent stages. Recreating stages increases change scope and operational risk.
- B. Correct.
This is correct. For an S3 storage integration, Snowflake exposes values such as the Snowflake IAM user and external ID via DESCRIBE INTEGRATION. In AWS, the IAM role trust policy must allow that Snowflake principal to assume the role and typically require the matching external ID. If the AWS role was recreated, the integration must also reference the valid current role ARN. This restores the trust relationship with minimal disruption and preserves the existing stage architecture.
- C. Incorrect.
This is incorrect. Although stage privileges are required for users and roles to access a stage, the scenario specifically describes failure after an AWS IAM role was deleted and recreated. That points to a broken cloud trust relationship, not a missing Snowflake grant. Regranting stage privileges would not repair AWS AssumeRole trust.
- D. Incorrect.
This is incorrect. Storage integrations are the recommended mechanism for securing S3 external stages because they avoid embedding long-lived cloud credentials in stage definitions. Switching to direct key-based credentials is not a best practice and does not address the intended trust model. In many regulated environments, this would weaken the security posture rather than re-establish it.