SnowPro Advanced: Security Engineer Question 71
Single answerTroubleshoot private connectivity issuesA company uses AWS PrivateLink to provide private connectivity from its VPC to Snowflake. After a network change, users can no longer sign in through the private Snowflake URL, but the public Snowflake URL still works from the same client hosts. The security engineer confirms that the AWS interface endpoint for Snowflake exists and is in the Available state. To isolate the issue, the engineer wants to identify the most likely cause of the private connectivity failure. Which action should the engineer take FIRST?
- A
Verify that the private DNS record for the Snowflake account URL resolves to the IP addresses of the AWS interface endpoint inside the VPC
- B
Rotate the key pair used by users for Snowflake authentication because stale credentials can block PrivateLink connections
- C
Recreate the Snowflake account because private connectivity settings are immutable after initial account provisioning
- D
Grant the SECURITYADMIN role to affected users so they can access the account through the private endpoint
- E
Change the Snowflake network policy to allow all public IP addresses so the private endpoint can complete the TLS handshake
Show answer and explanation
Correct answer: A
Explanation
For Snowflake private connectivity on AWS using PrivateLink, a frequent root cause of failed private access is incorrect DNS configuration. The interface endpoint can exist and be healthy, yet clients will still fail if the Snowflake private account URL does not resolve privately inside the VPC or connected network. In troubleshooting, confirm that the private hostname resolves to the interface endpoint's private IPs and that internal DNS forwarding or Route 53 private hosted zone associations are correct. This aligns with Snowflake private connectivity guidance: successful private access depends not only on the cloud endpoint object but also on proper DNS mapping to the account's private URL and valid network pathing. Authentication roles, user credentials, and broad public network policy changes do not address the underlying issue when the public URL continues to work but the private URL does not.
- A. Correct.
Correct. When public access still works but the private URL fails, DNS resolution is one of the first things to verify. With AWS PrivateLink, clients must resolve the Snowflake private hostname to the private IPs associated with the interface endpoint, typically through a private hosted zone or equivalent internal DNS configuration. If DNS still resolves to the public Snowflake service address, traffic will bypass the private endpoint and the private URL connection will fail or behave unexpectedly. This is a common real-world failure after VPC, Route 53, or resolver changes.
- B. Incorrect.
Incorrect. User authentication credentials such as key pairs affect identity verification after network connectivity is established. They do not determine whether traffic can reach Snowflake through AWS PrivateLink. Because the public URL still works, the symptom points to private network path or DNS resolution rather than stale authentication material.
- C. Incorrect.
Incorrect. Snowflake accounts do not need to be recreated to troubleshoot or restore private connectivity. This option reflects a misconception that private connectivity is permanently fixed at account creation. In practice, troubleshooting typically focuses on endpoint configuration, DNS, allowed principals or endpoint authorization, and routing or resolver settings.
- D. Incorrect.
Incorrect. Granting SECURITYADMIN affects authorization inside Snowflake, not network reachability to a private endpoint. If users cannot even sign in through the private URL, changing their Snowflake role grants will not resolve the connectivity problem. This distractor targets confusion between access control and network connectivity.
- E. Incorrect.
Incorrect. Network policies govern which client IP addresses may connect to Snowflake, but they do not make a private endpoint complete TLS successfully. Also, allowing all public IPs would weaken security and is not the first troubleshooting step when only the private URL is failing. The more likely root cause is that the private hostname is not resolving to the interface endpoint correctly.