What you will be able to do
- Choose the right warehouse privilege (USAGE, OPERATE, MODIFY, MONITOR) or MANAGE WAREHOUSES
- Use future grants and managed access schemas, and predict how schema-level and database-level future grants interact
- Predict which grants a clone keeps, and audit grants with SHOW GRANTS
- Let non-administrators see billing and usage, and control access to Cortex AI functions and models
1.Warehouse privileges
Each warehouse privilege does a different job. Least privilege means granting only the one a role actually needs. Running queries requires only USAGE. Starting, stopping, suspending or resuming the warehouse requires OPERATE. Resizing or changing other properties requires MODIFY. Viewing query history and usage requires MONITOR.
| Privilege | What it enables |
|---|---|
| USAGE | Use the warehouse to run queries. If auto-resume is on, a submitted statement resumes the warehouse |
| OPERATE | Change state (stop, start, suspend, resume), view current and past queries, and abort running queries |
| MODIFY | Alter any property, including size. Also needed to assign the warehouse to a resource monitor |
| MONITOR | View current and past queries and usage statistics |
| MANAGE WAREHOUSES (global) | Equivalent to MODIFY, MONITOR and OPERATE on every warehouse in the account |
MANAGE WAREHOUSES is a convenient way to delegate warehouse administration, and ACCOUNTADMIN must grant it. It doesn't include USAGE. Assigning a warehouse to a resource monitor needs MODIFY, and even then only ACCOUNTADMIN can make that assignment.
Checkpoint 1 of 8· Match them up
Match each operations need to the narrowest warehouse privilege that meets it.
Tap a term, then the definition that fits it.
Each privilege covers one kind of action, so a role can get exactly the one it needs.
“Enables changing the state of a warehouse (stop, start, suspend, resume).”Source: docs.snowflake.com
Sources1
2.Future grants and managed access schemas
GRANT ... ON ALL TABLES IN SCHEMA covers only the tables that already exist. To cover tables that will be created later, define a future grant on the schema or the database.
Checkpoint 2 of 8· Fill the gap
Which keyword gives read_only SELECT on tables created in d1.s1 from now on?
GRANT SELECT ON ? TABLES IN SCHEMA d1.s1 TO ROLE read_only;ON ALL TABLES affects only existing tables. ON FUTURE TABLES makes the grant apply automatically to tables created later.
Source: docs.snowflake.comGRANT SELECT ON FUTURE TABLES IN DATABASE d1 TO ROLE r1;Two more limits apply. Each object type can have at most one future grant of OWNERSHIP. Database-level future grants apply to both regular schemas and managed access schemas.
In a regular schema, whoever owns an object can grant access to it. In a managed access schema, object owners lose that ability. Only the schema owner, or a role with MANAGE GRANTS, can grant privileges on objects in the schema. This puts grant decisions in one place.
Checkpoint 3 of 8· Check yourself
In managed access schema SALES.CORE, role ETL_ROLE owns table ORDERS. Which role can grant SELECT on ORDERS to ANALYST?
In a managed access schema, object owners can't make grant decisions. That ability belongs to the schema owner or a role with MANAGE GRANTS.
“in a managed access schema, object owners lose the ability to make grant decisions.”Source: docs.snowflake.com
3.How cloning affects grants
When you clone a database or schema, the cloned child objects keep the privileges granted on the originals. The clone of the database or schema itself does not keep the privileges granted on the source container. Grants on that new container start from scratch.
For most other objects, CREATE <object> ... CLONE copies no grants. Commands that support COPY GRANTS, such as CREATE TABLE ... CLONE, can copy every privilege from the source except OWNERSHIP. In every other case, you have to grant the needed privileges on the clone yourself.
Checkpoint 4 of 8· Check yourself
You clone database PROD to DEV. Role R_READ had USAGE on PROD and SELECT on PROD.S1.T1. What does R_READ have in DEV?
Child objects in a cloned container keep their grants, but the cloned container does not. R_READ keeps SELECT on the cloned table but needs USAGE on DEV granted again before it can reach it.
“The clone of the container itself (database or schema) doesn’t inherit the privileges granted on the source container.”Source: docs.snowflake.com
Sources4
4.Auditing grants and opening billing data to non-administrators
SHOW GRANTS lists privileges that have been explicitly granted to roles, users and shares. Its variants answer different audit questions. SHOW GRANTS ON shows who has access to an object. SHOW GRANTS TO ROLE or TO USER shows what a role or user holds. SHOW GRANTS OF ROLE shows who has been granted a role. SHOW FUTURE GRANTS IN SCHEMA or IN DATABASE shows the future grants defined there. On its own, SHOW GRANTS lists the roles granted to the current user. Two global privileges support this kind of oversight: MONITOR ROLE to view roles and MONITOR USER to view users.
SHOW GRANTS ON ACCOUNT [ LIMIT <rows> ]
SHOW GRANTS ON <object_type> <object_name> [ LIMIT <rows> ]By default, only account administrators can see usage and billing history, such as warehouse metering and storage usage. To show it to someone else, such as a FinOps analyst, grant the global MONITOR USAGE privilege to a system-defined or custom role. You don't need to grant them ACCOUNTADMIN. Only ACCOUNTADMIN can grant MONITOR USAGE.
Checkpoint 5 of 8· Check yourself
A finance analyst needs account-level usage and billing history but must not administer the account. What is the right grant?
MONITOR USAGE is the global privilege that opens account-level usage and billing history to roles other than ACCOUNTADMIN.
“Grants the ability to monitor account-level usage and historical information for databases and warehouses”Source: docs.snowflake.com
5.Access control for Cortex AI functions and models
To use all the Snowflake Cortex AI Functions, a user needs two things: the USE AI FUNCTIONS account privilege and the SNOWFLAKE.CORTEX_USER database role. USE AI FUNCTION <name> grants one specific function. By default, CORTEX_USER is granted to PUBLIC, so every user has it. Granting CORTEX_USER to one more role therefore narrows nothing. To limit Cortex to certain roles, revoke CORTEX_USER from PUBLIC and grant it only to those roles.
Models in Snowflake have two levels of access: - USAGE: run inference methods, but no access to the model's underlying artifacts. - READ: run inference methods, plus read-only access to the artifacts and metadata.
An application that only needs predictions should get USAGE. Let me note one gap: these sources don't say which privilege is needed to register new model versions.
Checkpoint 6 of 8· Check yourself
Every user can currently call Cortex functions. Security wants only DATA_SCIENCE_ROLE to have access. What is the right change?
Everyone has access because PUBLIC holds CORTEX_USER. Adding another grant changes nothing until the PUBLIC grant is revoked.
“By default, the CORTEX_USER database role is granted to the PUBLIC role, which means every user has it.”Source: docs.snowflake.com
Checkpoint 7 of 8· Exam question
The finance department needs read access to the tables in the database ANALYTICS_DB, and the privileges should be defined inside that database so they travel with it. Analysts log in with the account role FINANCE_ANALYST. What is the MOST appropriate approach?
Correct answer: A — Create a database role in ANALYTICS_DB, grant SELECT privileges to it, and grant that database role to the FINANCE_ANALYST account role.
- A. Correct. Database roles are granted to account roles (or other database roles in the same database), and users then activate the account role, which carries the database role's privileges.
- B. Incorrect. A database role cannot be granted directly to a user; the grant must go to an account role or to another database role in the same database.
- C. Incorrect. A database role cannot be activated as a session's primary role with USE ROLE; it only takes effect through an account role that has been granted it.
- D. Incorrect. DEFAULT_ROLE must be an account role granted to the user. Database roles are not assignable as a user's default or primary role.
Checkpoint 8 of 8· Exam question
A developer clones the schema PROD.SALES into DEV.SALES_COPY using CREATE SCHEMA ... CLONE. Select TWO statements that correctly describe the privileges on the cloned objects.(Select 2)
Correct answers: A, C — Privileges granted on the tables inside the source schema are copied to the corresponding cloned tables in the new schema.; The role that runs the CLONE statement owns the new schema, and grants on the source schema are not carried over.
- A. Correct. When a container such as a schema or database is cloned, the child objects keep the privileges granted on their source counterparts.
- B. Incorrect. The cloned container does not inherit the privileges granted on the source schema itself; roles need fresh grants on it.
- C. Correct. The cloning role owns the new top-level object, and the source schema's own grants are not copied, which is why access must be re-granted.
- D. Incorrect. Future grants apply to objects created in the schema or database, including those created by cloning, so they are not ignored.
- E. Incorrect. Ownership of the clone goes to the role that executes the statement, not to the source object's owner role.
Sources1
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.MANAGE WAREHOUSES lets a role run queries on every warehouse.Why is that wrong?
MANAGE WAREHOUSES equals MODIFY, MONITOR and OPERATE on all warehouses. USAGE, which is needed to run queries, is not part of it.
Covered in Warehouse privileges
2.Database-level and schema-level future grants on the same object type add together.Why is that wrong?
The schema-level future grants win and the database-level ones are ignored for that schema.
Covered in Future grants and managed access schemas
3.To limit Cortex to one team, grant CORTEX_USER to that team's role.Why is that wrong?
PUBLIC holds CORTEX_USER by default, so every user keeps access until it is revoked from PUBLIC.
Covered in Access control for Cortex AI functions and models
Sources
Every claim above is drawn from one of these pages, quoted as it was written on the date shown.
- 1.
“Note that only the ACCOUNTADMIN role can assign warehouses to resource monitors.”
↩︎ Warehouse privileges“Enables using a virtual warehouse and, as a result, executing queries on the warehouse.”
↩︎ Warehouse privileges“Users need both the USE AI FUNCTIONS account privilege and the CORTEX_USER database role to use all Snowflake Cortex AI Functions.”
↩︎ Access control for Cortex AI functions and models“For models, USAGE grants the ability to run inference methods. It doesn’t grant access to the model’s underlying artifacts.”
↩︎ Access control for Cortex AI functions and models“For models, READ grants the ability to run inference methods along with read-only access to the model’s underlying artifacts and metadata.”
↩︎ Access control for Cortex AI functions and models“equivalent to granting the MODIFY, MONITOR, and OPERATE privileges on all warehouses in an account”
↩︎ Exam trap 1“Enables changing the state of a warehouse (stop, start, suspend, resume).”
↩︎ Checkpoint“Grants the ability to monitor account-level usage and historical information for databases and warehouses”
↩︎ Checkpoint - 2.
“No more than one future grant of the OWNERSHIP privilege is allowed on each securable object type.”
↩︎ Future grants and managed access schemas“Database-level future grants apply to both regular and managed access schemas.”
↩︎ Future grants and managed access schemas“the schema-level grants take precedence over the database level grants, and the database level grants are ignored.”
↩︎ Exam trap 2“the schema-level grants take precedence over the database level grants, and the database level grants are ignored.”
↩︎ Prediction - 3.
“statement grants the SELECT privilege on all existing tables only.”
↩︎ Future grants and managed access schemas“By default, this information can be accessed/viewed only by account administrators.”
↩︎ Auditing grants and opening billing data to non-administrators“To enable users who are not account administrators to access/view this information, grant the following privileges to a system-defined or custom role.”
↩︎ Auditing grants and opening billing data to non-administrators - 4.
“the clone inherits all granted privileges on the clones of all child objects contained in the source object”
↩︎ How cloning affects grants“the create operation copies all privileges, except OWNERSHIP, from the source table to the new table.”
↩︎ How cloning affects grants“The clone of the container itself (database or schema) doesn’t inherit the privileges granted on the source container.”
↩︎ Checkpoint - 5.
“Lists all access control privileges that have been explicitly granted to roles, users, and shares.”
↩︎ Auditing grants and opening billing data to non-administrators
Also cited
“you can revoke this database role from the PUBLIC role and then grant it to specific roles.”
↩︎ Exam trap 3“By default, the CORTEX_USER database role is granted to the PUBLIC role, which means every user has it.”
↩︎ Checkpoint“in a managed access schema, object owners lose the ability to make grant decisions.”
↩︎ Checkpoint