SnowPro Advanced: Security Engineer Question 416
Single answerUse Cortex AI for data security:A security engineering team at a healthcare company stores support tickets, chat transcripts, and claim notes in Snowflake. They want to use Snowflake Cortex AI to help identify sensitive information in free-text columns before analysts access the data. The team must minimize custom model development and keep the solution inside Snowflake's governance framework. Which approach best meets these requirements?
- A
Use Cortex AISQL functions to analyze unstructured text for sensitive content, then use the results to drive masking or downstream governance controls on the affected data.
- B
Export the text data to an external LLM endpoint, classify sensitive content there, and rely on network policies alone to keep the workflow compliant.
- C
Create a dynamic data masking policy that directly invokes an arbitrary external AI model at query time for each row of text.
- D
Use row access policies only, because Cortex AI is intended for summarization and question answering rather than security-related text inspection.
Show answer and explanation
Correct answer: A
Explanation
The best answer is to use Snowflake-native Cortex AI capabilities to inspect free-text data for sensitive information and then integrate those results with standard Snowflake governance features such as masking, tagging, and controlled access patterns. This reduces the need for custom model development and avoids unnecessary data egress to external services. From a security engineering perspective, the key principle is to combine AI-based text analysis with Snowflake's existing governance model rather than replacing governance controls with AI. In Snowflake documentation, Cortex is presented as a native AI capability accessible in SQL, while masking policies, row access policies, and tags remain the core governance mechanisms for enforcing protection. A practical architecture is therefore: analyze text with Cortex, persist or derive sensitivity metadata, and enforce access or masking based on that metadata.
- A. Correct.
Correct. This approach aligns with the requirement to minimize custom model development and remain within Snowflake's governance framework. Snowflake Cortex provides built-in AI capabilities through SQL functions that can be used to inspect text and derive classifications or labels. Those outputs can then be incorporated into security workflows such as tagging, masking, or routing records for review. This is the most practical Snowflake-native pattern for using Cortex AI in data security scenarios.
- B. Incorrect.
Incorrect. Exporting sensitive healthcare text to an external LLM increases data movement and governance complexity, which conflicts with the requirement to keep the solution inside Snowflake where possible. Network policies control connectivity to Snowflake endpoints; they do not by themselves provide classification, masking, or compliant handling of sensitive content once data is exported.
- C. Incorrect.
Incorrect. Dynamic masking policies are not designed as a general mechanism to invoke arbitrary external AI models row by row at query time. That design would also introduce operational, performance, and governance concerns. The better pattern is to use Snowflake-native Cortex capabilities to derive sensitivity indicators and then apply standard Snowflake security controls.
- D. Incorrect.
Incorrect. Row access policies restrict which rows a role can see, but they do not identify sensitive entities inside free-form text. Also, the statement that Cortex AI is only for summarization and question answering is inaccurate. Cortex capabilities can support broader AI-assisted analysis patterns relevant to data security workflows.