SnowPro Advanced: Security Engineer Question 241
Single answerValidate the secure client redirection configurationsA security engineer is validating Secure Client Redirect for a business-critical Snowflake account after a regional failover test. The team wants to confirm that users connecting with the account identifier can be safely redirected to the new region without weakening TLS security controls. Which action provides the most reliable validation that Secure Client Redirect is configured correctly and securely for supported clients?
- A
Run SYSTEM$GET_PRIVATELINK_CONFIG for the account and confirm the returned endpoints reference the target region.
- B
Connect using a supported Snowflake driver or connector with the account identifier, verify the connection succeeds after failover, and confirm the client is redirected to the account's current region endpoint while certificate validation remains successful.
- C
Use the organization name and account name in the URL and confirm the browser automatically rewrites the hostname to the target region, because Secure Client Redirect is only validated through Snowsight.
- D
Disable OCSP checks temporarily on the client and confirm the login succeeds against the old region endpoint, because successful authentication proves the redirect policy is active.
Show answer and explanation
Correct answer: B
Explanation
Secure Client Redirect is designed to allow supported Snowflake clients to connect using the account identifier and be redirected to the account's current region endpoint, such as after replication/failover scenarios. To validate it properly, the engineer should test with a supported driver, connector, or client configured to use the account identifier instead of a region-specific URL. The validation is successful when the client can connect after failover, follows the redirect to the new active region, and still completes normal TLS certificate validation. Best practice is to avoid hard-coded region endpoints in client configurations when relying on Secure Client Redirect. It is also important not to weaken TLS protections, such as disabling OCSP or certificate checks, because the purpose of the validation is to confirm secure redirection under normal security controls. Snowflake documentation on Secure Client Redirect and client connectivity best practices supports using supported clients and account identifiers for this validation.
- A. Incorrect.
Incorrect. SYSTEM$GET_PRIVATELINK_CONFIG is used for PrivateLink-related configuration details, not to validate Secure Client Redirect behavior. A region endpoint appearing in PrivateLink metadata does not prove that supported clients using the account identifier are being securely redirected after failover.
- B. Correct.
Correct. The practical way to validate Secure Client Redirect is to test with a supported Snowflake client that connects using the account identifier rather than a hard-coded region-specific hostname. After failover, the client should successfully connect and be redirected to the account's current region endpoint. Certificate validation must still succeed, confirming TLS trust is preserved during redirection. This directly validates both functionality and the security expectation.
- C. Incorrect.
Incorrect. Secure Client Redirect is not something validated only through Snowsight or browser hostname rewriting. The feature is intended for supported Snowflake clients, drivers, and connectors using the account identifier. Assuming browser behavior alone proves redirect configuration is a common misconception.
- D. Incorrect.
Incorrect. Disabling OCSP or weakening certificate validation is not an acceptable validation method for a security feature. Successful login with relaxed TLS checks does not demonstrate that Secure Client Redirect is securely configured. In fact, it undermines the goal of validating secure redirection and proper certificate validation.