SnowPro Advanced: Security Engineer Question 256
Single answerManage interfaces for auditorsA financial services company must provide external auditors with read-only access to historical query activity and access history for a two-week review. The auditors must not be able to see business data in application schemas, and the security team wants to avoid creating custom tables or exporting logs. Which approach best meets these requirements with the least operational overhead?
- A
Create a dedicated AUDITOR role with USAGE on the SNOWFLAKE database and grant SELECT only on the ACCOUNT_USAGE views required for the review, such as QUERY_HISTORY and ACCESS_HISTORY.
- B
Grant the auditors the SECURITYADMIN role because it already has the privileges needed to inspect account activity without modifying application data.
- C
Create secure views in an application database that join business tables with audit metadata, then grant the auditors SELECT on those secure views.
- D
Export query history and access history into a temporary reporting table owned by SYSADMIN, then grant the auditors SELECT on that table for the duration of the review.
Show answer and explanation
Correct answer: A
Explanation
For auditor access, Snowflake best practice is to use built-in metadata interfaces rather than exposing administrative roles or creating custom audit repositories unless there is a specific reporting requirement. The SNOWFLAKE database contains shared system metadata, and ACCOUNT_USAGE provides read-only views for governance, monitoring, and audit use cases. Relevant views include QUERY_HISTORY for executed SQL activity and ACCESS_HISTORY for object access patterns, subject to Snowflake's documented latency characteristics. A dedicated auditor role with narrowly scoped privileges supports separation of duties, minimizes blast radius, and avoids exposing application data. This approach is consistent with least privilege and with Snowflake documentation on SNOWFLAKE.ACCOUNT_USAGE and secure role-based access control.
- A. Correct.
Correct. This is the most appropriate and least operationally expensive solution. Snowflake exposes audit-relevant metadata through the shared SNOWFLAKE database, including ACCOUNT_USAGE views such as QUERY_HISTORY and ACCESS_HISTORY. Granting a dedicated auditor role only the required USAGE and SELECT privileges provides read-only access to audit interfaces without exposing application schema data. This aligns with least-privilege design and avoids unnecessary data movement or custom objects.
- B. Incorrect.
Incorrect. SECURITYADMIN is a highly privileged administrative role intended for managing grants and roles, not for external audit review. Giving auditors this role would violate least-privilege principles and could allow privilege changes or visibility beyond what is required. The fact that it can inspect security-related configurations does not make it an appropriate interface for auditors.
- C. Incorrect.
Incorrect. Although secure views can limit data exposure, this option unnecessarily places audit access inside an application database and introduces business data into the design. The requirement explicitly states that auditors should not see application data and that the team wants to avoid creating custom tables or similar custom interfaces. Joining business tables with audit metadata increases risk and operational complexity.
- D. Incorrect.
Incorrect. Exporting audit logs into temporary or custom reporting tables adds operational overhead and creates another copy of sensitive metadata. It also requires ongoing maintenance, ownership management, and potentially warehouse usage for refresh processes. Since Snowflake already provides audit metadata interfaces through ACCOUNT_USAGE, creating derived tables is not the best-fit solution.