What you will be able to do
- Give Feature Store producer and consumer roles the right privileges, including future grants for feature views that do not exist yet
- Choose between OWNERSHIP, USAGE and READ on a registered model, depending on how the model will be used for inference
- List the privileges a role needs to create a compute pool and to run ML Jobs on one
Key concept
ML objects are governed by ordinary RBAC — Feature views, datasets, models and compute pools are regular Snowflake objects. You secure them with normal role grants and role hierarchies. ML does not have its own permission system.
1.Feature Store producers and consumers
A Snowflake Feature Store is a schema that holds dynamic tables, views, tags and datasets. Access to it is plain RBAC on those objects. The documentation describes two kinds of user. Producers create and operate on feature views. Consumers read information about feature views and entities. Each kind usually gets its own role, and the two roles form a hierarchy: the consumer role is granted to the producer role, so producers get every consumer privilege plus their own. If you run several feature stores, you usually create one producer/consumer pair per store, or one pair per logical group of stores.
| Privilege | On | Producer | Consumer |
|---|---|---|---|
| CREATE DYNAMIC TABLE, CREATE VIEW, CREATE TAG | Feature store schema | Required | Not required |
| OPERATE | Dynamic tables and tasks in the feature store schema | Required (manage refresh settings) | Not required |
| CREATE TABLE, CREATE DATASET | Feature store schema and/or destination schema | Required for generating training datasets | Optional, for generating training datasets |
| USAGE | Feature store database and schema | Inherited from consumer | Required |
| SELECT, MONITOR | Dynamic tables in the feature store schema | Inherited from consumer | Required |
| SELECT, REFERENCE | Views in the feature store schema | Inherited from consumer | Required |
| USAGE | Warehouse passed to the feature store initializer | Required | Required |
There is one producer detail to watch. A Snowflake-managed feature view is backed by a dynamic table, and if it uses incremental refresh, its source tables must already have change tracking enabled. If they don't, the producer needs OWNERSHIP of those tables so change tracking can be turned on automatically when the feature view is created. Producers also need CREATE SCHEMA, unless the feature store schema already exists and they have usage on it.
-- Grant CONSUMER role privileges
GRANT USAGE ON DATABASE IDENTIFIER($FS_DATABASE) TO ROLE IDENTIFIER($FS_ROLE_CONSUMER);
GRANT USAGE ON SCHEMA IDENTIFIER($SCHEMA_FQN) TO ROLE IDENTIFIER($FS_ROLE_CONSUMER);
GRANT SELECT, MONITOR ON FUTURE DYNAMIC TABLES IN SCHEMA IDENTIFIER($SCHEMA_FQN) TO ROLE IDENTIFIER($FS_ROLE_CONSUMER);
GRANT SELECT, MONITOR ON ALL DYNAMIC TABLES IN SCHEMA IDENTIFIER($SCHEMA_FQN) TO ROLE IDENTIFIER($FS_ROLE_CONSUMER);
GRANT SELECT, REFERENCES ON FUTURE VIEWS IN SCHEMA IDENTIFIER($SCHEMA_FQN) TO ROLE IDENTIFIER($FS_ROLE_CONSUMER);
GRANT SELECT, REFERENCES ON ALL VIEWS IN SCHEMA IDENTIFIER($SCHEMA_FQN) TO ROLE IDENTIFIER($FS_ROLE_CONSUMER);The same script grants USAGE on future and existing datasets, and USAGE on the warehouse, to the consumer. It builds the hierarchy by granting the producer role to SYSADMIN and the consumer role to the producer. If you don't want to write the SQL yourself, snowflake-ml-python 1.6.3 and later include a setup_feature_store utility. It takes the database, schema, warehouse and both role names, and creates the same structure. Either way, the person running the setup needs a role with MANAGE GRANTS, CREATE ROLE and CREATE SCHEMA on the database. That can be ACCOUNTADMIN or a custom role that holds those privileges.
Checkpoint 1 of 5· Fill the gap
Complete the role hierarchy so the producer inherits every consumer privilege.
-- Build role hierarchy
GRANT ROLE IDENTIFIER($FS_ROLE_PRODUCER) TO ROLE SYSADMIN;
GRANT ROLE IDENTIFIER($FS_ROLE_CONSUMER) TO ROLE IDENTIFIER( ? );Granting the consumer role to the producer role gives producers every consumer privilege. That matches the documented rule that producers need all consumer privileges.
Source: docs.snowflake.comCheckpoint 2 of 5· Check yourself
You want to avoid using ACCOUNTADMIN to set up Feature Store roles. Which privileges must your custom setup role hold?
Setting up the roles means creating roles, creating the schema and granting privileges. A custom role with these three privileges can do this in place of ACCOUNTADMIN.
“A role with MANAGE GRANTS, CREATE ROLE, and CREATE SCHEMA ON DATABASE <DB> privileges is needed”Source: docs.snowflake.com
Checkpoint 3 of 5· Exam question
A data science team needs a consumer role that can read feature views for batch inference in a Feature Store schema, but must not create or refresh feature views. Which set of grants is the minimal one?
Correct answer: A — USAGE on the database and schema, SELECT and MONITOR on dynamic tables, SELECT and REFERENCE on views in the schema, and USAGE on a warehouse.
- A. Correct. Consumers need USAGE on the container objects, SELECT and MONITOR on the dynamic tables backing feature views, SELECT and REFERENCE on the views, and a warehouse to run queries.
- B. Incorrect. CREATE DYNAMIC TABLE and CREATE TAG are producer privileges for creating feature views, which exceeds the read-only requirement.
- C. Incorrect. Owning the schema gives broad administrative control, violating least privilege, and it does not cover objects owned by other roles.
- D. Incorrect. Feature views are backed by dynamic tables and views in the Feature Store schema, so privileges on those objects are required, not on source tables.
Sources1
2.Model Registry privileges: OWNERSHIP, USAGE and READ
A model logged to the Model Registry is a schema-level object, and it has its own small set of privileges. Exam questions usually come down to how the model will run: inside a warehouse, or on Snowpark Container Services (SPCS).
| Privilege | What it allows | What it does not allow |
|---|---|---|
| OWNERSHIP | Full control: manage versions, access artifacts, update metadata | Being held by more than one role (but the owning role can be granted to many users or roles) |
| USAGE | Warehouse inference, SHOW MODELS, SHOW VERSIONS IN MODEL | Access to model code, weights or other artifacts |
| READ | SPCS inference, model files, metadata, SHOW MODELS, SHOW VERSIONS IN MODEL | Changing the model (it is read-only) |
The model owner grants one of the two read-only privileges to whichever role runs predictions. A production role that only calls the model from SQL in a warehouse needs USAGE. A role that serves the model from SPCS, or needs the model files, needs READ. Because models are ordinary objects, you can also query them through INFORMATION_SCHEMA.MODEL_VERSIONS. That view holds models and their versions, and there is no separate model view.
GRANT USAGE ON MODEL my_model TO ROLE prod_role;
-- OR
GRANT READ ON MODEL my_model TO ROLE prod_role;Checkpoint 4 of 5· Match them up
Match each requirement to the least model privilege that meets it.
Tap a term, then the definition that fits it.
USAGE covers warehouse inference only. READ adds SPCS inference and model files. Only OWNERSHIP can manage versions and metadata.
“Read-only access to the model, allowing SPCS inference (prediction), model files, metadata”Source: docs.snowflake.com
Sources2
3.Compute pool privileges for ML workloads
Container-based ML workloads run on compute pools, and creating a pool is a separate privilege from using one. The source for this section is the access-control page for Snowflake ML Jobs. It separates setting up a new environment from running jobs in an environment that already exists.
| Privilege | On | Purpose |
|---|---|---|
| CREATE COMPUTE POOL | Account | Create a new compute pool (or use an existing pool instead) |
| CREATE SCHEMA | Database | Optional: a dedicated schema makes it easy to clean up old jobs and payload stages |
| USAGE | Database and schema where ML Jobs run | Basic access |
| CREATE SERVICE | Schema | Create and manage ML Jobs |
| USAGE | Compute pool | Use the pool for ML workloads |
| USAGE (or CREATE STAGE on the schema) | Stage | Upload job payloads; a missing stage is created on your behalf |
Two consequences matter. First, a data scientist who only runs jobs does not need CREATE COMPUTE POOL on the account. USAGE on an existing pool plus CREATE SERVICE on the schema is enough. Keep the account-level privilege for whoever provisions pools. Second, compute access does not grant data access. The job's role still needs its own privileges on the tables, warehouses and other resources the workload reads. So the Feature Store and model grants above still apply when the code runs on a compute pool. These sources only describe compute pool privileges for ML Jobs. They do not list the privileges needed to serve a model as a service on a pool.
Checkpoint 5 of 5· Check yourself
An ML engineer's job fails to start on an existing compute pool. They already have USAGE on the database, the schema and a stage. Which grant is the minimal fix?
Running ML Jobs in an existing environment needs USAGE on the pool and CREATE SERVICE on the schema. CREATE COMPUTE POOL is only needed to create new pools.
“USAGE privilege on the compute pool to allow it to be used for ML workloads”Source: docs.snowflake.com
Sources3
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.Running GRANT SELECT ON ALL VIEWS once at setup lets consumers read feature views that producers create later.Why is that wrong?
ALL covers only objects that exist when the grant runs. The documented setup also grants on FUTURE dynamic tables, views and datasets, so new feature views are readable without another grant.
Covered in Feature Store producers and consumers
2.USAGE on a model is enough to serve it on SPCS or download its weights.Why is that wrong?
USAGE allows warehouse inference and the SHOW commands only. SPCS inference and access to model files need READ.
Covered in Model Registry privileges: OWNERSHIP, USAGE and READ
Sources
Every claim above is drawn from one of these pages, quoted as it was written on the date shown.
- 1.
“Feature store roles are most naturally configured using a role hierarchy.”
↩︎ Feature Store producers and consumers“CREATE DYNAMIC TABLE, CREATE TAG, and CREATE VIEW on the feature store schema.”
↩︎ Feature Store producers and consumers“GRANT SELECT, MONITOR ON FUTURE DYNAMIC TABLES IN SCHEMA IDENTIFIER($SCHEMA_FQN) TO ROLE IDENTIFIER($FS_ROLE_CONSUMER);”
↩︎ Exam trap 1“GRANT SELECT, REFERENCES ON FUTURE VIEWS IN SCHEMA IDENTIFIER($SCHEMA_FQN) TO ROLE IDENTIFIER($FS_ROLE_CONSUMER);”
↩︎ Prediction“A role with MANAGE GRANTS, CREATE ROLE, and CREATE SCHEMA ON DATABASE <DB> privileges is needed”
↩︎ Checkpoint - 2.https://docs.snowflake.com/en/developer-guide/snowflake-ml/model-registry/model-managementOfficial docs
“Model objects have three privileges: OWNERSHIP, USAGE, and READ.”
↩︎ Model Registry privileges: OWNERSHIP, USAGE and READ“Read-only access to the model, allowing warehouse inference (prediction)”
↩︎ Model Registry privileges: OWNERSHIP, USAGE and READ“Because machine learning models are first-class objects in Snowflake, you can use all standard Snowflake governance capabilities with them”
↩︎ Key concept“Roles with only USAGE cannot access the model code, weights, or other artifacts.”
↩︎ Exam trap 2“Read-only access to the model, allowing SPCS inference (prediction), model files, metadata”
↩︎ Checkpoint - 3.https://docs.snowflake.com/en/developer-guide/snowflake-ml/ml-jobs/access-control-requirementsOfficial docs
“CREATE COMPUTE POOL privilege on the account: Required to create new compute pools.”
↩︎ Compute pool privileges for ML workloads“Users need appropriate privileges for any data tables, warehouses, or other resources their ML workloads will access”
↩︎ Compute pool privileges for ML workloads“USAGE privilege on the compute pool to allow it to be used for ML workloads”
↩︎ Checkpoint