ARA-C01 Question 93
Single answerAWS PrivateLinkA financial services company runs Snowflake on AWS and has a policy that all traffic between its analytics applications and Snowflake must remain on the AWS private network and must not traverse the public internet. The company has already established AWS PrivateLink connectivity for users in us-east-1. It is now deploying a new VPC in the same region for a separate line of business and wants those applications to connect privately to the same Snowflake account with minimal administrative effort. Which action should the Snowflake architect recommend?
- A
Create an additional AWS PrivateLink endpoint in the new VPC that targets the Snowflake private service, and ensure the account has the corresponding private connectivity configuration enabled for that VPC.
- B
Reuse the existing interface VPC endpoint from the original VPC because AWS PrivateLink endpoints are automatically reachable from all VPCs in the same region.
- C
Set up VPC peering between the two VPCs and route traffic from the new VPC through the existing PrivateLink endpoint in the original VPC.
- D
Configure a public Route 53 hosted zone that resolves the Snowflake account URL to the existing endpoint so the new VPC can access Snowflake without creating another endpoint.
Show answer and explanation
Correct answer: A
Explanation
For Snowflake on AWS, PrivateLink provides private connectivity by using interface VPC endpoints in the customer's VPC to reach Snowflake services over the AWS backbone rather than the public internet. A key architectural point is that interface endpoints are deployed per VPC. If another VPC needs private access to the same Snowflake account, the standard approach is to create a separate endpoint in that VPC and complete the related Snowflake private connectivity configuration. This is consistent with AWS PrivateLink behavior and Snowflake's documented private connectivity patterns. Architects should avoid assuming that one VPC endpoint can be transparently reused across multiple VPCs, and they should not rely on public DNS changes to meet a private-network-only requirement.
- A. Correct.
Correct. AWS PrivateLink interface endpoints are created per VPC and are not automatically shared across unrelated VPCs. To provide private connectivity from a second VPC, the architect should create a new interface endpoint in that VPC for the Snowflake service and associate it with the Snowflake private connectivity setup for the account. This aligns with the standard Snowflake PrivateLink architecture on AWS, where each participating VPC requires its own endpoint.
- B. Incorrect.
Incorrect. This reflects a common misconception. An interface VPC endpoint is not automatically reachable from every VPC in the region. It is scoped to the VPC and subnets where it is created. Without additional architecture, workloads in another VPC cannot simply use that endpoint directly.
- C. Incorrect.
Incorrect. VPC peering does not make an interface endpoint in one VPC a supported shared access point for another VPC in the way described. Even if some routing patterns exist for other resources, the recommended Snowflake design is to provision a separate PrivateLink endpoint in each VPC requiring private access. Using peering to centralize access adds complexity and does not match the standard Snowflake private connectivity model.
- D. Incorrect.
Incorrect. Creating or modifying public DNS does not satisfy the requirement to keep traffic off the public internet. Public DNS resolution to an endpoint does not replace the need for a PrivateLink endpoint in the consuming VPC. Snowflake private connectivity relies on the correct private endpoint and DNS configuration, not on exposing or remapping the account URL through public DNS.