You need to implement a data governance strategy that ensures data stewards can only access specific columns within a table to perform data quality checks. The table is RAW DATA.PUBLIC.CUSTOMER DETAIL

Question

Options

• AGrant SELECT privilege on the table to a custom role used by the data stewards. Use masking
• BCreate a secure view that only includes the EMAIL , and 'PHONE_NUMBER columns. Grant
• CGrant SELECT privilege on the table to the 'PUBLIC' role. Revoke SELECT privilege on the
• DCreate a role hierarchy where a data steward role inherits from a higher-level role that has
• ECreate a standard view that only includes the 'CUSTOMER ID', 'EMAIL', and 'PHONE NUMBER

• A
  6% (3)
• B
  77% (41)
• C
  2% (1)
• D
  2% (1)
• E
  13% (7)

Explanation

Option B - creating a secure view - is correct because a secure view in Snowflake hides the underlying query definition from unauthorized users (preventing column inference attacks) and exposes only the specific columns (CUSTOMER_ID, EMAIL, PHONE_NUMBER) that data stewards need. This enforces column-level access control without modifying table privileges or using complex masking policies.

Why the distractors fail:

• A - Masking policies obscure data values (e.g., showing **** instead of an email) but still expose all columns; this addresses data masking, not column restriction.
• C - Granting to PUBLIC then revoking is both insecure (PUBLIC is every user) and ineffective - Snowflake's privilege model doesn't support column-level revocation this way.
• D - Role hierarchy controls what roles a user inherits, but doesn't restrict access to specific columns within a table; it's the wrong tool for column-level restriction.
• E - A standard view (vs. secure view) exposes its definition to users with SHOW VIEWS or GET_DDL(), leaking schema details and defeating the security intent.

Memory tip: Think "Secure = Secret structure + Selective columns." Whenever a question asks for both column restriction and preventing metadata leakage, a secure view is the answer - standard views restrict columns but leak structure, while masking policies hide values but not columns.

No community discussion yet for this question.