skip to content

Access Governance

2 roadmaps5 questions

How a data platform decides who reads which rows and columns: role and tag-based policies, central enforcement and access reviews. The SSN-column request is daily work.

on this pageshow

explore

questions

5

How does role-based access control differ from attribute-based access control for governing who can read warehouse data?

level: juniorimportance: must knowfreq 55%

answer

  1. who you are versus what is true
  2. roles bundle permissions
  3. attributes on user and data
  4. role explosion at scale
  5. policies written once, evaluated per request

basics

~20 s

Role-based access grants permissions to roles and users to roles. Attribute-based access evaluates rules over attributes of the user and the data, such as department and a column's sensitivity tag, so one rule covers many tables.

solid answer

~40 s

With **role-based access control (RBAC)** permissions are attached to **roles** — `finance_analyst` may read these schemas — and users get roles. It is simple to reason about, but in a large warehouse roles multiply: finance-EU-read, finance-EU-read-with-PII, and so on, the problem known as **role explosion**. **Attribute-based access control (ABAC)** evaluates **rules over attributes** of the user (department, region, clearance), the data (classification tag, owning domain, region) and sometimes the context (purpose, time). One rule — *users may read rows whose region matches their own; columns tagged restricted are masked unless the user holds the restricted clearance* — then covers every table carrying those attributes. Most data platforms combine them: roles for coarse access to schemas, attributes and tags for row and column rules.

go deeper

for a junior

Be ready to define RBAC and ABAC with a warehouse example of each.

for a middle

Explain role explosion and how attribute or tag-based rules cover new tables without new grants.

for a senior

Show how you combine roles for coarse access with attribute rules for rows and columns, and how you govern the attributes.

for a principal

Decide the access model for the whole data estate, including who owns user and data attributes and how effective access is audited.

## The question access control answers For every query the platform must decide: **may this user read this data?** — possibly down to individual rows and columns. Two models dominate how that decision is expressed. ## Role-based access control In **RBAC**, permissions are granted to **roles**, and users are made members of roles. - `marketing_analyst` → read on the `marketing` schema. - `finance_analyst` → read on `finance`, but not on `payroll`. It is easy to explain and to review ("who has this role?"). The trouble starts when access depends on more than one dimension. Region, sensitivity and department multiply: `finance_eu_read`, `finance_eu_read_pii`, `finance_us_read`… This **role explosion** makes roles hard to review, and every new table needs grants to the right roles. ## Attribute-based access control In **ABAC**, a policy is a rule over **attributes**: - **User attributes**: department, region, employment type, clearance. - **Data attributes**: classification tag (public, confidential, restricted), owning domain, the region a row belongs to. - **Context attributes**: stated purpose, time, network location. Example rules: 1. A user may read rows whose `region` equals the user's region attribute. 2. Columns tagged `restricted` are masked unless the user holds the `restricted` clearance. 3. Contractors may not read datasets tagged `customer-personal`. Each rule applies to **every table carrying the attribute**, including tables created tomorrow. ## Comparison | Aspect | RBAC | ABAC | |---|---|---| | Unit of policy | role → permission on objects | rule over attributes | | Scales with | number of role combinations | number of rules and quality of attributes | | New table | needs new grants | covered if its tags and attributes are set | | Row and column rules | awkward (one role per slice) | natural | | Reviewability | easy: list role members | harder: must evaluate rules to see effective access | | Main risk | role explosion, stale grants | wrong or missing attributes silently change access | ## How platforms combine them Most real deployments use **roles for coarse access** (which schemas or domains a team may query) and **attribute or tag-based policies** for fine-grained row filters and column masks. The attributes themselves — a user's department, a column's classification — must be governed: an ABAC policy is only as correct as the tags it reads. ## Why interviewers ask it It is the entry question for data access governance. A good answer defines both, names **role explosion** as the reason ABAC exists, and notes that ABAC moves the risk to **attribute quality**.

  • What is the main operational risk of attribute-based policies?
    Wrong or missing attributes. If a column is not tagged as restricted, or a user's department attribute is stale, the policy grants or denies the wrong access with no visible error, so the tagging and user-attribute sources need their own governance.
  • Why is RBAC easier to review in an access audit?
    Because effective access is visible as role membership plus grants. With attribute rules an auditor must evaluate each rule against current attributes to know who can read what, which usually needs tooling.

saying these in an interview costs you the question

  • Solving every new access need by creating another role
  • Assuming attribute-based policies are correct regardless of tag quality
  • Believing RBAC and ABAC cannot be used together
  • Granting access per user instead of through roles or policies
open as a page

What does a periodic access review of a data platform check, and how do read logs keep it from becoming a rubber stamp?

level: middleimportance: should knowfreq 40%

basics

~20 s

An access review asks each data owner to confirm that every holder of access to their data still needs it. Read logs show which grants were never used, so owners revoke on evidence instead of approving everything by default.

open as a page

In a data lake, table-level access rules are enforced by the query engine; why can a user sometimes still read the protected data, and how do platforms close that path?

level: seniorimportance: should knowfreq 40%

basics

~20 s

Table rules run in the query engine, but the files sit in object storage with separate permissions, so a direct storage reader skips filters and masks. Deny users direct storage access and give only governed engines scoped, short-lived credentials.

open as a page

When masking policies are attached to classification tags, what happens to a newly added column of customer emails that nobody has tagged, and how do you close that gap?

level: seniorimportance: should knowfreq 35%

basics

~20 s

With no tag, no tag-based policy applies, so the emails are readable by anyone who can read the table. Close the gap by scanning new columns, inheriting tags along lineage, and defaulting unclassified columns in sensitive tables to masked.

open as a page

Who should approve access requests to a domain's sensitive dataset, and how do you keep approvals fast without making them meaningless?

level: principalimportance: should knowfreq 30%

basics

~20 s

The data owner should be accountable for access to sensitive data, but not click every request. Tier data by sensitivity, auto-approve low tiers by policy, require owner review with a stated purpose for high tiers, make grants expire, and track lead time.

open as a page