DAA-C01 Question 64
Single answerAuditingA data analyst needs to investigate whether a sensitive finance table was queried outside of normal business hours during the last 14 days. The analyst does not have ACCOUNTADMIN and should avoid requesting broad administrative access. Which Snowflake approach best meets this auditing requirement while following least-privilege principles?
- A
Query the SNOWFLAKE.ACCOUNT_USAGE.ACCESS_HISTORY view for records referencing the finance table, and grant the analyst a role with imported privileges on the SNOWFLAKE database plus only the required object privileges to resolve the table name.
- B
Query INFORMATION_SCHEMA.TABLES for the finance table and use LAST_ALTERED to determine when users last queried it.
- C
Review the QUERY_HISTORY table function only, because it directly lists all base tables touched by each query without needing any additional audit views.
- D
Enable object tagging on the finance table and use tag history to determine which users accessed the table after hours.
Show answer and explanation
Correct answer: A
Explanation
For auditing table access in Snowflake, ACCESS_HISTORY is the key source because it provides object-level access records tied to queries, which is more suitable than relying on query text or table metadata. This is especially important when users access data through views or more complex SQL patterns. QUERY_HISTORY can complement the investigation by adding user, warehouse, and execution details, but it is not the primary object-access audit source for this requirement. INFORMATION_SCHEMA views describe metadata, not access events, and tags are for governance rather than user access logging. In practice, administrators commonly expose the SNOWFLAKE shared database to audit users through a dedicated role with IMPORTED PRIVILEGES, supporting least-privilege access to account usage data without granting broad administrative roles. Relevant Snowflake documentation includes Account Usage views such as ACCESS_HISTORY and QUERY_HISTORY, as well as guidance on granting imported privileges on the SNOWFLAKE database.
- A. Correct.
Correct. ACCESS_HISTORY in the shared SNOWFLAKE database is designed for object-level auditing and can show which base objects were accessed by queries, including tables referenced indirectly through views. This is the appropriate source when the requirement is to determine whether a specific table was queried during a time window. To let a non-ACCOUNTADMIN analyst perform this work under least privilege, an administrator can grant IMPORTED PRIVILEGES on the SNOWFLAKE database to a dedicated role and provide only the necessary usage/select permissions on relevant objects in the customer account to interpret results. This avoids broad admin rights while enabling audit analysis.
- B. Incorrect.
Incorrect. INFORMATION_SCHEMA.TABLES contains metadata about tables, and LAST_ALTERED reflects DDL or certain metadata changes, not query access by end users. A table can be queried many times without changing LAST_ALTERED. This is a common misconception when trying to infer access from object metadata.
- C. Incorrect.
Incorrect. QUERY_HISTORY is useful for reviewing executed SQL statements, users, roles, timing, and status, but by itself it is not the best source for reliable object-level lineage of all tables touched by a query. Parsing SQL text is error-prone, and queries through views may not clearly expose base table access. ACCESS_HISTORY is the more appropriate auditing source for determining whether a specific table was accessed.
- D. Incorrect.
Incorrect. Tags classify and govern objects; they do not record per-user query access. Tag-related history can help audit changes to tags or support governance workflows, but it does not answer who queried a table and when. This distractor targets confusion between governance metadata and access auditing.