DAA-C01 Question 63
Single answerAuditingA financial analytics team must prove to auditors that no one has directly queried a sensitive table containing cardholder data during the last 90 days, except through an approved BI service role. The team needs a solution that can be run regularly by analysts without exporting logs to another system. Which approach best meets this requirement in Snowflake?
- A
Query the ACCOUNT_USAGE.ACCESS_HISTORY view to identify direct object access to the sensitive table, then join to QUERY_HISTORY and filter out queries executed under the approved BI service role.
- B
Query the ACCOUNT_USAGE.LOGIN_HISTORY view for users who logged in during the last 90 days, then compare that list to users with SELECT privilege on the sensitive table.
- C
Use SHOW GRANTS ON TABLE for the sensitive table and assume any role without SELECT privilege could not have queried the table in the last 90 days.
- D
Query the INFORMATION_SCHEMA.TABLES view to check LAST_ALTERED for the sensitive table and use that timestamp to infer whether users queried it directly.
Show answer and explanation
Correct answer: A
Explanation
For Snowflake auditing of who accessed sensitive data, ACCOUNT_USAGE.ACCESS_HISTORY is the key native source because it records object access associated with executed queries. In a real audit scenario, analysts commonly combine ACCESS_HISTORY with ACCOUNT_USAGE.QUERY_HISTORY to add user, role, query text, and timing context. This supports evidence-based validation that access happened only through an approved service role. By contrast, LOGIN_HISTORY answers who authenticated, SHOW GRANTS answers who is authorized, and TABLES/LAST_ALTERED reflects object changes rather than reads. Snowflake documentation on Account Usage views and access history supports using ACCESS_HISTORY for governance, lineage, and audit investigations involving direct object access.
- A. Correct.
Correct. ACCESS_HISTORY is designed for auditing data access at the object and column level and can show whether the sensitive table was directly accessed by queries. Joining it with QUERY_HISTORY provides query context such as role, user, and SQL text, allowing the analysts to verify that access occurred only through the approved BI service role. This is the most appropriate native Snowflake approach for ongoing auditing without relying on an external log platform.
- B. Incorrect.
Incorrect. LOGIN_HISTORY shows authentication events, not whether a user actually queried a specific table. A user may log in and never access the sensitive object, and a user with access could also run queries through different roles. This option confuses authentication auditing with data access auditing.
- C. Incorrect.
Incorrect. SHOW GRANTS indicates current privileges, not historical usage. Auditors are asking who actually queried the sensitive table over the last 90 days, not who could potentially query it. Privilege metadata alone cannot prove whether direct access occurred.
- D. Incorrect.
Incorrect. INFORMATION_SCHEMA.TABLES and the LAST_ALTERED field relate to table metadata changes, not read access. A table can be queried many times without changing LAST_ALTERED. This option reflects a common misunderstanding between object modification metadata and access audit records.