ARA-C01 Question 92
Single answerPrivate connectivityA financial services company runs Snowflake on AWS in the same region as its internal applications. Security policy requires that traffic from on-premises users and VPC-hosted applications to Snowflake must not traverse the public internet. The company already uses AWS Direct Connect to reach its VPCs from on premises and wants to minimize changes to application connection strings after the private design is implemented. Which approach best meets these requirements?
- A
Configure AWS PrivateLink for the Snowflake account, create the required interface endpoints in the customer VPC, connect on-premises networks through Direct Connect to that VPC, and use the account's private connectivity URL for clients.
- B
Use a SnowCD connectivity test over the existing public Snowflake URL and enforce TLS 1.2 so the connection is encrypted end to end without requiring any private networking changes.
- C
Deploy a self-managed reverse proxy in the VPC that forwards traffic to the public Snowflake endpoint, and keep using the existing public account URL to avoid any client changes.
- D
Create a site-to-site VPN from the data center directly to Snowflake's service-managed VPC so users can access the standard account URL over a private tunnel.
Show answer and explanation
Correct answer: A
Explanation
The best answer is to use Snowflake private connectivity with AWS PrivateLink. For AWS-hosted Snowflake accounts, private connectivity is designed so customer workloads access Snowflake through interface endpoints in their own VPCs, and on-premises environments can reach those endpoints through existing private network paths such as AWS Direct Connect. This satisfies the requirement that traffic not traverse the public internet. A key implementation detail is that clients use the Snowflake private connectivity URL/hostname rather than the standard public account URL, so some connection-string change is typically required. This is a common exam nuance: encryption alone is not equivalent to private connectivity, and unsupported patterns such as direct VPN into Snowflake-managed infrastructure should be ruled out. Refer to Snowflake documentation on private connectivity for AWS using AWS PrivateLink and the associated account URL requirements and endpoint setup guidance.
- A. Correct.
Correct. On AWS, Snowflake private connectivity is implemented with AWS PrivateLink. In this design, clients in the customer VPC reach Snowflake through interface endpoints, and on-premises users can traverse existing Direct Connect connectivity into that VPC. Clients must use Snowflake's private connectivity hostname/URL rather than the standard public account URL, which aligns with the requirement to minimize rather than eliminate connection-string changes. This is the supported pattern for avoiding internet traversal.
- B. Incorrect.
Incorrect. TLS encryption protects data in transit, but it does not make the network path private. Traffic to the public Snowflake URL still traverses public internet routes, which violates the stated requirement. SnowCD is a diagnostic tool and not a private connectivity solution.
- C. Incorrect.
Incorrect. A reverse proxy in the VPC may centralize egress, but if it forwards to Snowflake's public endpoint, the proxy-to-Snowflake leg still uses the public internet. It also adds operational overhead and is not the supported Snowflake private connectivity architecture for this requirement.
- D. Incorrect.
Incorrect. Customers do not create direct site-to-site VPNs into Snowflake's service-managed VPC for standard private connectivity. On AWS, the supported mechanism is PrivateLink. The standard public account URL is not the endpoint used for private connectivity.