Data Governance for Data Engineers

Role-Based Access Control (RBAC)

Create roles that map to job functions (analyst, engineer, finance_viewer). Grant table and schema permissions to roles, not individual users. When someone changes teams, revoke the old role and grant the new one. Every modern warehouse (Snowflake, BigQuery, Redshift, Databricks) supports RBAC.

-- Snowflake RBAC example
CREATE ROLE analyst_role;
GRANT USAGE ON WAREHOUSE analytics_wh TO ROLE analyst_role;
GRANT USAGE ON DATABASE analytics TO ROLE analyst_role;
GRANT SELECT ON ALL TABLES IN SCHEMA analytics.public
  TO ROLE analyst_role;

-- Assign to user
GRANT ROLE analyst_role TO USER jane;

Column-Level Security

Some columns in a table are sensitive while others are not. Column-level security restricts which roles can see specific columns. Snowflake uses masking policies. BigQuery uses column-level access control with policy tags. Redshift uses column-level GRANT.

-- Snowflake dynamic masking policy
CREATE MASKING POLICY email_mask AS (val STRING)
RETURNS STRING ->
  CASE
    WHEN CURRENT_ROLE() IN ('DATA_ADMIN', 'SUPPORT')
      THEN val
    ELSE '***@***.***'
  END;

ALTER TABLE customers
  MODIFY COLUMN email
  SET MASKING POLICY email_mask;

Row-Level Security

Row-level security filters rows based on the querying user's role or attributes. A regional manager sees only their region's data. A customer support agent sees only their assigned accounts. This is implemented via security policies (PostgreSQL, SQL Server) or row access policies (Snowflake, BigQuery).

-- PostgreSQL row-level security
ALTER TABLE orders ENABLE ROW LEVEL SECURITY;

CREATE POLICY region_access ON orders
  USING (region = current_setting('app.user_region'));

Hashing

Apply SHA-256 (with a salt) to PII columns. The hash preserves the ability to join records across tables without exposing the raw value. Use a consistent salt so the same email hashes to the same value everywhere. Store the salt in a secrets manager, not in the pipeline code.

Dynamic Masking

The raw PII exists in the table, but a masking policy hides it from unauthorized roles. Privileged users (support agents, data admins) see the real value. Everyone else sees a masked version. This is zero-copy: you do not maintain separate tables for different access levels.

Tokenization

Replace PII with a random token and store the mapping in a separate, tightly controlled service. Authorized applications can detokenize when needed. This is the strongest protection because the warehouse never contains the raw PII, and the tokenization service has its own access controls and audit logging.

System Design: “How would you handle PII in this pipeline?”

Strong answer structure: classify which columns are PII at ingestion. Hash PII columns for analytics. Apply dynamic masking policies for authorized roles. Log all access to tables containing PII. Implement a deletion pipeline for GDPR right-to-erasure requests. Mention specific tools (Snowflake masking policies, BigQuery policy tags) if you have used them.

Behavioral: “Tell me about a time you dealt with data compliance.”

Describe a specific project. What regulation or policy drove it? What technical controls did you implement? What was the outcome? Good examples: building a GDPR deletion pipeline, implementing column-level masking for a new dataset, setting up audit logging for SOX compliance, or migrating PII to a tokenized format.