3.1 Account Management and Data Governance Overview

What This Domain Covers

Account Management and Data Governance is roughly 20% of the SnowPro Core (exam code COF-C03) blueprint, making it tied for the largest weighted domain alongside Performance and Cost Optimization. It tests how you secure a Snowflake account: who can do what (access control), how identities are managed (users and authentication), how objects are organized (the hierarchy), and how sensitive data itself is protected (governance policies). The exam rarely asks for a bare definition. It asks which role should run a command, which privilege is missing, or which policy enforces a rule.

The two access-control frameworks

Snowflake combines two models, and the exam expects you to name both:

• Discretionary Access Control (DAC): every securable object has an owner, and the owner (the role that created it) has full control and can grant access to others.
• Role-Based Access Control (RBAC): privileges are assigned to roles, and roles are assigned to users (or to other roles). A user never holds a privilege directly — they activate a role that holds it.

This is a frequent trap: you cannot GRANT SELECT ... TO USER. You grant to a role, then grant the role to the user. A user's effective privileges are the union of all roles in their active role's inheritance chain.

Securable Objects and the Containment Hierarchy

A securable object is anything access can be granted on. Snowflake organizes them in a strict containment hierarchy. Knowing the order matters because privileges on a container do not automatically flow to its contents — you must grant USAGE on the database and schema to even see objects inside them.

Note that warehouses, users, roles, resource monitors, and shares are account-level objects — they are not inside a database or schema. A common exam distractor places a warehouse "in a schema." It is not.

Privileges flow to roles

Typical object privileges include USAGE (on databases, schemas, warehouses), SELECT/INSERT/UPDATE/DELETE (on tables), CREATE <object> (on a schema or database), OPERATE and MONITOR (on warehouses), and OWNERSHIP. To query a table, a role needs USAGE on the database, USAGE on the schema, USAGE on the warehouse, and SELECT on the table — four grants, not one.

How the Domain Is Tested

Expect scenario stems: "A new analyst cannot query a table even though SELECT was granted — what is missing?" (answer: USAGE on the database/schema). Or: "Which role should create a warehouse?" (SYSADMIN, by convention). Or: "Which feature hides credit-card numbers from analysts but shows them to auditors?" (a masking policy, conditioned on the current role).

A mental model: object vs. data

Keep two layers separate in your head:

1. Object access (RBAC/DAC): can this role even see or use the object?
2. Data access (governance): of the rows and columns in that object, which can this role see?

Masking policies and row access policies operate on layer 2. A role can hold SELECT on a table (layer 1) and still see only masked values or a filtered subset of rows (layer 2). Many questions hinge on recognizing that the analyst can query the table but the policy changed the result.

Study tactic

For every command in this chapter, ask three questions: which role has the privilege, what object level does it act on, and what governance policy (if any) further restricts the result. If you can answer all three for a scenario, you will get the question right even when the stem buries the cue.

Ownership, Managed Access, and the Account Layer

Two refinements complete the baseline. First, OWNERSHIP is special: the owning role can grant or revoke any privilege on its object and can transfer ownership with GRANT OWNERSHIP ... COPY CURRENT GRANTS. By default, the role that runs the CREATE statement becomes the owner, so the active role at creation time matters. Second, a schema can be created WITH MANAGED ACCESS (CREATE SCHEMA ... WITH MANAGED ACCESS); in a managed-access schema, only the schema owner (or a role with MANAGE GRANTS) can grant privileges on objects in it — object owners can no longer grant access on their own objects.

This centralizes governance and is a tested distinction from ordinary DAC, where any object owner can grant.

The account and organization layer

Above databases sit account-level constructs that this domain manages directly: users, roles, warehouses, resource monitors, shares, network policies, and security integrations. Above the account sits the organization, managed by ORGADMIN, which can create new accounts and view consolidated usage across them. A Snowflake account identifier combines the organization name and the account name. Recognizing which layer an object lives on tells you which role administers it and why a privilege grant succeeds or fails.

Keeping this map in mind prevents the common error of looking for a database-level role to fix an account-level problem.