SnowPro Advanced: Security Engineer Question 67
Select 2Configure and troubleshoot private connectivity and storage integrations:A security engineer is configuring a Snowflake external stage for sensitive data stored in an Amazon S3 bucket. The company requires that all access from Snowflake to S3 use private network paths only and that public internet access be disallowed. The engineer creates a storage integration, but attempts to query files from the stage fail with connectivity-related errors. During review, the engineer confirms that the IAM trust policy and allowed locations are correct. Which TWO actions should the engineer take to meet the requirement and resolve the issue?
- A
Configure outbound private connectivity for the Snowflake account to AWS using AWS PrivateLink so Snowflake can reach S3 without traversing the public internet
- B
Create the external stage with a storage integration that references the S3 bucket URL, then validate that the bucket can be reached through the configured private connectivity path
- C
Enable inbound private connectivity from the corporate VPC to Snowflake because external stage access to S3 depends on private client connections into Snowflake
- D
Add a network policy that only allows the corporate NAT gateway IPs, because network policies also control Snowflake egress traffic to cloud storage
- E
Grant the Snowflake service user broader S3 permissions on all buckets in the account, because private connectivity failures are typically caused by insufficient S3 privileges rather than networking
Show answer and explanation
Correct answers: A, B
Explanation
This scenario tests the distinction between storage authorization and network path security. A Snowflake storage integration handles delegated access to S3 through IAM, but it does not by itself guarantee private routing. When the requirement is that Snowflake access S3 without using the public internet, the engineer must configure Snowflake outbound private connectivity for the account and then use the storage integration in the external stage definition. Inbound private connectivity and network policies address client access to Snowflake, not Snowflake's outbound access to cloud storage. A least-privilege S3 policy remains important, but expanding permissions is not a fix for private connectivity issues. This aligns with Snowflake guidance for private connectivity and external access to cloud storage, where outbound private connectivity and correctly configured storage integrations are complementary controls.
- A. Correct.
Correct. For Amazon S3, meeting a requirement that Snowflake access cloud storage over private network paths requires configuring private outbound connectivity from Snowflake to the cloud provider. In AWS, this is done with AWS PrivateLink for outbound private connectivity. Without this, Snowflake may attempt to access S3 over public network paths even if the storage integration IAM configuration is correct.
- B. Correct.
Correct. The external stage must still be defined to use the storage integration and correct S3 URL, and after private connectivity is configured, the engineer should validate that the stage access works over that path. This reflects the practical troubleshooting sequence: confirm integration configuration, then confirm the storage location is reachable through the private connectivity setup.
- C. Incorrect.
Incorrect. Inbound private connectivity is used to let clients connect privately to Snowflake. It does not control Snowflake's outbound access from Snowflake to S3 for an external stage. This is a common confusion between client-to-Snowflake connectivity and Snowflake-to-storage connectivity.
- D. Incorrect.
Incorrect. Network policies restrict which client IP addresses can connect to Snowflake. They do not govern Snowflake egress traffic to external cloud storage. This distractor targets the misconception that network policies provide general network path control for all Snowflake traffic.
- E. Incorrect.
Incorrect. Broader S3 permissions do not solve a private connectivity requirement and would weaken security posture. Since the scenario already states the IAM trust policy and allowed locations are correct, expanding permissions is not the appropriate remediation. Connectivity errors in this case point to network path configuration, not authorization scope.