ADA-C01 Question 88
Single answerReport on users who do not have MFA enabledA Snowflake account administrator must produce a weekly audit report listing all human users who can sign in with a password but do not have multi-factor authentication (MFA) enrolled. The admin wants a solution that uses Snowflake metadata rather than manually checking each user in Snowsight. Which approach should the administrator use?
- A
Query the ACCOUNT_USAGE.USERS view and filter for users where HAS_PASSWORD = TRUE and HAS_MFA = FALSE, excluding disabled or service users as needed.
- B
Run SHOW USERS and use the DEFAULT_ROLE column to identify users who do not have MFA enabled.
- C
Query LOGIN_HISTORY and return users who have successful logins without a CLIENT_APPLICATION_ID value; those users do not have MFA enabled.
- D
Use DESCRIBE USER for every user and check whether the RSA_PUBLIC_KEY field is null; if it is null, the user does not have MFA enabled.
Show answer and explanation
Correct answer: A
Explanation
To report on users who do not have MFA enabled, the best practice is to use Snowflake metadata designed for account auditing rather than inferring status from login events or unrelated user properties. The ACCOUNT_USAGE.USERS view provides explicit user-level attributes including HAS_PASSWORD and HAS_MFA, which makes it the most appropriate source for this report. In a real-world audit, administrators typically focus on interactive human users who authenticate with passwords, so filtering on HAS_PASSWORD = TRUE and HAS_MFA = FALSE is a practical starting point, with additional exclusions for disabled, deleted, or non-human accounts according to policy. This aligns with Snowflake guidance to use ACCOUNT_USAGE views for governance and reporting, and to use direct metadata fields rather than indirect indicators such as default roles, login client details, or RSA key configuration.
- A. Correct.
Correct. The ACCOUNT_USAGE.USERS view is the appropriate metadata source for account-level user reporting. It includes columns such as HAS_PASSWORD and HAS_MFA, which allow an administrator to identify users who can authenticate with a password but have not enrolled in MFA. In practice, administrators often also exclude users that are disabled, deleted, or clearly service-oriented accounts depending on internal policy.
- B. Incorrect.
Incorrect. SHOW USERS returns useful user metadata, but the DEFAULT_ROLE column has nothing to do with MFA status. Choosing this option reflects a common misconception that role configuration or session defaults indicate authentication posture. They do not.
- C. Incorrect.
Incorrect. LOGIN_HISTORY can help analyze authentication events, but it is not a reliable source for determining whether a user is enrolled in MFA. CLIENT_APPLICATION_ID identifies the client or driver used and does not indicate MFA enrollment status. A user could log in through many client types regardless of MFA configuration.
- D. Incorrect.
Incorrect. RSA_PUBLIC_KEY is related to key-pair authentication, not MFA enrollment. A null RSA_PUBLIC_KEY only means that key-pair authentication is not configured for that user. Users can still have MFA enabled or disabled independently of RSA key settings.