Creating custom roles in Snowflake - Performance & Efficiency
When creating custom roles in Snowflake, it's important to understand how the time to create roles grows as you add more roles.
We want to know how the number of operations changes when creating many roles.
Analyze the time complexity of the following operation sequence.
-- Create multiple custom roles
BEGIN
FOR i IN 1..n LOOP
EXECUTE IMMEDIATE 'CREATE ROLE role_' || i;
END LOOP;
END;
This sequence creates n custom roles one by one using a loop.
Identify the API calls, resource provisioning, data transfers that repeat.
- Primary operation: Executing the 'CREATE ROLE' command for each role.
- How many times: Exactly n times, once per role.
Each new role requires one separate create command, so the total operations increase directly with the number of roles.
| Input Size (n) | Approx. Api Calls/Operations |
|---|---|
| 10 | 10 |
| 100 | 100 |
| 1000 | 1000 |
Pattern observation: The number of operations grows linearly as you add more roles.
Time Complexity: O(n)
This means the time to create roles grows directly in proportion to how many roles you create.
[X] Wrong: "Creating multiple roles happens all at once, so time stays the same no matter how many roles."
[OK] Correct: Each role creation is a separate command that takes time, so more roles mean more commands and more time.
Understanding how operations scale helps you design efficient role management and shows you can think about system behavior as it grows.
"What if we created roles in parallel instead of one by one? How would the time complexity change?"
Practice
Solution
Step 1: Understand role purpose
Custom roles in Snowflake are designed to manage what users can do by controlling permissions.Step 2: Identify correct function
Creating a role is not about storing data, creating users, or speeding queries, but about access control.Final Answer:
To control and manage user access permissions -> Option DQuick Check:
Role purpose = Access control [OK]
- Confusing roles with users
- Thinking roles store data
- Assuming roles speed up queries
data_analyst in Snowflake?Solution
Step 1: Recall Snowflake role creation syntax
The correct command to create a role isCREATE ROLE role_name;.Step 2: Match syntax with options
Only CREATE ROLE data_analyst; uses the correctCREATE ROLEsyntax.Final Answer:
CREATE ROLE data_analyst; -> Option AQuick Check:
CREATE ROLE = correct syntax [OK]
- Using NEW ROLE instead of CREATE ROLE
- Using MAKE or ADD which are invalid
- Missing semicolon at the end
CREATE ROLE analyst; GRANT USAGE ON DATABASE sales_db TO ROLE analyst; GRANT ROLE analyst TO USER alice;
What permission does user
alice have on sales_db?Solution
Step 1: Analyze role creation and grants
The roleanalystis created and given USAGE permission onsales_db.Step 2: Check role assignment to user
Useraliceis granted theanalystrole, so she inherits its permissions.Final Answer:
Only USAGE permission on sales_db -> Option BQuick Check:
Role grants USAGE, user inherits USAGE [OK]
- Assuming no permissions without direct grant
- Confusing USAGE with SELECT permission
- Ignoring role inheritance
CREATE ROLE analyst
but get an error. What is the likely cause?
Solution
Step 1: Check command syntax
Snowflake commands require a semicolon at the end to execute properly.Step 2: Evaluate other options
Role names like analyst are allowed, users are independent of roles, and CREATE ROLE is supported.Final Answer:
Missing semicolon at the end of the command -> Option CQuick Check:
Semicolon ends command [OK]
- Forgetting semicolon causes syntax error
- Thinking role names are restricted
- Believing users must exist first
report_viewer that can only read data from the reports schema in the analytics database. Which sequence of commands correctly achieves this?Solution
Step 1: Create the role
UseCREATE ROLE report_viewer;to make the role.Step 2: Grant USAGE on database and schema
Granting USAGE on the database and schema allows access to objects inside.Step 3: Grant SELECT on all tables in the schema
Grant SELECT on all tables to allow read access to data.Step 4: Evaluate options
CREATE ROLE report_viewer; GRANT USAGE ON DATABASE analytics TO ROLE report_viewer; GRANT USAGE ON SCHEMA analytics.reports TO ROLE report_viewer; GRANT SELECT ON ALL TABLES IN SCHEMA analytics.reports TO ROLE report_viewer; correctly grants USAGE and SELECT at proper levels. CREATE ROLE report_viewer; GRANT SELECT ON DATABASE analytics TO ROLE report_viewer; misses schema and USAGE grants. CREATE ROLE report_viewer; GRANT ALL ON SCHEMA analytics.reports TO ROLE report_viewer; grants ALL which is too broad. CREATE ROLE report_viewer; GRANT USAGE ON DATABASE analytics TO ROLE report_viewer; GRANT SELECT ON SCHEMA analytics.reports TO ROLE report_viewer; grants SELECT on schema which is invalid; SELECT must be on tables.Final Answer:
CREATE ROLE report_viewer; GRANT USAGE ON DATABASE analytics TO ROLE report_viewer; GRANT USAGE ON SCHEMA analytics.reports TO ROLE report_viewer; GRANT SELECT ON ALL TABLES IN SCHEMA analytics.reports TO ROLE report_viewer; -> Option AQuick Check:
Grant USAGE + SELECT on tables = read access [OK]
- Granting SELECT on schema instead of tables
- Missing USAGE grants on database or schema
- Granting ALL permissions instead of SELECT only
Ready to prove it?
Pass the test and this pattern moves unknown
