SnowPro Advanced: Security Engineer Question 403
Single answerMonitor container logsA security engineering team runs a containerized service in Snowpark Container Services that performs token validation for internal applications. During an incident review, the team needs to investigate whether the service emitted unexpected authentication errors during the last deployment. The team wants the fastest Snowflake-native way to query recent stdout/stderr output from the running service for troubleshooting, while keeping access limited to authorized administrators. Which approach should they use?
- A
Query the event table that stores Snowpark Container Services logs after enabling log collection for the account, and grant the appropriate privileges to the administrators who need to investigate.
- B
Use QUERY_HISTORY to retrieve container stdout and stderr because container logs are recorded as SQL statement output automatically.
- C
Review ACCESS_HISTORY because Snowpark Container Services writes application log lines there together with object access details.
- D
Use TASK_HISTORY to inspect the container's runtime logs because services are implemented as continuously running tasks.
Show answer and explanation
Correct answer: A
Explanation
For monitoring Snowpark Container Services logs, the Snowflake-native approach is to use telemetry data stored in an event table. Event tables are designed to capture logs and traces from supported Snowflake features, enabling administrators to query recent service output during troubleshooting or incident response. This is more appropriate than account usage views such as QUERY_HISTORY, ACCESS_HISTORY, or TASK_HISTORY, which each serve different auditing or operational purposes. From a security engineering perspective, best practice is to enable telemetry deliberately, store the data in the designated event table, and grant only the required privileges to the roles responsible for investigations. Refer to Snowflake documentation for Event Tables, Logging/Tracing telemetry, and Snowpark Container Services observability guidance.
- A. Correct.
Correct. In Snowflake, log and trace data for supported features, including Snowpark Container Services, is collected in an event table when telemetry collection is configured. This is the Snowflake-native mechanism for querying container stdout/stderr style logs for operational and security troubleshooting. Restricting access through standard Snowflake privileges aligns with least-privilege administration.
- B. Incorrect.
Incorrect. QUERY_HISTORY tracks SQL statement execution metadata, such as text, duration, and status. It does not serve as the repository for application container stdout/stderr logs from Snowpark Container Services. A candidate might choose this because both are queryable account views, but container runtime logs are handled through telemetry/event tables instead.
- C. Incorrect.
Incorrect. ACCESS_HISTORY is for auditing data access and policy enforcement behavior, not for collecting arbitrary application log output from containers. Someone may confuse security auditing with application logging, but authentication error messages emitted by the service would not be stored there as log lines.
- D. Incorrect.
Incorrect. TASK_HISTORY contains execution details for Snowflake tasks. Snowpark Container Services are not monitored through TASK_HISTORY for container stdout/stderr logs. This distractor targets the misconception that any scheduled or running compute process in Snowflake surfaces operational logs through task metadata.