Articles · Snowflake
Snowflake RBAC Interview Questions: Role Inheritance, Future Grants, and Access Failures
Practice Snowflake RBAC interview questions using role inheritance, active roles, future-grant precedence, managed schemas, and an access-failure ledger.
Snowflake RBAC interview questions are easiest to answer as a chain of evidence: which roles are active, which privileges they inherit, which objects those privileges cover, and who may change the grants. A role assignment alone does not prove that the current session has the table privileges required for its query.
This guide builds one role hierarchy and a grant ledger for existing and future tables.
Official facts come from Snowflake documentation checked on October 6, 2026. The roles, tables, access predictions, and diagnostic exercises are original examples. They are not evidence of a particular employer's interview format. SQL is illustrative; local graph and ledger checks model our assumptions without executing Snowflake.
Which way do privileges flow through a role hierarchy?
The GRANT ROLE reference describes granting a child role to a parent role. The parent inherits the child's privileges, not the reverse.
Our three business roles are ANALYST_READ, TEAM_ANALYST, and TEAM_LEAD. We connect them with:
GRANT ROLE ANALYST_READ TO ROLE TEAM_ANALYST;
GRANT ROLE TEAM_ANALYST TO ROLE TEAM_LEAD;
Read the arrows as inheritance flowing upward: ANALYST_READ → TEAM_ANALYST → TEAM_LEAD. If ANALYST_READ receives SELECT on a table, both parent roles can inherit that privilege. A privilege granted only to TEAM_LEAD does not flow back down to ANALYST_READ.
Check the direction because the phrase “grant role A to role B” is easy to reverse when drawing a diagram. Label the relationship and test it with one privilege before extending the hierarchy.
Role ownership is another relationship. Snowflake's access-control overview distinguishes owning a role from inheriting its privileges through the hierarchy. Do not assume that the role managing another role automatically receives its data access merely because it owns the role object.
For the exercise, the hierarchy is acyclic and privileges are ordinary allow grants. We are not importing a generic deny-precedence algorithm into Snowflake. A design question involving explicit deny rules would require a different authorization model.
Why can an assigned role still leave a query unauthorized?
A session has a primary role and can activate secondary account roles. The USE SECONDARY ROLES reference describes activating secondary roles; assignment to the user and activation in the session are separate facts.
Suppose a user has TEAM_ANALYST and an unrelated SUPPORT role. ANALYST_READ has the necessary table SELECT and database/schema usage. TEAM_ANALYST inherits those grants. SUPPORT does not. The following SELECT predictions assume the stated container privileges and warehouse access, with no other grants changing the outcome.
| Primary role | Secondary setting | Active inherited read path? | SELECT prediction |
|---|---|---|---|
| SUPPORT | NONE | No | Denied |
| TEAM_ANALYST | NONE | Yes, through ANALYST_READ | Allowed |
| SUPPORT | ALL, including assigned TEAM_ANALYST | Yes | Allowed |
| TEAM_LEAD, after assignment | NONE | Yes, through both child roles | Allowed |
The fourth row includes an explicit assignment prerequisite. Having a role in the account does not let a user activate it without the appropriate grant.
In a failing query, record the actual session state. A screenshot showing a user was assigned TEAM_ANALYST last week does not establish which roles are active now. The CURRENT_ROLE function reports the current primary role; inspect secondary roles as well when they may contribute privileges.
Current Snowflake documentation also describes user-based access control alongside RBAC. Direct user grants have their own activation conditions. This exercise deliberately uses account-role grants, so its predictions should not be generalized to every authorization path in a differently configured account.
Does secondary-role access also authorize object creation?
The access-control overview specifies an important boundary: authorization for CREATE <object> statements comes from the primary role, and the new object's ownership is assigned to that role. Other actions can use active primary and secondary privileges under the documented rules.
Add an engineering role, BUILD, with CREATE TABLE on our schema. A user has both BUILD and TEAM_ANALYST. TEAM_ANALYST has read access but lacks CREATE TABLE.
With TEAM_ANALYST primary and BUILD active only as a secondary role, the CREATE TABLE attempt lacks the required primary-role authorization in this exercise. Switching the primary role to BUILD can authorize creation, assuming its other necessary privileges are present. The new table is owned by BUILD.
This counterexample prevents the shortcut “ALL secondary roles authorize everything.” Explain the operation being checked. A successful SELECT and a failed CREATE can occur in the same session without contradicting one another.
It also explains why a client should record the role used at creation time. A later question about object ownership cannot be answered merely by listing every role assigned to the user.
What do current grants and future grants each cover?
Snowflake's access-control best practices describes future grants as a way to automate privileges on new objects. They do not retroactively repair every existing object's grants.
Our managed-access schema is PROD.MART. BUILD created table T0 before any future table grants existed. No business role initially has SELECT on T0. A schema administrator later establishes SELECT on future tables for ANALYST_READ.
When BUILD creates T1 afterward, the applicable future grant supplies ANALYST_READ with SELECT on T1. T0 still lacks that grant. A developer observing “new tables work, old tables fail” should therefore inspect creation time and grant scope before assuming random permission behavior.
An authorized grantor can backfill current tables separately:
GRANT SELECT ON ALL TABLES IN SCHEMA PROD.MART
TO ROLE ANALYST_READ;
GRANT SELECT ON FUTURE TABLES IN SCHEMA PROD.MART
TO ROLE ANALYST_READ;
The first statement repairs the missing current-table SELECT grants, including T0, at the moment it runs. The second establishes the rule for subsequently created tables. One is not a replacement for the other.
Our examples use ordinary tables in this one schema. A future grant for TABLES is not automatically a future grant for every other object type. Check the object type, database/schema scope, and intended privilege when explaining why a newly created object differs from another.
What happens when database and schema future grants compete?
The GRANT privileges reference documents precedence: when database and schema future grants apply to the same object type, the schema-level future grants take precedence and the database-level grants are ignored for that schema's new objects.
An authorized administrator establishes these two TABLES rules before BUILD creates T1 in PROD.MART:
- At database PROD, grant INSERT on future TABLES to TEAM_LEAD.
- At schema PROD.MART, grant SELECT on future TABLES to ANALYST_READ.
Both concern the object type TABLES. T1 receives the applicable schema-level SELECT grant, not an additional database-default INSERT grant. TEAM_LEAD can still read T1 through its inheritance path from ANALYST_READ, but it does not receive INSERT through the ignored database future rule.
| Table and observation time | ANALYST_READ SELECT | TEAM_LEAD SELECT | TEAM_LEAD INSERT from database future rule |
|---|---|---|---|
| T0, before backfill | No | No | No |
| T1, created after both future rules | Yes | Yes, inherited | No |
| T0, after current-table SELECT backfill | Yes | Yes, inherited | No |
The table assumes no other grants confer these privileges. That assumption matters: an INSERT observed through a separate direct grant would not demonstrate that future-grant precedence stopped working.
This is why a grant ledger should distinguish direct object grants, inherited grants, and future-grant definitions. A future definition expresses what should be applied at creation; an object's current grants show its present authorization state. Inspect both rather than treating one view as a complete explanation.
Why can't a managed-schema object owner grant access?
In an ordinary schema, object ownership commonly includes discretionary grant decisions. In a managed-access schema, Snowflake centralizes those decisions with the schema owner or a role having MANAGE GRANTS, as described in the best-practices guide.
BUILD owning T1 therefore does not mean BUILD can grant SELECT on T1 to an unrelated role. Object creation, object ownership, and authority to distribute access are distinct questions.
For our ledger, SCHEMA_ADMIN owns PROD.MART and manages its object grants. BUILD creates tables under the intended creation privileges, while the business roles receive scoped data access through centrally controlled grants. This separates building data objects from deciding who may consume them.
When a grant command fails, preserve the separation between creating a table and distributing its access. Do not grant broad administrative authority to BUILD just because one grant command failed. Identify the authorized grantor and ask it to apply the intended object or future grant through the team's normal change process.
Then verify the allowed and forbidden paths. TEAM_ANALYST should read the intended tables. It should not acquire arbitrary creation or grant-management authority as a side effect. A repair that makes every command succeed can weaken the boundary the exercise was supposed to preserve.
How would you investigate an access failure in order?
Begin with the exact operation and object name. SELECT from PROD.MART.T0 is a different question from creating a new table or granting another role access to T0. Fully qualifying the object helps distinguish same-named tables; it does not confer privileges.
Record primary and secondary roles. Inspect the active hierarchy, then check table SELECT, database and schema usage, and warehouse access needed for the ordinary query. If the attempted action is CREATE, focus on primary-role authorization. If it is GRANT, inspect grant authority, including managed-schema restrictions.
Useful inspection statements include:
SELECT CURRENT_ROLE(), CURRENT_SECONDARY_ROLES();
SHOW GRANTS TO ROLE ANALYST_READ;
SHOW GRANTS OF ROLE ANALYST_READ;
SHOW GRANTS ON TABLE PROD.MART.T0;
SHOW FUTURE GRANTS IN SCHEMA PROD.MART;
Use the SHOW GRANTS reference to interpret the command forms and the visibility available to your diagnostic role. A limited role's output should not be treated as proof that an administrator can see no other grants.
Next compare T0 with T1. Did the failing table predate the future rule? Is the rule on the correct schema and object type? Does schema precedence suppress a database-level rule? These questions turn a vague permission incident into a bounded explanation.
Change one relevant grant or role setting in a development exercise, then rerun the intended operation as the actual caller. Testing only under an administrator can hide the original missing privilege. Record the before/after outcome and the unauthorized operation that should remain denied.
How can you verify the role reasoning without a live account?
Our local model traverses child roles from an active parent, unions their stated grants, and compares predictions with the two grant-ledger snapshots. It verifies upward inheritance, inactive assigned roles, primary-only creation, T0 before backfill, T1's schema future grant, and BUILD's missing grant-management authority.
That model checks the worked explanation, not Snowflake's engine, policies, or a real account's hidden grants. Before relying on a real grant change, inspect the account and verify the relevant allowed and denied operations with the intended identity. Keep the evidence boundary explicit rather than presenting a modeled result as a successful SQL session.
Practice access reasoning with linked exercises
| Question | Practice target |
|---|---|
| Design an RBAC Relational Schema | Separate users, roles, assignments, and permissions. |
| Resolve user roles across account hierarchy | Resolve inheritance instead of checking one role name. |
| Design an access control system (RBAC + resource-based) | Distinguish role permissions from resource scope. |
| Design Hierarchical Permission Checks | Explain a permission decision through a hierarchy. |
| Identify read-only files from permission records | Evaluate the stated permission record rather than assuming access. |
Start with Resolve user roles across account hierarchy, then redraw the three-role Snowflake hierarchy. Predict T0 and T1 before changing any grants, and explain why TEAM_LEAD can inherit SELECT while the database future INSERT rule remains ignored.