What you will be able to do
- Tell DAC, RBAC and UBAC apart and say what each one contributes to Snowflake's access control framework
- Choose between RBAC and UBAC for a given business requirement
- Explain how object ownership works and how managed access schemas limit owners' grant decisions
- Describe the use case and position of each system-defined role: ACCOUNTADMIN, SECURITYADMIN, USERADMIN, SYSADMIN and PUBLIC
Key concept
RBAC as the foundation — Snowflake mixes three access models. Its framework is built on granting privileges to roles and then granting those roles to users. Ownership (DAC) decides who can make grants, and direct user grants (UBAC) are an optional addition for narrow, collaborative cases.
1.Three models in one framework
Snowflake doesn't pick a single access control model. It combines parts of three, and each one answers a different question. Discretionary Access Control (DAC) answers *who decides*: every object has an owner, and that owner can grant access to it. Role-Based Access Control (RBAC) answers *how access is packaged*: privileges are granted to roles, and roles are granted to users. User-Based Access Control (UBAC) answers *can I skip the role*: privileges can be granted straight to a user.
The documentation shows all three working together. A role that holds OWNERSHIP on two objects is DAC. Privileges on the first object are granted to a second role, and that role is granted to two users. That is RBAC. Privileges on the second object are granted directly to two other users. That is UBAC, which the docs describe as a way to *extend* the framework. In daily administration RBAC carries most of the load: the overview says that usually you use RBAC to manage access to securable objects.
Four terms recur in everything below. A securable object is anything access can be granted to, and access is denied unless a grant allows it. A privilege is a defined level of access to an object. A role is an entity that privileges are granted to. A user is an identity for a person or a service, and it can also receive privileges.
| Model | Who receives the privilege | What it contributes |
|---|---|---|
| DAC | The owner role holds OWNERSHIP on the object | The owner can in turn grant access to the object |
| RBAC | A role, which is then assigned to users | The usual way to manage access to securable objects |
| UBAC | The user directly | Extends the framework with flexibility for individual users |
Checkpoint 1 of 6· Match them up
Match each access control model to the way Snowflake applies it
Tap a term, then the definition that fits it.
The overview defines each model in one line. DAC is about ownership, RBAC routes privileges through roles, and UBAC grants them to the user without a role in between.
“Each object has an owner, who can in turn grant access to that object.”Source: docs.snowflake.com
Sources1
2.Ownership: the DAC part of the design
To own an object, a role must hold the OWNERSHIP privilege on it. Each object has exactly one owning role, and by default that is the role that created the object. When the owning role is granted to several users, those users share control of the object. You can move ownership to another role, including a database role, with GRANT OWNERSHIP.
In a regular schema, the owner has every privilege on the object by default. That includes the right to grant privileges to other roles and to revoke them. This is DAC at work: whoever creates a table decides who else can read it. That is convenient, but it also spreads grant decisions across every team that creates objects.
A managed access schema is the design lever that takes those decisions back. In this kind of schema, object owners can no longer grant privileges on their objects. Only the schema owner or a role with the MANAGE GRANTS privilege can. If a requirement says "grant decisions must be centralised" or "object creators must not share data on their own", a managed access schema is the answer.
Checkpoint 2 of 6· Exam question
A new team lead must be able to create users and roles for their department. The security team wants to give them only these abilities, without account-wide privilege management or the ability to create databases. Which system-defined role should be granted?
Correct answer: B — USERADMIN, which holds the CREATE USER and CREATE ROLE privileges and nothing broader for object administration.
- A. Incorrect. SECURITYADMIN can create users and roles but also has MANAGE GRANTS, which lets it grant or revoke privileges on any object, exceeding the stated limit.
- B. Correct. USERADMIN is dedicated to user and role administration and is the least-privileged system role that satisfies the requirement.
- C. Incorrect. ACCOUNTADMIN is the top-level role with the broadest authority, including billing and account settings, so it violates the least-privilege requirement.
- D. Incorrect. SYSADMIN manages objects such as databases and warehouses; it does not hold CREATE USER or CREATE ROLE and it is the opposite of the requested scope.
Checkpoint 3 of 6· Check yourself
Role ANALYST_DEV creates a table in a managed access schema. Who can grant SELECT on that table to another role?
Managed access schemas take grant decisions away from object owners and give them to the schema owner and to roles holding MANAGE GRANTS.
“Only schema owners or a role with the MANAGE GRANTS privilege can grant privileges on objects in a managed access schema.”Source: docs.snowflake.com
Sources1
3.Choosing between RBAC and UBAC
RBAC is the recommended choice for production environments and enterprise governance. It scales, it keeps control in one place, and it makes access easier to audit, because you manage a few roles instead of many individual users.
UBAC is meant for narrower cases, such as private development and collaboration. The docs give the example of building Streamlit applications: during development, the owner of an asset may want to share it with a few colleagues before releasing it to a wider audience.
UBAC doesn't change how much you have to trust object owners. They can already grant access to any role, including broadly accessible roles such as PUBLIC. Grants can pile up under either model, and the remedy in both cases is the managed access schema.
There is one runtime condition you must remember. Snowflake only considers privileges granted directly to a user when that user's secondary roles are set to ALL. Granting to users also needs MANAGE GRANTS on the objects. The documented example grants a single user everything required to run a Streamlit app:
GRANT USAGE ON WAREHOUSE w1 TO USER user1;
GRANT USAGE ON DATABASE d1 TO USER user1;
GRANT USAGE ON SCHEMA d1.s1 TO USER user1;
GRANT USAGE ON STREAMLIT `streamlitApp1` TO USER user1;If your governance rules forbid direct user grants, an administrator can switch UBAC off for the whole account:
ALTER ACCOUNT SET DISABLE_USER_PRIVILEGE_GRANTS = TRUE;Checkpoint 4 of 6· Exam question
A Snowflake administrator is documenting the access models the platform supports. Which description correctly characterizes user-based access control (UBAC) as opposed to role-based access control (RBAC)?
Correct answer: C — Privileges are granted straight to an individual user, whereas RBAC attaches privileges to roles that users are then assigned.
- A. Incorrect. Network policies restrict where a user may connect from and carry no object privileges, so they cannot define an access control framework.
- B. Incorrect. Passing on access through the owning role describes discretionary access control (DAC), where the object owner decides who gets access, not UBAC.
- C. Correct. UBAC ties privileges directly to a specific user, while RBAC places privileges on roles and then assigns roles to users, which is how Snowflake grants nearly all object access.
- D. Incorrect. Snowflake does not derive privileges from column labels or from the warehouse in use; masking policies and tags govern data visibility separately from privilege grants.
Checkpoint 5 of 6· Check yourself
A user was granted SELECT on a table directly, with no role involved. Their query against the table still fails. What is the most likely reason?
Snowflake only evaluates privileges granted directly to a user when all of that user's secondary roles are active.
“Privileges assigned directly to users are only effective when the user has all secondary roles enabled.”Source: docs.snowflake.com
4.System-defined roles and their hierarchy
Every account comes with a small set of system-defined roles. You can't drop them, and you can't revoke the privileges Snowflake granted to them. Each role has a separate administrative job, and they are already linked in a hierarchy:
- ACCOUNTADMIN sits at the top and contains both SYSADMIN and SECURITYADMIN. - SECURITYADMIN holds the global MANAGE GRANTS privilege, so it can grant or revoke any grant. It inherits USERADMIN, because USERADMIN is granted to it. - USERADMIN only manages users and roles, through the CREATE USER and CREATE ROLE privileges. - SYSADMIN creates warehouses, databases and other objects. - PUBLIC is a pseudo-role that every user and every role in the account receives automatically.
| Role | Use case | Position in the hierarchy |
|---|---|---|
| ACCOUNTADMIN | Account-level parameters, billing and credit data, initial setup | Top-level; contains SYSADMIN and SECURITYADMIN |
| SECURITYADMIN | Manage any object grant globally (MANAGE GRANTS); create and manage users and roles | Child of ACCOUNTADMIN; inherits USERADMIN |
| USERADMIN | User and role management only (CREATE USER, CREATE ROLE) | Child of SECURITYADMIN |
| SYSADMIN | Create warehouses, databases and other objects | Child of ACCOUNTADMIN; recommended parent of all custom roles |
| PUBLIC | Cases where explicit access control is not needed | Automatically granted to every user and every role |
Two details are often tested. First, MANAGE GRANTS only lets SECURITYADMIN grant and revoke privileges. It doesn't let SECURITYADMIN create objects; to do that, the role needs the matching create privilege. Second, anything PUBLIC owns is, by definition, available to every user and role in the account.
The top role needs the most care. ACCOUNTADMIN is the only role that sets account-level parameters, and it can view billing and stop any running statement. Even so, it is not a superuser. It can only see and manage objects when it, or a role below it in the hierarchy, has privileges on them. Snowflake recommends granting ACCOUNTADMIN to a small number of people, and to at least two users. Don't make it anyone's default role, and don't use it to create objects or run automated scripts.
Checkpoint 6 of 6· Check yourself
An automated pipeline creates warehouses and tables every night. Which role does Snowflake recommend as the base for its role setup?
Snowflake recommends not using ACCOUNTADMIN for automated scripts. SYSADMIN, or roles below it, can handle all warehouse and database object operations.
“Snowflake recommends using a role other than ACCOUNTADMIN for automated scripts.”Source: docs.snowflake.com
Sources1
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.ACCOUNTADMIN is a superuser that can see and manage every object in the account.Why is that wrong?
ACCOUNTADMIN can only reach objects that it, or a role below it in the hierarchy, holds privileges on. Objects owned by a custom role that isn't in its hierarchy are out of its reach.
Covered in System-defined roles and their hierarchy
2.A privilege granted directly to a user works in every session, whatever role is active.Why is that wrong?
Snowflake only evaluates direct user grants when the user has all secondary roles enabled.
Covered in Choosing between RBAC and UBAC
Sources
Every claim above is drawn from one of these pages, quoted as it was written on the date shown.
- 1.
“Access privileges are assigned directly to users.”
↩︎ Three models in one framework“Each securable object is owned by a single role, which by default is the role used to create the object.”
↩︎ Ownership: the DAC part of the design“in a managed access schema, object owners lose the ability to make grant decisions.”
↩︎ Ownership: the DAC part of the design“Role that encapsulates the SYSADMIN and SECURITYADMIN system-defined roles.”
↩︎ System-defined roles and their hierarchy“Inherits the privileges of the USERADMIN role via the system role hierarchy (that is, USERADMIN role is granted to SECURITYADMIN).”
↩︎ System-defined roles and their hierarchy“Pseudo-role that is automatically granted to every user and every role in your account.”
↩︎ System-defined roles and their hierarchy“System-defined roles cannot be dropped.”
↩︎ System-defined roles and their hierarchy“Access control considers privileges assigned directly to users only when USE SECONDARY ROLE is set to ALL.”
↩︎ Exam trap 2“Each object has an owner, who can in turn grant access to that object.”
↩︎ Checkpoint - 2.
“User-based access control (UBAC) is intended for use cases such as private development and collaboration.”
↩︎ Choosing between RBAC and UBAC“Role-based access control (RBAC) is your foundation for access control in Snowflake.”
↩︎ Key concept“Note that ACCOUNTADMIN is not a superuser role.”
↩︎ Exam trap 1“Only schema owners or a role with the MANAGE GRANTS privilege can grant privileges on objects in a managed access schema.”
↩︎ Checkpoint“UBAC does not provide object owners with new levels of privilege.”
↩︎ Prediction“Snowflake recommends using a role other than ACCOUNTADMIN for automated scripts.”
↩︎ Checkpoint - 3.
“A user with MANAGE GRANTS privileges on objects can grant privileges directly to users.”
↩︎ Choosing between RBAC and UBAC“Privileges assigned directly to users are only effective when the user has all secondary roles enabled.”
↩︎ Checkpoint