System Roles + Custom Roles + Secondary Roles

Micro-Concept 1: The Six System Roles — What Each One Does

Memorise this table. The exam rarely tests all six in one question, but at least one of them appears every sitting.

A visual of the hierarchy:

           ACCOUNTADMIN
              /        \
     SECURITYADMIN    SYSADMIN  ←  custom roles roll up here
          |              |
      USERADMIN     (your custom role hierarchy)
                          |
                       PUBLIC  ←  inherited by everyone

  ORGADMIN  →  separate, not part of the standard hierarchy

Micro-Concept 2: The Network-Policy Trap (SECURITYADMIN, not SYSADMIN)

One specific question keeps reappearing on the exam, almost word for word: “Which role is recommended to create and manage network policies?” The answer is SECURITYADMIN. This is one of the highest-confidence “free mark” patterns on Domain 2 — if you see it phrased this way, lock in SECURITYADMIN and move on.

The trap is that the word “network” sounds infrastructural, so the brain reaches for SYSADMIN. The reasoning behind the correct answer:

• Per the Snowflake docs on CREATE NETWORK POLICY, only SECURITYADMIN or higher, or a role with the global CREATE NETWORK POLICY privilege, can create one.
• SECURITYADMIN holds MANAGE GRANTS. It is Snowflake’s designated security and access-management role — restricting network access fits squarely inside that scope.
• SYSADMIN owns warehouses and databases. That is compute and storage, not security policy.
• USERADMIN handles users and roles. Different domain again.

ACCOUNTADMIN can create network policies, because it inherits SECURITYADMIN. But the documented best-practice answer is SECURITYADMIN. Least privilege says don’t reach for ACCOUNTADMIN when a more specific role does the job.

Micro-Concept 3: ACCOUNTADMIN Is NOT a Superuser

This is the single most-missed Domain 2 fact in my training sessions. ACCOUNTADMIN sits at the top of the hierarchy, but it cannot, by default, modify or drop objects owned by a custom role that lives outside its inheritance chain.

-- A custom role exists in isolation by default
USE ROLE USERADMIN;
CREATE ROLE rogue_r;

-- ACCOUNTADMIN cannot inherit rogue_r's privileges unless rogue_r is granted to it
-- (directly or via the SYSADMIN chain)
USE ROLE ACCOUNTADMIN;
USE ROLE rogue_r;  -- only works if rogue_r is granted to ACCOUNTADMIN
-- If rogue_r created a table, ACCOUNTADMIN cannot drop it directly.

This is the whole reason the “grant every custom role to SYSADMIN” rule exists. Without that grant, you end up with orphan roles whose objects sit invisible to anyone except an ACCOUNTADMIN with an explicit grant. In production, that becomes an incident waiting to happen — the role’s owner leaves the team, the role gets dropped, and suddenly nobody can manage the objects underneath.

The practical rules Snowflake documents:

• Do not make ACCOUNTADMIN anyone’s default role. Snowflake explicitly recommends against it in the access control best-practices doc.
• Limit ACCOUNTADMIN to roughly two users. Enough for redundancy if one person is locked out; few enough that the role is not used casually.
• Require MFA for every ACCOUNTADMIN user. Snowflake’s MFA rollout makes this enforced rather than recommended on most accounts now.
• Roll custom roles up to SYSADMIN so the SYSADMIN view of the account is complete.

Micro-Concept 4: Custom Role Hierarchy — The Recommended Shape

Snowflake documents a four-step pattern for creating a custom role. The exam tests recognition of this pattern, not the exact sequence of statements.

1. Use USERADMIN to create the role. Plain CREATE ROLE needs the CREATE ROLE account privilege. USERADMIN has it.
2. Use SECURITYADMIN to grant privileges to the role. Granting privileges needs MANAGE GRANTS, which SECURITYADMIN holds.
3. Grant the new role to SYSADMIN. This is the line that makes the role visible to anyone administering as SYSADMIN.
4. Grant the new role to the users who need it. Without this final grant the role exists but nobody can use it.

A working example end to end:

USE ROLE USERADMIN;
CREATE ROLE finance_analyst_r;

USE ROLE SECURITYADMIN;
GRANT USAGE ON WAREHOUSE  lab_xs           TO ROLE finance_analyst_r;
GRANT USAGE ON DATABASE   sales_db         TO ROLE finance_analyst_r;
GRANT USAGE ON SCHEMA     sales_db.finance TO ROLE finance_analyst_r;
GRANT SELECT ON ALL TABLES IN SCHEMA sales_db.finance TO ROLE finance_analyst_r;

-- Roll the custom role up to SYSADMIN (visibility / management)
GRANT ROLE finance_analyst_r TO ROLE SYSADMIN;

-- Hand it to a user
GRANT ROLE finance_analyst_r TO USER alice;

If you only commit two sentences from this section to memory, make it these: USERADMIN creates roles. SYSADMIN is the recommended parent. Almost every custom-role question on the exam answers to one of those two facts.

Micro-Concept 5: Secondary Roles — Multiple Roles in One Session

Without secondary roles, a session has exactly one active role: the primary role. Switching means running USE ROLE other_r, which replaces the current role completely. The moment you need a JOIN across two tables owned by different roles, this becomes painful.

Secondary roles solve that. The syntax is straightforward:

USE SECONDARY ROLES { ALL | NONE | role1 [, role2 ...] }

Three modes:

Three facts the exam tests repeatedly:

• Only the primary role can CREATE objects. Secondary roles add query and DML privileges. They do not create. They do not own. This is the most-tested nuance of the whole feature.
• The set of secondary roles re-evaluates on every SQL statement. Grant a role mid-session and it takes effect on the next statement. Revoke one and it disappears the same way.
• The default for new users is now 'ALL'. BCR-1692 (rolled out from August 2024 through March 2025) changed DEFAULT_SECONDARY_ROLES from NULL (which behaved as no secondary roles activated) to ('ALL'). A fresh user now starts every session with every granted role active. Check SHOW USERS for the default_secondary_roles column to confirm what your account is on.

One observation from production: this BCR change quietly broke a lot of RBAC implementations that assumed a user could only see one database at a time. If your organisation runs least-privilege strictly and tested it pre-2024, retest it. The third bullet above is exactly the kind of “small change, big consequence” item that shows up as a tricky scenario question on newer exam forms.

Inspect the current state of any session:

SELECT CURRENT_ROLE();              -- the primary role
SELECT CURRENT_SECONDARY_ROLES();   -- a JSON: {"roles": "...", "value": "ALL"|"NONE"|...}

Official docs for today’s topics.

Role hierarchy and context functions.