SnowPro Certification Module: Access Control Roles, Sharing, and Authentication

The Heavyweight of the SnowPro Certification: Access Control

Access control in Snowflake answers two questions: who can do what, and who decides? Nail this concept and you’ve already conquered 25% of the COF-C03 exam.

Here is exactly what you need to know:

• System-defined roles and their hierarchy
• Account roles vs. database roles (when to use each)
• Data sharing mechanisms (Direct Share, Private Listing, Public Listing)
• Authentication protocols (SAML 2.0, OAuth 2.0)

One mental model runs through all of this: Snowflake separates security from data. SECURITYADMIN handles users, roles, and policies. SYSADMIN handles databases, tables, and warehouses. ACCOUNTADMIN sits above both for account-level operations. Master that split and most exam questions answer themselves.

Let’s break this down piece by piece so that when exam day comes, not a single access control question catches you off guard.

Module 1: The Hierarchy of Power (Basic Roles)

Every query in Snowflake runs as a role, not a user. Once you understand the role hierarchy, you understand how Snowflake thinks about permissions: who does what, who controls what, and how these roles shape your entire platform.

Every Snowflake account comes with system-defined roles out of the box. The exam expects you to know exactly what each one controls:

Good to know

1- After creating a custom role, always assign it up to SYSADMIN

GRANT ROLE my_custom_role TO ROLE SYSADMIN;

2- Snowflake uses two access control models together:

• RBAC (Role-Based Access Control) permissions are assigned to roles, roles are assigned to users. Users never get privileges directly
• DAC (Discretionary Access Control) object owners can grant access to others

3- Roles are hierarchical: higher roles inherit all privileges from lower roles

4- Snowflake also provides built-in roles with predefined responsibilities:

• The PUBLIC role is automatically granted to every user and role
• USERADMIN can create users and roles but cannot grant object-level privileges

Exam traps box

Module 2: Account Roles vs. Database Roles

Two types of roles exist in Snowflake. Account roles have been around since the beginning. Database roles came later to solve a specific problem: keeping permissions scoped to a single database.

Key idea

Database roles are scoped to ONE database. They cannot cross boundaries, cannot be granted directly to users, and must flow through an account role to reach anyone.

Think of it like office badges: account role = building access, database role = floor access. The floor badge is useless without the building badge first.

What you need to remember:

• Database roles can be granted to account roles, not directly to users
• Database roles can be granted to other database roles within the same database, letting you build local hierarchies
• The owner of a database role is always an account role (by default, the one that created it)
• Database roles don’t appear in SHOW ROLES. Use SHOW DATABASE ROLES IN DATABASE <name>
• If you clone or replicate a database, database roles come with it. Account roles don’t.

Main use case: packaging permissions for data sharing.

When to use each

Exam traps box

Database roles define what someone can access. Shares define how you deliver that access to another account. Module 3 connects the two.

Module 3: Data Sharing

You’ve packaged permissions into a database role. But how do you get that package to a partner on a different Snowflake account? That’s the problem data sharing solves.

Data sharing lets you give another Snowflake account access to your data without copying it. No ETL, no file exports, no duplication. The data stays in your storage. They query it with their compute.

Provider pays for storage. Consumer pays for compute. The data never moves.

Three ways to share

Snowflake offers three mechanisms to deliver data to another account. Each has different constraints on where your consumer can be located and whether the share is visible publicly.

The key constraint is geography. Direct Share only works when both accounts are on the same cloud provider AND the same region. The moment your partner is on a different cloud or a different region, you need a Listing.

Choosing the right mechanism

With three options, how do you decide? This decision tree answers it in seconds.

Key Idea

Data sharing has two components:

• Database role = the package of privileges (what they can access)
• Share = the delivery vehicle (how it reaches them)

The share contains the database role. The database role contains the privileges. FUTURE grants make it self-maintaining.

Think of shares like envelopes and database roles like letters inside. You write the letter once, put it in as many envelopes as you need, and each envelope goes to a different recipient.

Exam traps box

Module 4: Authentication

Sharing gets data to external partners. But before anyone queries anything, Snowflake needs to verify who they are. That’s authentication. Authentication answers one question: are you who you claim to be?

Two protocols, two purposes

Snowflake uses two main protocols. They solve different problems and serve different users.

The diagram shows the split:

• SAML 2.0 is for humans logging in through a browser. User clicks “Sign in with Okta,” authenticates there, receives a SAML assertion, Snowflake trusts it.
• OAuth 2.0 is for applications connecting on behalf of a user. Tableau needs to query Snowflake. OAuth provides a token without exposing the user’s password.

Different entry points, same destination. Snowflake validates both.

Identity Providers (IdP)

The IdP is where users actually prove their identity. Snowflake doesn’t verify passwords directly for SSO. It trusts the IdP to do that.

What about SCIM?

SCIM handles lifecycle. When someone joins your company, SCIM creates their Snowflake user. When they leave, SCIM deactivates it. Automatic sync from your IdP.

Exam traps box

You now understand who can do what (roles), how permissions are scoped (database roles), how data reaches partners (sharing), and how users prove their identity (authentication). That covers roughly 25% of the COF-C03 exam.

Conclusion

You’ve now covered the four pillars of Snowflake access control.

Module 1 taught you the role hierarchy. SECURITYADMIN manages who: users, roles, policies. SYSADMIN manages what: databases, warehouses, tables. ACCOUNTADMIN sits above both for account-level tasks like shares and billing. That split answers most permission questions.

Module 2 introduced database roles. They stay inside one database, can’t be granted directly to users, and must flow through account roles. Think building badge vs floor badge. The floor badge is useless without the building badge first.

Module 3 covered data sharing. Direct Share works only when both accounts are on the same cloud and same region. Cross-cloud or cross-region requires Private Listing or Public Listing. Database roles make shares self-maintaining with FUTURE grants.

Module 4 explained authentication. SAML 2.0 is for humans logging in via browser. OAuth 2.0 is for applications connecting on behalf of users. SCIM provisions users but doesn’t authenticate them. That distinction is tested constantly.