Bird
Raised Fist0
Snowflakecloud~5 mins

Granting and revoking privileges in Snowflake - Commands & Configuration

Choose your learning style10 modes available
Introduction
Sometimes you want to let someone use parts of your data or tools, and other times you want to take that permission away. Granting and revoking privileges in Snowflake lets you control who can do what with your data and resources.
When you want to allow a new team member to read data from a specific database.
When you need to let an analyst create tables in a shared schema.
When you want to stop a user from modifying data after their project ends.
When you want to give a role permission to run queries on a warehouse.
When you need to remove access from a user who no longer needs it.
Commands
This command gives the role named 'analyst_role' permission to read data from the database 'my_database'.
Terminal
GRANT SELECT ON DATABASE my_database TO ROLE analyst_role;
Expected OutputExpected
SQL executed successfully.
This command shows all the permissions currently given to the 'analyst_role' so you can verify the grant.
Terminal
SHOW GRANTS TO ROLE analyst_role;
Expected OutputExpected
created_on | privilege | granted_on | name | granted_to | grantee_name ---------------------|-----------|------------|-------------|------------|-------------- 2024-06-01 12:00:00 | SELECT | DATABASE | MY_DATABASE | ROLE | ANALYST_ROLE
This command removes the permission to read data from 'my_database' for the role 'analyst_role'.
Terminal
REVOKE SELECT ON DATABASE my_database FROM ROLE analyst_role;
Expected OutputExpected
SQL executed successfully.
This command checks again to confirm that the 'SELECT' permission was removed from 'analyst_role'.
Terminal
SHOW GRANTS TO ROLE analyst_role;
Expected OutputExpected
No grants found.
Key Concept

If you remember nothing else from this pattern, remember: granting gives permission to use resources, and revoking takes it away.

Common Mistakes
Trying to grant privileges to a user instead of a role.
Snowflake manages permissions through roles, not directly to users, so the grant will fail or not work as expected.
Always grant privileges to roles, then assign roles to users.
Revoking privileges without checking current grants.
You might revoke a privilege that was never granted or miss revoking inherited privileges, causing confusion.
Use SHOW GRANTS to verify current permissions before revoking.
Granting privileges on the wrong object level (e.g., table instead of database).
Permissions might not apply as intended, leading to unexpected access or denial.
Be clear about the object you want to grant or revoke privileges on and use the correct syntax.
Summary
Use GRANT to give roles permission to access or modify Snowflake resources.
Use SHOW GRANTS to check what permissions a role currently has.
Use REVOKE to remove permissions from roles when access is no longer needed.

Practice

(1/5)
1. What is the main purpose of granting privileges in Snowflake?
easy
A. To allow roles to perform specific actions on database objects
B. To create new users in the system
C. To delete roles from the account
D. To backup data automatically

Solution

  1. Step 1: Understand the role of privileges

    Privileges control what actions roles can perform on database objects like tables or views.
  2. Step 2: Identify the purpose of granting privileges

    Granting privileges gives roles permission to do specific tasks, such as SELECT or INSERT on tables.
  3. Final Answer:

    To allow roles to perform specific actions on database objects -> Option A
  4. Quick Check:

    Grant privileges = Allow role actions [OK]
Hint: Privileges let roles do tasks on objects, not users directly [OK]
Common Mistakes:
  • Confusing privileges with user creation
  • Thinking privileges delete roles
  • Assuming privileges backup data
2. Which of the following is the correct syntax to grant SELECT privilege on a table named sales_data to a role named analyst_role?
easy
A. GRANT SELECT TO ROLE analyst_role ON sales_data;
B. GRANT ROLE analyst_role TO SELECT ON TABLE sales_data;
C. GRANT SELECT ON ROLE analyst_role TO TABLE sales_data;
D. GRANT SELECT ON TABLE sales_data TO ROLE analyst_role;

Solution

  1. Step 1: Recall the correct GRANT syntax

    The syntax is: GRANT <privilege> ON <object_type> <object_name> TO ROLE <role_name>;
  2. Step 2: Match the syntax to the options

    GRANT SELECT ON TABLE sales_data TO ROLE analyst_role; matches the correct order and keywords exactly.
  3. Final Answer:

    GRANT SELECT ON TABLE sales_data TO ROLE analyst_role; -> Option D
  4. Quick Check:

    GRANT privilege ON object TO ROLE [OK]
Hint: Remember: GRANT privilege ON object TO ROLE role_name [OK]
Common Mistakes:
  • Mixing order of keywords
  • Placing role before privilege
  • Using TO TABLE instead of TO ROLE
3. Given the following commands executed in order:
GRANT SELECT ON TABLE customers TO ROLE sales_role;
REVOKE SELECT ON TABLE customers FROM ROLE sales_role;
GRANT INSERT ON TABLE customers TO ROLE sales_role;

What privileges does sales_role have on the customers table after these commands?
medium
A. Only SELECT
B. Only INSERT
C. SELECT and INSERT
D. No privileges

Solution

  1. Step 1: Analyze the first GRANT

    The role sales_role is granted SELECT privilege on customers.
  2. Step 2: Analyze the REVOKE

    The SELECT privilege is revoked from sales_role, removing that permission.
  3. Step 3: Analyze the second GRANT

    The role is granted INSERT privilege on customers.
  4. Final Answer:

    Only INSERT -> Option B
  5. Quick Check:

    Revoked SELECT, granted INSERT = INSERT only [OK]
Hint: Revoke removes privilege; later grants add new ones [OK]
Common Mistakes:
  • Assuming revoked privileges remain
  • Thinking grants accumulate without revokes
  • Confusing privilege types
4. You run the command:
REVOKE ALL PRIVILEGES ON DATABASE sales_db FROM ROLE marketing_role;

But the privileges are not removed. What is the most likely reason?
medium
A. The role marketing_role does not have any privileges on sales_db
B. The syntax REVOKE ALL PRIVILEGES is invalid in Snowflake
C. You must revoke privileges from users, not roles
D. The database sales_db does not exist

Solution

  1. Step 1: Check if the role has privileges

    If the role has no privileges on the database, revoking does nothing.
  2. Step 2: Verify syntax and object existence

    REVOKE ALL PRIVILEGES is valid syntax, and revoking is done on roles, not users. Assume sales_db exists.
  3. Final Answer:

    The role marketing_role does not have any privileges on sales_db -> Option A
  4. Quick Check:

    Revoking non-existent privileges has no effect [OK]
Hint: Check if role actually has privileges before revoking [OK]
Common Mistakes:
  • Assuming syntax error with REVOKE ALL PRIVILEGES
  • Trying to revoke from users directly
  • Ignoring role privilege state
5. You want to allow a role data_scientist to both read and write data in tables of the analytics schema but prevent it from dropping any tables. Which set of commands correctly grants and restricts privileges?
hard
A. GRANT SELECT, INSERT, UPDATE ON ALL TABLES IN SCHEMA analytics TO ROLE data_scientist; GRANT DROP ON SCHEMA analytics TO ROLE data_scientist;
B. GRANT ALL PRIVILEGES ON SCHEMA analytics TO ROLE data_scientist; REVOKE DROP ON SCHEMA analytics FROM ROLE data_scientist;
C. GRANT SELECT, INSERT, UPDATE ON ALL TABLES IN SCHEMA analytics TO ROLE data_scientist; REVOKE DROP ON SCHEMA analytics FROM ROLE data_scientist;
D. GRANT SELECT, INSERT, UPDATE ON ALL TABLES IN SCHEMA analytics TO ROLE data_scientist;

Solution

  1. Step 1: Grant read and write privileges

    Grant SELECT, INSERT, and UPDATE to allow reading and writing data.
  2. Step 2: Revoke DROP privilege

    Explicitly revoke DROP to prevent deleting tables.
  3. Step 3: Evaluate other options

    GRANT ALL PRIVILEGES ON SCHEMA analytics TO ROLE data_scientist; REVOKE DROP ON SCHEMA analytics FROM ROLE data_scientist; grants ALL privileges then revokes DROP, which is valid but less precise. GRANT SELECT, INSERT, UPDATE ON ALL TABLES IN SCHEMA analytics TO ROLE data_scientist; does not revoke DROP, so drop is allowed. GRANT SELECT, INSERT, UPDATE ON ALL TABLES IN SCHEMA analytics TO ROLE data_scientist; GRANT DROP ON SCHEMA analytics TO ROLE data_scientist; grants DROP, which is opposite of requirement.
  4. Final Answer:

    GRANT SELECT, INSERT, UPDATE ON ALL TABLES IN SCHEMA analytics TO ROLE data_scientist; REVOKE DROP ON SCHEMA analytics FROM ROLE data_scientist; -> Option C
  5. Quick Check:

    Grant needed privileges, revoke unwanted ones [OK]
Hint: Grant needed privileges, then revoke unwanted ones explicitly [OK]
Common Mistakes:
  • Granting ALL privileges without revoking DROP
  • Not revoking DROP privilege
  • Granting DROP privilege by mistake
Recommended

Ready to prove it?

Pass the test and this pattern moves unknown strong while earning +1 Grip toward your certificate.

10 questions~5 mineasy hard