SnowPro Advanced: Security Engineer Question 402
Single answerUse the SERVICE_USAGE_HISTORY and compute pool monitoring viewsA security engineering team uses Snowpark Container Services to run an internal tokenization microservice in a compute pool. The team must investigate a suspected period of abnormal service activity and determine whether the issue was caused by the service itself or by compute pool capacity constraints. They need an approach that provides service-level usage details and compute pool state/usage evidence for the same time window. Which action is the MOST appropriate?
- A
Query SERVICE_USAGE_HISTORY for the service activity during the incident window, and correlate it with the compute pool monitoring/account usage views that show compute pool state and node-level usage over the same period.
- B
Query QUERY_HISTORY and ACCESS_HISTORY only, because service containers execute as SQL statements and all compute pool capacity events are fully represented there.
- C
Use WAREHOUSE_METERING_HISTORY together with LOGIN_HISTORY, because Snowpark Container Services consume warehouse credits and service lifecycle events are tied to user sessions.
- D
Review TASK_HISTORY and PIPE_USAGE_HISTORY, because services in compute pools are monitored through task execution records and ingestion telemetry rather than service usage views.
Show answer and explanation
Correct answer: A
Explanation
For Snowpark Container Services investigations, the best practice is to use the monitoring surfaces intended for that workload type. SERVICE_USAGE_HISTORY provides service-level historical usage information, while compute pool monitoring/account usage views provide visibility into compute pool behavior such as pool state and resource usage over time. Correlating these views for the same incident window helps determine whether a problem originated from the service workload itself or from infrastructure constraints in the compute pool. In contrast, QUERY_HISTORY, ACCESS_HISTORY, WAREHOUSE_METERING_HISTORY, TASK_HISTORY, and PIPE_USAGE_HISTORY are designed for other Snowflake objects and do not replace the service-specific and compute-pool-specific telemetry required here. This aligns with Snowflake documentation for Snowpark Container Services monitoring and Account Usage/monitoring views for services and compute pools.
- A. Correct.
Correct. SERVICE_USAGE_HISTORY is designed to provide service-level usage history for Snowpark Container Services, which helps identify what the service was doing during a specific period. To determine whether abnormal behavior was caused by service demand or by insufficient/changed compute pool capacity, the team should correlate that information with compute pool monitoring views that expose compute pool status and usage details for the same timeframe. This is the most direct and operationally appropriate method for distinguishing service activity from compute pool constraints.
- B. Incorrect.
Incorrect. QUERY_HISTORY and ACCESS_HISTORY are valuable for SQL statement auditing and data access investigation, but Snowpark Container Services are not investigated solely through SQL statement history. Compute pool lifecycle and capacity behavior are not fully represented in these views. A candidate might choose this because they associate all Snowflake workload investigation with query/audit views, but service/container activity requires the service-specific and compute-pool-specific monitoring surfaces.
- C. Incorrect.
Incorrect. WAREHOUSE_METERING_HISTORY applies to virtual warehouses, not compute pools used by Snowpark Container Services. LOGIN_HISTORY is about authentication/session events and does not provide the operational compute pool evidence needed to diagnose pool saturation or state changes. This distractor targets the common misconception that all Snowflake compute is warehouse-based.
- D. Incorrect.
Incorrect. TASK_HISTORY and PIPE_USAGE_HISTORY are for tasks and Snowpipe-related processing respectively. They do not provide the service runtime or compute pool operational visibility needed for Snowpark Container Services troubleshooting. Someone might select this if they are broadly familiar with operational telemetry views but do not distinguish between Snowflake features and their corresponding monitoring objects.