ARA-C01 Question 95
Single answerAzure Private LinkA company runs Snowflake on Azure and has a strict requirement that traffic from its analytics applications to Snowflake must stay on the Microsoft backbone and not traverse the public internet. The company already uses Azure Private Link for other internal services. An architect is asked to design private connectivity for users and applications connecting to Snowflake from Azure VNets in the same region. Which action should the architect recommend to meet this requirement?
- A
Create an Azure Private Endpoint in the customer VNet for the Snowflake account URL, configure the required private DNS resolution for the privatelink hostname, and have clients use the Snowflake privatelink connection URL.
- B
Deploy an Azure VPN Gateway and route client traffic from the VNet to Snowflake over an IPsec tunnel because Azure VPN automatically converts public SaaS endpoints into private routes.
- C
Use Azure Service Endpoints on the subnet hosting the application servers so Snowflake traffic remains private without requiring any DNS changes or endpoint-specific URLs.
- D
Place an Azure Application Gateway in front of Snowflake and publish an internal listener so application traffic reaches Snowflake privately through the gateway.
Show answer and explanation
Correct answer: A
Explanation
The correct design is to use Azure Private Link with a Private Endpoint mapped to the Snowflake account, along with the required private DNS configuration and Snowflake's private connectivity URL. This is the supported approach when an organization wants Azure-hosted clients to access Snowflake without traversing the public internet. A common misconception is that VPNs or Service Endpoints can be used for any private Azure access requirement; however, Snowflake's supported private connectivity model on Azure is Private Link. Another common error is forgetting that DNS and endpoint-specific account URLs are part of the implementation. Snowflake documentation for private connectivity on Azure and Microsoft documentation for Azure Private Link both emphasize the combination of Private Endpoint plus DNS resolution to the private endpoint IP as the core pattern.
- A. Correct.
Correct. For Snowflake on Azure, private connectivity is implemented using Azure Private Link. The customer creates a Private Endpoint to Snowflake's Private Link service, configures DNS so the Snowflake account resolves to the privatelink endpoint, and clients use the Snowflake privatelink URL/hostname as documented. This keeps traffic on the Azure/Microsoft private network rather than sending it over the public internet.
- B. Incorrect.
Incorrect. Azure VPN Gateway provides encrypted connectivity between networks, such as on-premises to Azure, but it does not transform a public SaaS endpoint like Snowflake into a private endpoint. Snowflake private access on Azure specifically uses Azure Private Link rather than customer-managed IPsec tunnels to Snowflake.
- C. Incorrect.
Incorrect. Azure Service Endpoints extend VNet identity to certain Azure platform services, but they are not the mechanism used for Snowflake private connectivity. Snowflake integrates with Azure Private Link, not Azure Service Endpoints. DNS updates and use of the private connectivity hostname are also important parts of the design.
- D. Incorrect.
Incorrect. Azure Application Gateway is a layer 7 load balancer and web application delivery service for customer-managed applications. It is not used to front Snowflake SaaS endpoints to create private network access. Introducing it here would add unnecessary complexity and would not provide the supported private connectivity model for Snowflake.