SnowPro Advanced: Security Engineer Question 33
Single answerSnowflake-managed MFAA company uses native Snowflake usernames and passwords for several hundred contractors who access Snowsight and the Classic Console. The security team wants to reduce account takeover risk by requiring MFA, but they do not want to integrate an external identity provider yet. They also want to avoid disrupting service accounts used for automated workloads. Which approach should the Snowflake security engineer recommend to meet these requirements?
- A
Enable Snowflake-managed MFA for the human users who authenticate directly with Snowflake, and keep service accounts on non-interactive authentication methods such as key-pair authentication instead of MFA.
- B
Configure network policies to require MFA for all connections, including JDBC and service accounts, because Snowflake-managed MFA is enforced through network rules.
- C
Enable Tri-Secret Secure so that users logging in with username and password are prompted for a second factor without needing an external identity provider.
- D
Use programmatic access tokens for all contractor users so that Snowflake-managed MFA is not needed, while continuing to use passwords for service accounts.
Show answer and explanation
Correct answer: A
Explanation
The best recommendation is to use Snowflake-managed MFA for human users who sign in directly to Snowflake with native credentials, while excluding automated service accounts from MFA and moving them to appropriate non-interactive authentication methods. This approach aligns with Snowflake security best practices: MFA should protect interactive user access, and service accounts should avoid password-based authentication where possible. Snowflake-managed MFA is specifically intended for organizations that are not using federated authentication through an external identity provider. It applies to supported interactive login experiences rather than being a general-purpose control for all programmatic clients. Relevant Snowflake documentation and guidance cover Snowflake-managed MFA, native authentication, and recommended authentication methods for service users, including key-pair authentication and OAuth where applicable.
- A. Correct.
Correct. Snowflake-managed MFA is designed for users who authenticate directly to Snowflake with native username/password sign-in, such as through Snowsight or the Classic Console. This fits the requirement to add MFA without deploying an external IdP. For non-human or automated service accounts, MFA is generally not appropriate because those accounts should use non-interactive authentication methods such as key-pair authentication or OAuth-based flows, depending on the workload design. This avoids breaking automation while improving security for interactive users.
- B. Incorrect.
Incorrect. Network policies restrict where users can connect from by IP or network identifier; they do not serve as the mechanism to require MFA. Snowflake-managed MFA is not enforced by network policies, and service accounts using JDBC or other drivers are not made MFA-capable through a network rule. This option confuses network access controls with authentication controls.
- C. Incorrect.
Incorrect. Tri-Secret Secure is a data protection feature related to encryption key management, not user authentication. It does not prompt for a second factor and has no role in enabling MFA for native Snowflake logins. This distractor reflects a common misconception that any advanced security feature can be used to strengthen login controls.
- D. Incorrect.
Incorrect. Replacing interactive contractor access with programmatic tokens is not a practical or recommended substitute for MFA in this scenario. Contractors using Snowsight and the Classic Console are human users and should use an interactive authentication mechanism with MFA. Also, continuing to use passwords for service accounts is poor practice compared with key-pair authentication or another non-interactive method.