RBAC + DAC in Snowflake

Micro-Concept 1: The Two Sentences That Carry Half the Domain

Two sentences answer most Domain 2 access-control questions on their own.

RBAC: “Privileges are granted to roles, and roles are granted to users.”
DAC: “Each object has an owner role that can grant access on it.”

Snowflake runs both at the same time. They are not alternatives. RBAC is the assignment model. DAC is the ownership model. Every object you create has an owner role (DAC), and every privilege on that object is delivered through a role grant (RBAC).

Sample Q4 from the official C03 study guide reads, paraphrased: “Which Snowflake access control framework allows the owner of an object to grant access to other users?” The answer is Discretionary Access Control (DAC). The cue word is “owner.” If the stem says “owner grants access,” the answer is DAC. If the stem says “privileges assigned to groups of users,” the answer is RBAC. Read for the cue, then commit.

Micro-Concept 2: The Two-Step Privilege Flow (RBAC)

RBAC always flows in exactly two steps. Multi-select questions love to slip a third step into the options or merge the two into a single “grant directly to user” line. Both are wrong.

Privileges are never granted directly to users in RBAC. That pattern is UBAC, which is a separate model with narrow scope (covered below). An exam option that says “in RBAC, privileges are granted to users” is a guaranteed wrong answer.

Roles can also be granted to other roles. That is how the role hierarchy works:

GRANT ROLE analyst_r TO ROLE SYSADMIN;
-- Anyone using SYSADMIN now also has every privilege analyst_r holds.

This is privilege inheritance. A parent role inherits every privilege of every child role granted to it. That is why ACCOUNTADMIN, sitting at the top of the system-role chain (ACCOUNTADMIN → SECURITYADMIN & SYSADMIN → USERADMIN → PUBLIC), can see and operate on everything inside its inheritance tree. The chain matters. We cover the system roles in detail on Day 19.

Micro-Concept 3: DAC, Ownership Belongs to a Role

The single most-missed point on DAC: roles own objects, not users. The role that is active in the session when CREATE runs becomes the owner. That ownership is the OWNERSHIP privilege, and it can be transferred to another role with a single grant.

USE ROLE analyst_r;
CREATE TABLE my_data (id INT);
-- analyst_r now owns my_data. analyst_r can grant SELECT on it to other roles.

-- Transfer ownership to a different role:
GRANT OWNERSHIP ON TABLE my_data TO ROLE data_steward_r;
-- analyst_r loses ownership; data_steward_r gains it.

Three consequences fall out of this rule, and exam stems exploit each of them:

• If Alice and Bob both have analyst_r granted to them, they share ownership of anything analyst_r creates. Ownership belongs to the role; the role belongs to both of them.
• If Alice leaves and her account is dropped, the table she created is not orphaned. analyst_r still owns it. Anyone else holding analyst_r can still manage it.
• The owner role can grant any privilege on its object to any other role without involving ACCOUNTADMIN. That is the “discretionary” in DAC. The owner role decides on its own.

On a recent client migration, this is exactly why we never bind ownership to a personal user. Ownership tracks a service role. People rotate off projects; roles persist.

Micro-Concept 4: The Securable Object Hierarchy

Privileges are not standalone. They flow through a hierarchy of containers. Reading a table needs three privileges, not one.

The required order is Database USAGE → Schema USAGE → Table SELECT. Outermost first, innermost last. Exam multi-selects will offer combinations like “schema SELECT” or “table USAGE.” Both are nonsense (tables do not have USAGE, schemas do not have SELECT), but they trip people up when the options are listed quickly.

The grant pattern looks like this:

GRANT USAGE  ON DATABASE sales_db                 TO ROLE analyst_r;
GRANT USAGE  ON SCHEMA   sales_db.public          TO ROLE analyst_r;
GRANT SELECT ON TABLE    sales_db.public.orders   TO ROLE analyst_r;

Two shortcuts worth knowing. GRANT <priv> ON ALL ... IN SCHEMA covers objects that already exist. GRANT <priv> ON FUTURE ... IN SCHEMA covers objects created later. The future-grant pattern is what production teams use to onboard new tables automatically without manually re-granting on every new object.

Micro-Concept 5: Account Roles vs Database Roles

Until a few years ago, every role in Snowflake was account-wide. Snowflake now distinguishes two role types, and C03 tests the difference directly.

Database roles exist so a database owner can manage access for their database without touching the account-wide role hierarchy. A common pattern: define a database role db_reader with USAGE on the database, USAGE on every schema, and SELECT on every table. Then grant that one database role to whichever account roles need to query the database, for example an analyst_r for one team and a reporting_r for another. The database owner publishes a single, well-scoped read role. The account hierarchy stays clean.

The trap that lands on the exam: an option claiming you can activate a database role directly with USE ROLE my_db.my_db_role. That is false. Database roles are only usable through an account role they have been granted to. In SnowPro training sessions I have run, this is consistently the question where the room splits 50/50 on the first attempt.

Micro-Concept 6: PUBLIC, the Default Floor

PUBLIC is a special pseudo-role with four properties:

• Every user is automatically granted PUBLIC. No explicit grant is needed.
• Every role automatically inherits PUBLIC.
• PUBLIC cannot be dropped.
• Anything granted to PUBLIC is effectively granted to every user in the account.

Used deliberately, PUBLIC is the right place for grants that genuinely apply to everyone. One example: USAGE on the SNOWFLAKE database so all users can read ACCOUNT_USAGE views. Used carelessly, it is a security hole. Granting SELECT on a sensitive table to PUBLIC opens that table to the entire account. Grants to PUBLIC are easy to add and hard to walk back once business teams start relying on what they can see.

Micro-Concept 7: UBAC, the Third Model

Current Snowflake docs name a third model alongside DAC and RBAC: UBAC, User-Based Access Control. UBAC lets you grant a privilege directly to a user, bypassing roles entirely. It only takes effect when the user runs with USE SECONDARY ROLES = ALL. That is why it is narrow by design, aimed at private development, personal Streamlit apps, and similar single-user scenarios.

For C03 as it currently stands, the standard answer to “which access-control models does Snowflake use?” is DAC + RBAC. That is the exact pair in the official practice bank (Q18). Recognize UBAC if it shows up as a distractor or an “all that apply” option. Pick the DAC + RBAC pair when the question asks for Snowflake’s primary access-control framework.

Official docs for today’s topics.

Database roles and ownership transfer.