ADA-C01 Question 87
Single answerReport on users who do not have MFA enabledA security administrator needs to produce a weekly report of all Snowflake users in the account who can still sign in with a password but have not enrolled in multi-factor authentication (MFA). The report must be generated using SQL and should rely on account metadata rather than manually inspecting individual users. Which approach best meets this requirement?
- A
Query SNOWFLAKE.ACCOUNT_USAGE.USERS and filter for users where HAS_PASSWORD = TRUE and HAS_MFA = FALSE.
- B
Run SHOW USERS and filter the results for users where DISABLED = FALSE, because active users without MFA are implied by enabled accounts.
- C
Query INFORMATION_SCHEMA.USERS and filter for LOGIN_NAME is not null and TYPE = 'PERSON', because only person users can be required to use MFA.
- D
Use DESCRIBE USER for every user and infer MFA enrollment by checking whether a public key is configured.
Show answer and explanation
Correct answer: A
Explanation
The best solution is to query SNOWFLAKE.ACCOUNT_USAGE.USERS and filter on HAS_PASSWORD = TRUE and HAS_MFA = FALSE. This matches the real-world administrative need to identify password-based users who have not enrolled in MFA. ACCOUNT_USAGE is designed for centralized reporting and governance use cases and exposes user-level metadata suitable for scheduled SQL reports. By contrast, SHOW USERS is more operational and not ideal for durable reporting logic, and fields such as DISABLED, LOGIN_NAME, TYPE, or public key configuration do not indicate MFA enrollment. Snowflake documentation for the ACCOUNT_USAGE.USERS view documents user security-related columns such as HAS_PASSWORD and HAS_MFA, which are the correct basis for this report.
- A. Correct.
Correct. The ACCOUNT_USAGE.USERS view is the appropriate metadata source for account-level SQL reporting on user properties. The relevant columns include HAS_PASSWORD and HAS_MFA, which allow an administrator to identify users who authenticate with a password but have not enrolled in MFA. This directly supports the requirement to generate a weekly SQL-based report from metadata.
- B. Incorrect.
Incorrect. SHOW USERS returns user metadata, but DISABLED only indicates whether the user account is disabled. It does not imply anything about MFA enrollment. An enabled user might still have MFA enabled or disabled, so filtering on DISABLED cannot accurately identify users missing MFA.
- C. Incorrect.
Incorrect. INFORMATION_SCHEMA is not the best source for this requirement, and filtering on LOGIN_NAME or TYPE does not determine MFA enrollment. Even if a user is a person user with a login name, that does not indicate whether MFA is configured. The key requirement is specifically to report on MFA status, which is exposed in ACCOUNT_USAGE.USERS via HAS_MFA.
- D. Incorrect.
Incorrect. DESCRIBE USER can show details for a specific user, but using it iteratively for every user is operationally inefficient and does not meet the requirement to use account metadata for reporting. In addition, public key configuration relates to key-pair authentication, not MFA enrollment, so it is not a valid proxy for MFA status.