SnowPro Advanced: Security Engineer Question 95
Single answerGeneric stringsA security engineer at a financial services company is reviewing unstructured customer support data that is loaded into a Snowflake VARCHAR column named RAW_TEXT. The company uses a masking policy to prevent analysts from seeing sensitive values such as account numbers and email addresses unless they hold a privileged role. During testing, the engineer notices that some records contain free-form values like "acct=99887766" and "contact me at jane.doe@company.com", but the current policy only masks exact known column patterns and misses these embedded values. Which approach is the most appropriate to improve protection for these generic strings while keeping the solution inside Snowflake security controls?
- A
Update the masking policy to use conditional logic with string and pattern-matching functions so that embedded sensitive substrings in RAW_TEXT are redacted for non-privileged roles.
- B
Replace the masking policy with a row access policy because row access policies are designed to hide sensitive substrings inside a VARCHAR value.
- C
Create a network policy that restricts access to the RAW_TEXT column from analyst IP ranges so generic strings do not need masking.
- D
Use object tags on the table only, because applying a SENSITIVE tag automatically masks matching substrings within free-form text.
Show answer and explanation
Correct answer: A
Explanation
For free-form or generic strings in Snowflake, the key challenge is that sensitive data may appear as substrings inside a larger VARCHAR value rather than occupying a dedicated structured column. In that scenario, the best fit is a masking policy that uses conditional logic and string pattern functions to redact values for unauthorized roles while preserving access for privileged roles. Snowflake dynamic data masking supports role-aware transformations at query time, making it appropriate for this use case. Row access policies are for controlling row visibility, not substring redaction. Network policies control where users can connect from, not what data values they can see. Tags support data classification and can be combined with tag-based masking strategies, but tags alone do not perform masking. Snowflake documentation and best practices around dynamic data masking, tag-based masking, and row access policies clearly distinguish these controls and their intended use cases.
- A. Correct.
Correct. Dynamic data masking in Snowflake can be implemented with a masking policy that evaluates the current role or other context and returns either the original value or a transformed/redacted value. For generic strings stored in VARCHAR columns, the practical approach is to use SQL string handling and pattern-matching functions, such as REGEXP_REPLACE and related conditional logic, to redact sensitive substrings embedded in free-form text. This keeps the control in Snowflake and aligns with the requirement to protect analysts from seeing account numbers and email addresses unless authorized.
- B. Incorrect.
Incorrect. Row access policies control which rows are visible to a query based on conditions; they do not selectively redact part of a string within a visible row. A candidate might choose this because row access policies are also security controls, but they solve row-level visibility problems, not substring masking within a column value.
- C. Incorrect.
Incorrect. Network policies restrict authentication access by network location, which can reduce exposure from untrusted locations, but they do not mask or transform data returned from a query. This is a plausible distractor because network policies are an important Snowflake security feature, but they are unrelated to detecting and redacting generic sensitive strings inside column values.
- D. Incorrect.
Incorrect. Tags in Snowflake are metadata labels and can be used to drive governance workflows; however, a tag by itself does not automatically mask data. Tag-based masking is possible only when masking policies are associated appropriately, but simply applying a SENSITIVE tag on the table does not inspect free-form text and redact matching substrings automatically. This option reflects a common misconception that classification metadata alone enforces masking.