SnowPro Advanced: Security Engineer Question 338
Single answerIdentify, triage, and contain security incidents:A Snowflake security engineer is notified that a service user account began issuing large numbers of unexpected SELECT statements against sensitive tables from a new client IP range late at night. The account is used by an internal ETL application and normally runs only COPY INTO and MERGE statements during business hours. Management wants the engineer to quickly contain the incident while preserving evidence for investigation. Which action should the engineer take FIRST?
- A
Immediately disable the suspected user account to stop all activity, then investigate query history later
- B
Revoke the role currently assigned to the user and drop the warehouse used by the ETL application
- C
Use Snowflake access history, login history, and query history to validate the suspicious activity, then temporarily restrict or disable the compromised principal in a way that stops access while preserving audit records
- D
Clone the affected database to a new database for forensic review and allow the ETL account to continue running so investigators can observe its behavior
Show answer and explanation
Correct answer: C
Explanation
The best answer is to first triage using Snowflake's auditing and monitoring data, then apply targeted containment to the suspected compromised identity. For suspicious access, Snowflake practitioners commonly review QUERY_HISTORY for anomalous SQL, LOGIN_HISTORY for unusual client IPs or authentication behavior, and ACCESS_HISTORY to understand which objects were touched. After confirming suspicious behavior, the engineer should contain the incident by restricting the specific user or credentials rather than making broad disruptive changes such as dropping warehouses. This approach balances rapid containment, evidence preservation, and minimizing unnecessary operational impact. These actions are consistent with Snowflake security operations best practices and the platform's account usage views for investigation.
- A. Incorrect.
This is a plausible instinct for containment, but it is not the best FIRST action in the scenario as stated. The engineer was specifically asked to contain the incident while preserving evidence and performing triage. Immediately disabling the account may stop activity, but it skips validation of what occurred and may unnecessarily interrupt a legitimate production process if the alert is a false positive. Snowflake audit sources such as LOGIN_HISTORY, QUERY_HISTORY, and ACCESS_HISTORY should be reviewed promptly to confirm the scope and nature of the activity before taking targeted containment action.
- B. Incorrect.
This is not the best first step. Revoking a role and dropping a warehouse are blunt actions that may disrupt unrelated workloads and do not directly address investigation needs. Dropping the warehouse is especially poor incident response practice because it can impact service availability without improving evidence collection. A better approach is to triage with Snowflake telemetry, then contain the specific principal or session path involved.
- C. Correct.
This is correct. In Snowflake, effective incident handling begins with triage using available telemetry such as login history, query history, and access history to confirm whether the activity is truly anomalous, identify the source, and determine what objects were accessed. Once validated, the engineer should perform targeted containment, such as temporarily disabling the user, rotating credentials, or otherwise restricting access for the compromised principal. This aligns with incident response best practices: verify, scope, then contain, while relying on Snowflake's persisted audit records rather than making unnecessary destructive changes.
- D. Incorrect.
This is incorrect. Cloning a database may be useful in some operational or recovery scenarios, but it is not the right first response to a likely credential compromise. Allowing the ETL account to continue running increases risk and does not contain the incident. In addition, the most relevant evidence for this type of event is in account usage and access telemetry, not in creating a clone of the database.