ARA-C01 Question 91
Single answerPrivate connectivityA financial services company runs Snowflake on AWS in us-east-1 and must ensure that data engineers connect to Snowflake without traversing the public internet. The company already uses AWS Direct Connect to reach its VPCs and wants a design that minimizes internet exposure for both browser-based access to Snowsight and programmatic access from applications running in the VPC. Which architecture best meets these requirements?
- A
Create an AWS PrivateLink interface endpoint for Snowflake in the customer VPC, use the account's private connectivity URL for client connections, and ensure DNS is configured so users and applications resolve Snowflake to the private endpoint.
- B
Use AWS Direct Connect alone because it provides private connectivity to all AWS services, including Snowflake, without requiring any Snowflake-specific private endpoint configuration.
- C
Deploy a site-to-site VPN to the Snowflake VPC and route Snowsight and application traffic through the VPN so the company can avoid public internet exposure.
- D
Use a public Snowflake URL protected by a network policy that only allows the company's NAT gateway public IPs, because restricting source IPs makes the connection private.
Show answer and explanation
Correct answer: A
Explanation
The best answer is to use AWS PrivateLink with Snowflake's private connectivity configuration. In Snowflake, private connectivity requires cloud-provider-specific private endpoint services and Snowflake-provided private URLs/hostnames. On AWS, Direct Connect can be part of the enterprise network path into the customer's VPC, but it does not replace PrivateLink for private Snowflake access. Network policies are useful additional controls, but they do not convert public endpoints into private ones. This aligns with Snowflake best practices for private connectivity: use the cloud provider's private endpoint technology, configure DNS correctly, and connect clients to the Snowflake private endpoint/URL for supported interfaces such as drivers, connectors, and Snowsight where applicable.
- A. Correct.
Correct. On AWS, Snowflake private connectivity is implemented with AWS PrivateLink. Customers create interface endpoints in their own VPC and use Snowflake-provided private connectivity URLs/endpoints for supported services. This allows traffic from applications in the VPC to reach Snowflake without using public internet paths. For browser-based access such as Snowsight, private connectivity also depends on using the appropriate private URL and DNS resolution so clients reach the private endpoint rather than the public hostname. This is the standard pattern for private access to Snowflake on AWS.
- B. Incorrect.
Incorrect. AWS Direct Connect provides private network transport into AWS, but it does not by itself create private connectivity to Snowflake. Snowflake is not automatically reachable privately just because the customer has Direct Connect into a VPC. You still need Snowflake private connectivity using AWS PrivateLink and the corresponding Snowflake private URL/endpoints. A common misconception is that Direct Connect alone makes every SaaS or AWS-hosted service private.
- C. Incorrect.
Incorrect. Customers do not establish a customer-managed VPN directly into a Snowflake VPC for Snowflake private connectivity. Snowflake private access on AWS is achieved through AWS PrivateLink, not by routing traffic through a site-to-site VPN into Snowflake's environment. This distractor targets the misconception that any private tunnel to AWS can be used to connect directly to Snowflake infrastructure.
- D. Incorrect.
Incorrect. Limiting access to public Snowflake endpoints with a network policy improves security posture by restricting allowed source IP addresses, but the connection still uses a public endpoint and is not considered private connectivity. Network policies and private connectivity address different concerns: source restriction versus eliminating public internet exposure.