SnowPro Advanced: Security Engineer Question 263
Single answerTrack changes of the use of secure objects (for example, views, functions, and procedures)A financial services company uses secure views and secure UDFs to expose masked customer data to downstream analytics teams. The security engineering team must identify when these secure objects are used, who used them, and whether their definitions changed over time for audit purposes. They want the most reliable Snowflake-native approach with SQL-accessible history and minimal custom application code. Which solution best meets these requirements?
- A
Query ACCOUNT_USAGE.ACCESS_HISTORY and correlate it with QUERY_HISTORY and object metadata to see when secure objects were referenced, who queried them, and use SHOW/DESCRIBE or GET_DDL snapshots over time to detect definition changes.
- B
Query ACCOUNT_USAGE.LOGIN_HISTORY because it records every object a user accessed in a session, including secure views, secure functions, and stored procedures, along with the object definition at execution time.
- C
Enable Time Travel on the schema containing the secure objects and query historical versions of the secure view or secure function definitions directly from the past.
- D
Use ACCOUNT_USAGE.GRANTS_TO_USERS because grants history shows every time a secure object is executed and whether its SQL definition changed between executions.
Show answer and explanation
Correct answer: A
Explanation
For auditing secure object usage in Snowflake, the best native approach is to use ACCOUNT_USAGE views that capture query and access activity, especially ACCESS_HISTORY in combination with QUERY_HISTORY. ACCESS_HISTORY is designed for governance and lineage-style auditing of object access during query execution. QUERY_HISTORY complements this with execution context such as user, role, warehouse, and query text. However, Snowflake does not provide a built-in source-control-style version history for view, function, or procedure definitions in ACCOUNT_USAGE. Therefore, to track definition changes over time, a best practice is to regularly snapshot object definitions using metadata commands such as GET_DDL, SHOW, or DESCRIBE and store the results in an audit table or external version-control system. This combination satisfies the requirement to track both use and change history of secure objects with minimal custom application logic. Relevant Snowflake documentation areas include ACCESS_HISTORY, QUERY_HISTORY, ACCOUNT_USAGE, GET_DDL, and metadata commands for views, functions, and procedures.
- A. Correct.
Correct. ACCESS_HISTORY is the primary Snowflake-native source for auditing data access lineage and can help identify when underlying objects, including secure objects involved in query processing, were referenced. QUERY_HISTORY adds user, role, timing, and query context. For tracking definition changes over time, Snowflake does not provide a built-in full version history of view/UDF/procedure definitions in ACCOUNT_USAGE equivalent to source control, so a practical audit approach is to periodically capture metadata such as GET_DDL output or SHOW/DESCRIBE results and compare snapshots. This aligns with real-world audit patterns and uses SQL-accessible Snowflake metadata with minimal custom code.
- B. Incorrect.
Incorrect. LOGIN_HISTORY tracks authentication events such as successful and failed logins, client IP, and related session entry details. It does not provide per-object usage information for secure views, secure UDFs, or procedures, nor does it store object definitions at execution time. This is a common confusion between access auditing and authentication auditing.
- C. Incorrect.
Incorrect. Time Travel applies to data in supported table-like objects and allows querying historical data states, but it is not a mechanism for retrieving historical DDL versions of secure views, UDFs, or stored procedures as source-version snapshots. A candidate might choose this because Time Travel sounds like a general historical feature, but it does not solve object-definition change auditing for these secure objects.
- D. Incorrect.
Incorrect. GRANTS_TO_USERS shows privilege grants made to users and can support entitlement reviews, but it does not indicate each execution or usage event of a secure object. It also does not provide a history of SQL text changes to the object definition. This confuses permission state with runtime access activity and code-change tracking.