Data Governance and Security
What candidates must know
Snowflake security is RBAC plus policy objects. Privileges are granted to roles, roles are granted to roles and users, and effective access is the union of all inherited roles; object ownership confers full control and can be transferred. Know future grants (applied to objects created later), managed access schemas (schema owner centralizes grant management), and secure views/secure UDFs that hide definitions and internal optimization details. Column-level masking policies, row access policies, tag-based masking, object tagging with allowed values, and data classification cover protection. Auditing lives in ACCESS_HISTORY, ACCOUNT_USAGE views and QUERY_HISTORY, alongside network policies, key-pair and SSO authentication, MFA, and Tri-Secret Secure.
Traps
- A masking policy condition evaluates against the current role of the querying user; a role granted the policy owner's privileges still sees masked data unless the condition says otherwise.
- Policies are enforced with the privileges of the policy owner for the underlying object, so revoking the owner's access breaks queries.
ACCOUNT_USAGEviews require privileges on theSNOWFLAKEdatabase; they are not visible by default.- GRANT ... ON FUTURE applies only to objects created after the grant.
- Ownership of a policy matters more than ownership of the column when troubleshooting access issues.
Rule of thumb
Separate functional roles from access roles, always grant privileges to access roles, and use tag-based masking so new columns inherit protection automatically.
Worked example
Analysts should see masked emails except in the PII_ADMIN role: create a masking policy returning the raw value when CURRENT_ROLE() is PII_ADMIN, otherwise a hash, then apply it to the email column. New tables can be covered by attaching the tag and a tag-based masking policy.