DEA-C02 Question #130: Real Exam Question with Answer & Explanation

Question

A retail store's application team needs to build a loyalty program for their customers. The customer table contains Personal Identifiable Information (PII), and the team members have been assigned the role DEVELOPER. CREATE TABLE customer_data ( customer_first_name string, customer_last_name string, customer_address string, customer_email string, ... some other columns, ); The team needs to access the customer data, but the email field must be obfuscated. Which solution protects the sensitive information, while maintaining the usability of the data?

Options

• ACreate a view on the table to eliminate the email column by omitting it from the
• BCreate a separate table for all the non-PII columns and grant the role DEVELOPER access to the
• CUse the CURRENT_ROLE and CURRENT_USER context functions to integrate with a secure view
• DUse the CURRENT_ROLE context function to integrate with a masking policy on the sensitive

Explanation

Option D is correct because a column-level masking policy integrated with CURRENT_ROLE() dynamically substitutes sensitive values (e.g., replacing the email with ****) based on who is querying - DEVELOPER roles see obfuscated data while privileged roles see the real value. This satisfies both requirements: data remains queryable and structurally intact (usability), yet PII is protected (security).

Why the distractors fail:

• A - Omitting the email column entirely doesn't obfuscate it, it eliminates it. The column becomes unavailable, breaking any use case that legitimately needs it (like sending loyalty emails from an authorized role).
• B - Duplicating non-PII columns into a separate table creates maintenance overhead and data redundancy. Like A, it removes access rather than masking it, and doesn't scale well as the schema evolves.
• C - Using both CURRENT_ROLE and CURRENT_USER in a secure view is not the standard pattern for column-level obfuscation. Secure views can control row/column visibility, but masking policies (option D) are the purpose-built Snowflake feature for obfuscating specific field values while keeping the column present.

Memory tip: The word "obfuscated" in the question is your signal - obfuscation means the data is still there but hidden, which maps directly to a masking policy. If the question said "remove" or "exclude," think views or separate tables. Mask the word, mask the data.

No community discussion yet for this question.