SnowflakeProfessional levelPage 5 of 5

SnowPro Advanced: Security Engineer exam dumps: questions 401 to 431 of 431

Page 5 of the free SnowPro Advanced: Security Engineer question bank for the SnowPro® Advanced: Security Engineer exam. Questions 401 to 431 are listed below, the first 5 in full with answers and explanations. Back to page 1 for the exam overview and FAQ.

Question bank last updated April 2026

Start timed practice exam Questions 401 to 431

Free SnowPro Advanced: Security Engineer practice questions

Questions 401 to 405 of 431

Pick an answer before you open the explanation. Each question also has its own page with a permalink.

SnowPro Advanced: Security Engineer Question 401

Single answerUse the SERVICE_USAGE_HISTORY and compute pool monitoring views

A security engineering team is investigating a cost spike and possible unauthorized use of Snowpark Container Services in a production account. They need to determine which service consumed the most compute over the last 24 hours and whether the underlying compute pool experienced scaling or state changes during that same period. The team wants to use built-in account telemetry rather than application logs. Which approach best meets this requirement?

A
Query SERVICE_USAGE_HISTORY to identify per-service resource consumption, and correlate the results with compute pool monitoring views that show pool state and scaling activity during the same time window.
B
Query ACCESS_HISTORY to identify which service consumed the most compute, and use LOGIN_HISTORY to determine whether the compute pool auto-scaled during the period.
C
Query QUERY_HISTORY to identify container service compute consumption, and use WAREHOUSE_METERING_HISTORY to determine compute pool resizing events.
D
Query SERVICE_USAGE_HISTORY only, because it includes both per-service usage details and complete compute pool lifecycle and scaling history.

Show answer and explanation

Correct answer: A

Explanation

The best answer is to use SERVICE_USAGE_HISTORY together with compute pool monitoring views. In Snowflake, service usage telemetry and compute pool operational telemetry are related but distinct. SERVICE_USAGE_HISTORY helps determine how much compute or resource consumption is attributable to individual services. Compute pool monitoring views are then used to inspect the behavior of the underlying compute pool, including state and scaling-related activity during the same investigation window. This is the most practical and accurate approach for a security engineer investigating suspicious or unexpected Snowpark Container Services usage. Best practice is to correlate multiple account usage and monitoring sources rather than relying on application logs or warehouse-centric views. Snowflake documentation for Snowpark Container Services and Account Usage/monitoring views describes these as separate telemetry sources for service usage versus compute pool operations.

A. Correct.
Correct. SERVICE_USAGE_HISTORY is intended to analyze usage for services, including resource consumption for Snowpark Container Services. To understand what happened at the compute pool layer, you would correlate that data with the compute pool monitoring views, which expose operational details such as pool status and scaling-related behavior. This combination directly addresses both parts of the requirement: identifying the highest-consuming service and validating pool activity in the same time range.
B. Incorrect.
Incorrect. ACCESS_HISTORY tracks object access for governance and auditing, not container service compute consumption. LOGIN_HISTORY records authentication events, not compute pool scaling or lifecycle details. These views are useful for security investigations in other contexts, but they do not answer this operational usage question.
C. Incorrect.
Incorrect. QUERY_HISTORY is focused on SQL statement execution and is not the authoritative source for Snowpark Container Services resource consumption. WAREHOUSE_METERING_HISTORY applies to virtual warehouses, not compute pools used by Snowpark Container Services. This option reflects a common misconception of treating compute pools like warehouses.
D. Incorrect.
Incorrect. SERVICE_USAGE_HISTORY helps identify service-level usage, but it does not replace compute pool monitoring views for detailed pool operational telemetry such as state transitions or scaling activity. Relying on SERVICE_USAGE_HISTORY alone would leave the team without the pool-level evidence requested in the scenario.

SnowPro Advanced: Security Engineer Question 402

Single answerUse the SERVICE_USAGE_HISTORY and compute pool monitoring views

A 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.

SnowPro Advanced: Security Engineer Question 403

Single answerMonitor container logs

A 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.

SnowPro Advanced: Security Engineer Question 404

Single answerMonitor container logs

A security engineering team deployed a Snowpark Container Services service that processes sensitive files. During a suspected incident, the team needs to review recent container output to determine whether the application logged authentication failures or unexpected access attempts. The team wants to use Snowflake-native capabilities and maintain least-privilege access for the responder. Which action should the responder take to monitor the container logs for this service?

A
Query the event table that is collecting Snowpark Container Services logs and filter for the target service and time range.
B
Use QUERY_HISTORY to retrieve stdout and stderr emitted by the running containers.
C
Run SHOW SERVICES and inspect the returned rows for the full application log output.
D
Query ACCOUNT_USAGE.ACCESS_HISTORY to read the container log lines generated by the service.

Show answer and explanation

Correct answer: A

Explanation

For Snowpark Container Services, Snowflake-native monitoring of container logs is performed through event tables. When telemetry collection is configured, logs generated by containers are written to the event table, where responders can query them using SQL for investigations, troubleshooting, and security monitoring. This is the appropriate mechanism when a team needs to review recent application output such as authentication failures, errors, or suspicious access attempts. By contrast, QUERY_HISTORY is for SQL execution metadata, SHOW SERVICES is for object and runtime metadata, and ACCESS_HISTORY is for data access auditing rather than application log content. Best practice is to grant incident responders only the privileges needed to query the relevant event table and investigate the affected service.

A. Correct.
Correct. Snowpark Container Services can emit logs and telemetry to an event table, which is the Snowflake-native mechanism for monitoring container logs. A responder with appropriate privileges can query the event table and filter on attributes such as service, container, severity, and timestamp to investigate recent activity. This aligns with operational monitoring and forensic review practices in Snowflake.
B. Incorrect.
Incorrect. QUERY_HISTORY contains metadata about SQL statements executed in Snowflake, not the stdout or stderr log stream from containers running in Snowpark Container Services. Someone might choose this because QUERY_HISTORY is commonly used for troubleshooting SQL activity, but it is not the source for container application logs.
C. Incorrect.
Incorrect. SHOW SERVICES returns service metadata and status information, such as definitions and runtime state, but it does not provide the full application log stream. This is a plausible distractor because administrators often use SHOW commands to inspect deployed objects, yet log monitoring requires the event table rather than object metadata output.
D. Incorrect.
Incorrect. ACCESS_HISTORY is designed for auditing data access patterns, including how objects were accessed, but it does not store arbitrary application log lines from containers. A candidate might confuse security auditing with operational logging, but container logs are monitored through event tables, not ACCESS_HISTORY.

SnowPro Advanced: Security Engineer Question 405

Single answer5.2 Leverage Snowflake Cortex AI to enhance data security.

A security engineering team at a healthcare company wants to reduce the manual effort required to identify sensitive information in newly ingested claims notes stored in Snowflake. They want to use Snowflake-native AI capabilities to help classify free-text content so they can drive downstream masking and governance decisions, while keeping the data inside Snowflake. Which approach is the MOST appropriate?

A
Use Snowflake Cortex AI functions to analyze the unstructured text in the claims notes and generate classifications or labels that can be stored in Snowflake tables, then use those results to support security controls such as tagging, masking, or governance workflows.
B
Use network policies to inspect the contents of claims notes at query time and automatically detect PHI in the result set before the data is returned to users.
C
Use Tri-Secret Secure so Snowflake Cortex can natively classify sensitive text without requiring any SQL processing or governance objects.
D
Use row access policies alone to identify PHI entities embedded inside free-text notes and dynamically rewrite the note contents to remove sensitive terms.

Show answer and explanation

Correct answer: A

Explanation

The best answer is to use Snowflake Cortex AI to analyze text directly within Snowflake and store the resulting classifications or indicators for downstream security and governance enforcement. In practice, organizations often combine AI-driven analysis of free text with Snowflake governance features such as tags, masking policies, and policy-based access controls. The key distinction is that Cortex provides AI/LLM capabilities for understanding content, while features such as network policies, row access policies, and encryption controls address different parts of the security model. Snowflake documentation and best practices distinguish clearly between content analysis capabilities and governance enforcement mechanisms: AI can help identify sensitive content, but enforcement still relies on established security features such as tagging, masking, and access policies.

A. Correct.
Correct. Snowflake Cortex AI can be used to analyze text stored in Snowflake and produce summaries, labels, classifications, or extracted signals that help identify sensitive content. In a security workflow, those outputs can be persisted and then used to drive governance actions such as applying tags, informing masking strategies, or supporting review processes. This matches the requirement to keep data inside Snowflake and reduce manual review of free-text fields.
B. Incorrect.
Incorrect. Network policies control which client IP addresses can connect to Snowflake; they do not inspect query payloads or classify data content. This option confuses perimeter access control with data content analysis.
C. Incorrect.
Incorrect. Tri-Secret Secure is a key management and encryption-related capability, not an AI-based data classification tool. It does not inspect text or classify PHI. This distractor reflects a common misconception that stronger encryption features also provide data discovery or classification.
D. Incorrect.
Incorrect. Row access policies control which rows a role can see based on conditions, but they do not perform NLP-style identification of PHI inside free-text columns and do not rewrite text contents for sanitization. They are useful after data has been classified, not for performing the classification itself.

Timed practice exam

Take a SnowPro Advanced: Security Engineer practice test under exam conditions

65 questions in 115 minutes, drawn from this bank, with a score report and a per-question review when you finish.

Start timed exam

SnowPro Advanced: Security Engineer practice questions 401 to 431 of 431

Every question has a page with the answer and explanation. Numbers are stable, so you can bookmark or share them. The bank is split into 5 pages of up to 100 questions.