ARA-C01 Question 96
Select 2Azure Private LinkA financial services company runs Snowflake on Microsoft Azure and must ensure that traffic from an internal analytics application in Azure to Snowflake never traverses the public internet. The application is deployed in a hub-and-spoke virtual network topology across multiple subscriptions. The security team also wants to minimize operational overhead for DNS management and avoid exposing Snowflake through public endpoints. Which TWO actions should the architect take to meet these requirements?
- A
Create an Azure Private Endpoint for the Snowflake account in a VNet reachable from the application, and configure private DNS resolution so the Snowflake account URL resolves to the private IP address.
- B
Disable public network access to the Snowflake account after validating that all required clients resolve and connect through the Azure Private Link endpoint.
- C
Create a service endpoint for Azure Storage in each spoke VNet so the application can reach Snowflake without using public internet paths.
- D
Configure SnowCD to replace Azure Private Link, because SnowCD provides a private transport mechanism for Snowflake connectivity.
- E
Publish the Snowflake account URL through Azure Application Gateway with a public frontend IP and use WAF rules to restrict inbound traffic.
Show answer and explanation
Correct answers: A, B
Explanation
For Snowflake on Azure, the correct pattern for private, non-public connectivity is Azure Private Link via a Private Endpoint, combined with DNS configuration so Snowflake account hostnames resolve to private IP addresses. In real deployments, DNS is often the deciding factor between a successful and failed Private Link implementation, especially in hub-and-spoke architectures and multi-subscription environments. If the organization also wants to prevent any public-path access, the architect should disable public network access only after validating that all required users, applications, and supporting services are functional over the private path. Azure service endpoints do not replace Private Link for Snowflake, and SnowCD is for testing rather than transport. Relevant guidance is covered in Snowflake documentation for Azure Private Link and private connectivity, along with Microsoft Azure documentation for Private Endpoint and private DNS zone integration.
- A. Correct.
Correct. Azure Private Link for Snowflake requires creating a Private Endpoint in the customer's Azure VNet and ensuring DNS resolves the Snowflake hostname to the endpoint's private IP address. Without correct DNS integration, clients may continue resolving to the public endpoint and bypass the intended private connectivity path. In a hub-and-spoke design, this often means linking the relevant private DNS zone or forwarding DNS appropriately across VNets and subscriptions.
- B. Correct.
Correct. If the requirement is to avoid exposing Snowflake through public endpoints, disabling public network access is the appropriate hardening step after private connectivity is confirmed. This prevents clients from connecting over the public Snowflake endpoint and enforces the use of Azure Private Link. The sequencing matters: validate private endpoint connectivity and DNS first to avoid unintentionally cutting off access.
- C. Incorrect.
Incorrect. Azure service endpoints for Azure Storage are unrelated to private connectivity from the application to the Snowflake service endpoint. Snowflake connectivity over Azure Private Link uses Azure Private Endpoint/Private Link, not Azure service endpoints. This option reflects a common confusion between service endpoints and Private Link.
- D. Incorrect.
Incorrect. SnowCD is a diagnostic utility used to test connectivity and help troubleshoot network paths to Snowflake. It does not provide or replace a private networking transport such as Azure Private Link. Someone might choose this if they know SnowCD is used in connectivity scenarios, but it is not a networking solution.
- E. Incorrect.
Incorrect. Publishing Snowflake through Azure Application Gateway with a public frontend does not satisfy the requirement to keep traffic off the public internet and avoid public exposure. Even with WAF protections, the endpoint remains publicly reachable. This option is a plausible security control, but it does not meet the stated private connectivity requirement.