SnowPro Advanced: Security Engineer Question 262
Single answerTrack changes of the use of secure objects (for example, views, functions, and procedures)A security engineer at a healthcare company needs to audit how a secure view and a secure user-defined function (UDF) are being used across the account. The team specifically wants to know which queries referenced these secure objects, who ran those queries, and when they occurred. The solution must rely on native Snowflake metadata rather than custom logging added to every consumer workload. Which approach best meets this requirement?
- A
Query the ACCOUNT_USAGE.ACCESS_HISTORY view and inspect the base_objects_accessed and objects_modified columns to identify queries that referenced the secure view or secure UDF, then correlate with query metadata such as user and time.
- B
Use SHOW SECURE VIEWS and SHOW USER FUNCTIONS to retrieve historical usage details for each secure object, including the user and timestamp of every invocation.
- C
Query INFORMATION_SCHEMA.OBJECT_PRIVILEGES to determine when secure objects were used, because privilege metadata records each runtime access event for views and functions.
- D
Review ACCOUNT_USAGE.GRANTS_TO_ROLES to identify which roles had access to the secure objects, then infer actual usage from the grant history without querying access telemetry.
Show answer and explanation
Correct answer: A
Explanation
To track changes in the use of secure objects, the key distinction is between entitlement metadata and access telemetry. Snowflake's ACCOUNT_USAGE.ACCESS_HISTORY is the native auditing source for understanding which queries accessed which objects. For secure views and secure functions, this enables investigation of object usage patterns without modifying application code to emit custom logs. In contrast, SHOW commands and INFORMATION_SCHEMA or grant-history views describe objects and privileges, not actual usage events. Best practice is to use ACCESS_HISTORY for query-level access auditing and correlate it with query metadata from Snowflake account usage views when user identity, time, and execution context are required. This aligns with Snowflake documentation for auditing data access and analyzing object-level access history.
- A. Correct.
Correct. ACCOUNT_USAGE.ACCESS_HISTORY is the native Snowflake source designed for analyzing object access by query. It can be used to determine which queries accessed specific objects and provides access lineage details through semi-structured columns such as base_objects_accessed. By combining this with query-related metadata available in Snowflake account usage views, a security engineer can identify who executed the query and when. This is the most appropriate native method for tracking use of secure objects such as secure views and secure UDFs.
- B. Incorrect.
Incorrect. SHOW SECURE VIEWS and SHOW USER FUNCTIONS return object definitions and metadata about the objects themselves, not an audit trail of each usage event. They are useful for inventory and administration, but they do not provide per-query historical invocation details such as user, query, and timestamp.
- C. Incorrect.
Incorrect. INFORMATION_SCHEMA.OBJECT_PRIVILEGES shows granted privileges on objects, not actual runtime access events. A common misconception is to confuse authorization metadata with audit telemetry. Privileges indicate who can access an object, but not whether or when the object was actually used.
- D. Incorrect.
Incorrect. GRANTS_TO_ROLES helps determine which roles were granted access to objects, which is useful for entitlement reviews, but grant history does not prove that a secure view or UDF was actually queried. Inferring usage from grants is unreliable and does not satisfy the requirement to identify specific queries, users, and times.