Role-Based Access Control (RBAC)

Role-Based Access Control is the primary security model in Snowflake. Every action a user performs — reading a table, running a query, creating a schema — is governed by privileges granted to roles, which are then assigned to users. Understanding RBAC thoroughly is essential for the COF-C02 exam.

How RBAC Works in Snowflake

The core formula is simple:

GRANT privilege ON object TO role

A user activates a role in their session, and that role determines what the user can do. If the role does not have the required privilege on the required object, the action is denied — even if the user is an ACCOUNTADMIN in another context.

RBAC Hierarchy: Users, Roles, Privileges, and Objects

Diagram showing the RBAC chain: Users are assigned Roles. Roles hold Privileges. Privileges are granted ON Securable Objects (account, database, schema, table, warehouse). Role inheritance flows upward — a parent role inherits all privileges of its child roles. The ACCOUNTADMIN role sits at the top, inheriting from SYSADMIN and SECURITYADMIN. SYSADMIN inherits from any custom roles beneath it.

Securable Objects

A securable object is any object in Snowflake on which privileges can be granted. They are organised into a hierarchy:

Level	Examples
Account	Account-level settings, warehouses, integrations
Database	Databases
Schema	Schemas within a database
Table / View	Tables, views, materialised views
Stage / Pipe	Named stages, Snowpipe definitions
Stream / Task	Change tracking streams, scheduled tasks
Warehouse	Virtual warehouses

🎯Exam Tip — Object Hierarchy

Privileges are not inherited downward through the object hierarchy. Granting USAGE on a database does not automatically grant USAGE on its schemas, nor SELECT on its tables. You must grant privileges at each level separately.

System-Defined Roles

Snowflake provisions five system-defined roles automatically:

📖

Key Terms — System-Defined Roles

ACC

ACCOUNTADMIN

Top-level role combining SYSADMIN and SECURITYADMIN. Has all privileges. Should be used sparingly and always with MFA. Owns account-level settings.

SEC

SECURITYADMIN

Manages security objects: users, roles, network policies, and grants. Can GRANT/REVOKE any privilege in the account. Reports to ACCOUNTADMIN.

SYS

SYSADMIN

Creates and manages warehouses, databases, and other objects. Custom roles should be granted to SYSADMIN so SYSADMIN inherits their object ownership.

USE

USERADMIN

A sub-role of SECURITYADMIN. Can create users and roles only. Does not have GRANT privileges on all objects.

PUB

PUBLIC

Automatically granted to every user and role. Represents the minimum level of access. Can be granted privileges for objects accessible to all users.

⚠️ACCOUNTADMIN Best Practice

Snowflake strongly recommends assigning at least two users to ACCOUNTADMIN in case one account is locked out. Day-to-day administration should use SYSADMIN or custom roles, not ACCOUNTADMIN.

Privileges on Databases

To access any object in a database, a role must first have USAGE on the database itself.

Privilege	What It Allows
USAGE	Access the database; required before any lower-level access
CREATE SCHEMA	Create new schemas within the database
MODIFY	Alter the database properties
MONITOR	View database-level usage and metadata
OWNERSHIP	Full control; only one role may own an object at a time

Database Privilege Examples

1-- Grant USAGE so a role can access the database
2GRANT USAGE ON DATABASE sales_db TO ROLE analyst_role;
3
4-- Grant the ability to create schemas in the database
5GRANT CREATE SCHEMA ON DATABASE sales_db TO ROLE developer_role;
6
7-- Grant full ownership of the database to a role
8GRANT OWNERSHIP ON DATABASE sales_db TO ROLE db_owner_role REVOKE CURRENT GRANTS;
9
10-- Show all privileges granted ON a database
11SHOW GRANTS ON DATABASE sales_db;

Privileges on Schemas

After gaining USAGE on a database, a role needs USAGE on each schema it accesses.

Privilege	What It Allows
USAGE	Access the schema and its objects (required)
CREATE TABLE	Create tables in the schema
CREATE VIEW	Create views
CREATE STAGE	Create named stages for data loading
CREATE PIPE	Create Snowpipe objects
CREATE STREAM	Create change-data-capture streams
CREATE TASK	Create scheduled tasks
MODIFY	Alter schema properties
OWNERSHIP	Full control of the schema

Schema Privilege Examples

1-- Grant USAGE on schema so role can see its contents
2GRANT USAGE ON SCHEMA sales_db.public TO ROLE analyst_role;
3
4-- Grant CREATE TABLE so role can build tables in the schema
5GRANT CREATE TABLE ON SCHEMA sales_db.public TO ROLE developer_role;
6
7-- Grant multiple create privileges at once
8GRANT CREATE VIEW, CREATE STAGE, CREATE PIPE
9ON SCHEMA sales_db.public
10TO ROLE developer_role;
11
12-- Bulk grant on all existing tables in schema
13GRANT SELECT ON ALL TABLES IN SCHEMA sales_db.public TO ROLE analyst_role;
14
15-- Show privileges on a schema
16SHOW GRANTS ON SCHEMA sales_db.public;

Privileges on Tables and Views

Privilege	What It Allows
SELECT	Read rows from the table or view
INSERT	Add new rows
UPDATE	Modify existing rows
DELETE	Remove rows
TRUNCATE	Remove all rows (faster than DELETE, not logged per-row)
REFERENCES	Create foreign key references to the table
OWNERSHIP	Full control; required to DROP the table

ℹ️TRUNCATE vs DELETE

TRUNCATE requires the TRUNCATE privilege, not DELETE. A role with only DELETE cannot truncate a table. This distinction appears regularly in exam questions.

RBAC

QUESTION

Which privilege is required to read rows from a Snowflake table?

Click to reveal answer

ANSWER

SELECT. The role must also have USAGE on both the containing database and schema before SELECT on the table is meaningful.

Click to see question

RBAC

QUESTION

What is the minimum set of privileges required for a role to query a table called sales_db.public.orders?

Click to reveal answer

ANSWER

1) USAGE ON DATABASE sales_db 2) USAGE ON SCHEMA sales_db.public 3) SELECT ON TABLE sales_db.public.orders

Click to see question

Privileges on Warehouses

Warehouses are compute resources. Their privileges are separate from data object privileges.

Privilege	What It Allows
USAGE	Execute queries using this warehouse
OPERATE	Start, suspend, and abort queries on the warehouse
MONITOR	View warehouse usage statistics and query history
MODIFY	Change warehouse properties (size, auto-suspend settings)
OWNERSHIP	Full control of the warehouse

Warehouse Privilege Examples

1-- Allow analyst to run queries on the warehouse
2GRANT USAGE ON WAREHOUSE analytics_wh TO ROLE analyst_role;
3
4-- Allow an ops role to suspend or resize the warehouse
5GRANT OPERATE ON WAREHOUSE analytics_wh TO ROLE ops_role;
6GRANT MODIFY ON WAREHOUSE analytics_wh TO ROLE ops_role;
7
8-- Allow a monitoring role to see query history
9GRANT MONITOR ON WAREHOUSE analytics_wh TO ROLE monitor_role;
10
11-- Check what privileges a role holds on the warehouse
12SHOW GRANTS TO ROLE analyst_role;

RBAC

A data engineer needs to resize a warehouse from X-Small to Medium and also suspend it between jobs. Which warehouse privileges are required?

OWNERSHIP Privilege

Ownership is a special privilege in Snowflake:

Only one role can own an object at any time.
The owning role has full control over the object, including the ability to DROP it.
Ownership is automatically assigned to the role that created the object (the active role in the session at creation time).
Ownership can be transferred using GRANT OWNERSHIP.

Transferring Object Ownership

1-- Transfer ownership of a table to a new role
2-- REVOKE CURRENT GRANTS removes all existing privilege grants on the object
3GRANT OWNERSHIP ON TABLE sales_db.public.orders
4TO ROLE new_owner_role
5REVOKE CURRENT GRANTS;
6
7-- Transfer ownership WITHOUT removing existing grants (COPY CURRENT GRANTS)
8GRANT OWNERSHIP ON TABLE sales_db.public.orders
9TO ROLE new_owner_role
10COPY CURRENT GRANTS;
11
12-- Transfer ownership of an entire schema
13GRANT OWNERSHIP ON SCHEMA sales_db.public
14TO ROLE new_owner_role
15REVOKE CURRENT GRANTS;
16
17-- Transfer ownership of a database
18GRANT OWNERSHIP ON DATABASE sales_db
19TO ROLE new_owner_role
20REVOKE CURRENT GRANTS;

RBAC

QUESTION

How many roles can own a single Snowflake object at one time?

Click to reveal answer

ANSWER

Exactly ONE role can own a Snowflake object at any given time. Ownership can be transferred but not shared.

Click to see question

🎯REVOKE CURRENT GRANTS vs COPY CURRENT GRANTS

When transferring ownership:

REVOKE CURRENT GRANTS — removes all existing privilege grants on the object from other roles. The new owner starts fresh.
COPY CURRENT GRANTS — preserves all existing privilege grants. Other roles retain their previously granted privileges.

The exam may ask which option is used when you want a clean transfer with no inherited grants.

Discretionary Access Control (DAC)

Snowflake combines RBAC with Discretionary Access Control (DAC):

In RBAC, access is managed centrally by an administrator.
In DAC, object owners can grant access to their own objects to other roles — without requiring a central admin to do so.

This means a role that owns a table can run:

GRANT SELECT ON TABLE my_table TO ROLE other_role;

…even if that role is not SECURITYADMIN or ACCOUNTADMIN.

DAC + RBAC Combined Model

Diagram showing Snowflake's hybrid access control model. On the left side, a central SECURITYADMIN manages roles and their hierarchy. On the right side, individual object owners (any role with OWNERSHIP privilege) can grant/revoke access on their own objects directly to other roles. Both paths result in privilege grants tracked in the same access control system. This combination allows both centralised governance and delegated object-level access management.

Snowflake DAC and RBAC combined security model diagram

GRANT WITH GRANT OPTION

By default, when role A grants SELECT to role B, role B cannot further grant that privilege to role C. The WITH GRANT OPTION changes this:

GRANT WITH GRANT OPTION

1-- Grant SELECT and allow the grantee to pass it on
2GRANT SELECT ON TABLE sales_db.public.orders
3TO ROLE analyst_role
4WITH GRANT OPTION;
5
6-- analyst_role can now grant SELECT to other roles:
7-- (Run while using analyst_role)
8GRANT SELECT ON TABLE sales_db.public.orders
9TO ROLE junior_analyst_role;
10
11-- Revoke the grant option without revoking the privilege itself
12-- (must revoke and re-grant without WITH GRANT OPTION)
13REVOKE GRANT OPTION FOR SELECT ON TABLE sales_db.public.orders
14FROM ROLE analyst_role;

RBAC

Role A has been granted SELECT ON TABLE orders WITH GRANT OPTION. Role A then grants SELECT to Role B. If Role A's grant option is revoked, what happens to Role B's SELECT privilege?

Role Hierarchy and Privilege Inheritance

Roles can be organised into a hierarchy. A parent role inherits all privileges of its child roles.

Role Hierarchy — GRANT ROLE

1-- Create custom roles
2CREATE ROLE junior_analyst;
3CREATE ROLE senior_analyst;
4CREATE ROLE data_team_lead;
5
6-- Build the hierarchy: senior_analyst inherits junior_analyst's privileges
7GRANT ROLE junior_analyst TO ROLE senior_analyst;
8
9-- data_team_lead inherits all privileges of senior_analyst (and thus junior_analyst)
10GRANT ROLE senior_analyst TO ROLE data_team_lead;
11
12-- Assign a role to a user
13GRANT ROLE junior_analyst TO USER alice;
14GRANT ROLE data_team_lead TO USER bob;
15
16-- Best practice: grant custom roles up to SYSADMIN
17GRANT ROLE data_team_lead TO ROLE sysadmin;

Role Inheritance Chain Example

Visual diagram showing a four-level role hierarchy. At the bottom: junior_analyst role with SELECT on raw tables. Above it: senior_analyst role with SELECT on curated views, which also inherits junior_analyst's SELECT on raw tables. Above that: data_team_lead with CREATE TABLE privilege, inheriting all privileges from both lower roles. At the top: SYSADMIN, which has data_team_lead granted to it, giving SYSADMIN visibility over all objects managed by the hierarchy. Arrows point upward showing the direction of privilege inheritance.

Snowflake role hierarchy inheritance diagram

REVOKE — Removing Privileges

REVOKE Examples with CASCADE and RESTRICT

1-- Basic revoke
2REVOKE SELECT ON TABLE sales_db.public.orders FROM ROLE analyst_role;
3
4-- Revoke a schema privilege
5REVOKE CREATE TABLE ON SCHEMA sales_db.public FROM ROLE developer_role;
6
7-- Revoke with CASCADE: also revokes downstream grants made by this role
8REVOKE SELECT ON TABLE sales_db.public.orders
9FROM ROLE analyst_role CASCADE;
10
11-- Revoke with RESTRICT: fails if the role has granted this privilege to others
12-- (prevents accidental breakage of downstream access)
13REVOKE SELECT ON TABLE sales_db.public.orders
14FROM ROLE analyst_role RESTRICT;
15
16-- Revoke a role assignment from a user
17REVOKE ROLE analyst_role FROM USER alice;

⚠️CASCADE vs RESTRICT in REVOKE

CASCADE: The revoke propagates downward — any grants that the target role made using this privilege are also revoked.
RESTRICT: The revoke fails with an error if the target role has granted this privilege to any other roles. This is the safer option to avoid unknowingly breaking access.

The exam often presents a scenario where a downstream role loses access unexpectedly — this is caused by a CASCADE revoke up the chain.

FUTURE GRANTS

Future grants automatically apply a privilege to objects created in the future within a schema or database, eliminating the need to grant privileges every time a new object is created.

FUTURE GRANTS — Auto-grant on New Objects

1-- Automatically grant SELECT on any future tables created in this schema
2GRANT SELECT ON FUTURE TABLES IN SCHEMA sales_db.public
3TO ROLE analyst_role;
4
5-- Automatically grant SELECT on future views
6GRANT SELECT ON FUTURE VIEWS IN SCHEMA sales_db.public
7TO ROLE analyst_role;
8
9-- Future grants at the database level (applies to all schemas)
10GRANT SELECT ON FUTURE TABLES IN DATABASE sales_db
11TO ROLE analyst_role;
12
13-- Grant future pipe usage
14GRANT USAGE ON FUTURE STAGES IN SCHEMA sales_db.public
15TO ROLE loader_role;
16
17-- Show future grants configured on a schema
18SHOW FUTURE GRANTS IN SCHEMA sales_db.public;
19
20-- Show future grants configured on a database
21SHOW FUTURE GRANTS IN DATABASE sales_db;

ℹ️Future Grants vs Bulk Grants

Future grants apply to objects created after the grant is set up — they do not backfill existing objects.

To cover existing objects, use:

GRANT SELECT ON ALL TABLES IN SCHEMA sales_db.public TO ROLE analyst_role;

You often need both: one for existing objects and one for future objects.

RBAC

QUESTION

What is the purpose of FUTURE GRANTS in Snowflake?

Click to reveal answer

ANSWER

FUTURE GRANTS automatically apply a specified privilege to all objects of a given type created in a schema or database after the grant is configured. They prevent access gaps when new objects are added.

Click to see question

Bulk Grants with GRANT ALL

Bulk Privilege Grants

1-- Grant ALL privileges on a specific table
2GRANT ALL PRIVILEGES ON TABLE sales_db.public.orders TO ROLE power_user;
3
4-- Grant SELECT on every existing table in a schema
5GRANT SELECT ON ALL TABLES IN SCHEMA sales_db.public TO ROLE analyst_role;
6
7-- Grant SELECT on all existing views in a schema
8GRANT SELECT ON ALL VIEWS IN SCHEMA sales_db.public TO ROLE analyst_role;
9
10-- Grant USAGE on all existing schemas in a database
11GRANT USAGE ON ALL SCHEMAS IN DATABASE sales_db TO ROLE analyst_role;
12
13-- Combine bulk (existing) + future grants for complete coverage
14GRANT SELECT ON ALL TABLES IN SCHEMA sales_db.public TO ROLE analyst_role;
15GRANT SELECT ON FUTURE TABLES IN SCHEMA sales_db.public TO ROLE analyst_role;

SHOW GRANTS Commands

Inspecting Grants with SHOW GRANTS

1-- Show all privileges granted TO a specific role
2SHOW GRANTS TO ROLE analyst_role;
3
4-- Show which roles and users have been granted a specific role
5SHOW GRANTS OF ROLE analyst_role;
6
7-- Show all privileges granted ON a specific table
8SHOW GRANTS ON TABLE sales_db.public.orders;
9
10-- Show all privileges granted ON a database
11SHOW GRANTS ON DATABASE sales_db;
12
13-- Show all privileges granted ON a schema
14SHOW GRANTS ON SCHEMA sales_db.public;
15
16-- Show all privileges granted ON a warehouse
17SHOW GRANTS ON WAREHOUSE analytics_wh;
18
19-- Show future grants in a schema
20SHOW FUTURE GRANTS IN SCHEMA sales_db.public;

Comparing RBAC and DAC

RBAC vs DAC in Snowflake

Feature

RBAC (Role-Based)

DAC (Discretionary)

Who controls access?

✓Central administrator (SECURITYADMIN)

Object owner (any role with OWNERSHIP)

Flexibility

Lower — requires admin intervention for each grant

✓Higher — owner can delegate independently

Governance

✓Stronger — all grants managed centrally

Weaker — distributed, harder to audit

Implementation in Snowflake

System-defined roles (SYSADMIN, SECURITYADMIN)

Any role with OWNERSHIP can grant its object's privileges

Audit trail

✓Centralised GRANT history

Object-level GRANT history

Recommended for

Enterprise governance and compliance

Agile teams with delegated data ownership

Setting Up RBAC — Step-by-Step

Setting Up a Full RBAC Structure for an Analytics Team

Create custom roles

Define functional roles that map to job functions in your organisation. Avoid giving users ACCOUNTADMIN or SYSADMIN for day-to-day work.

SQL

CREATE ROLE junior_analyst;
CREATE ROLE senior_analyst;
CREATE ROLE data_engineer;

💡Role names should reflect the job function, not the individual user.

Build the role hierarchy

Grant child roles to parent roles so privileges are inherited upward. Always grant top-level custom roles to SYSADMIN.

SQL

GRANT ROLE junior_analyst TO ROLE senior_analyst;
GRANT ROLE senior_analyst TO ROLE data_engineer;
GRANT ROLE data_engineer TO ROLE sysadmin;

💡Granting custom roles to SYSADMIN ensures SYSADMIN can manage all objects created by those roles.

Create warehouse and grant access

Create the compute resource and grant the USAGE privilege so roles can run queries.

SQL

CREATE WAREHOUSE analytics_wh
WAREHOUSE_SIZE = 'X-SMALL'
AUTO_SUSPEND = 300
AUTO_RESUME = TRUE;

GRANT USAGE ON WAREHOUSE analytics_wh TO ROLE junior_analyst;
GRANT USAGE ON WAREHOUSE analytics_wh TO ROLE senior_analyst;
GRANT OPERATE ON WAREHOUSE analytics_wh TO ROLE data_engineer;

💡Data engineers often need OPERATE so they can suspend the warehouse after batch loads.

Grant database and schema access

Grant USAGE at the database and schema level. Without these, lower-level object grants are ineffective.

SQL

GRANT USAGE ON DATABASE sales_db TO ROLE junior_analyst;
GRANT USAGE ON DATABASE sales_db TO ROLE senior_analyst;
GRANT USAGE ON DATABASE sales_db TO ROLE data_engineer;

GRANT USAGE ON SCHEMA sales_db.public TO ROLE junior_analyst;
GRANT USAGE ON SCHEMA sales_db.public TO ROLE senior_analyst;
GRANT CREATE TABLE, CREATE VIEW ON SCHEMA sales_db.public TO ROLE data_engineer;

💡Remember: USAGE on database + USAGE on schema is required before any object-level privilege can be used.

Grant table-level privileges with future grants

Grant both existing and future table access so new tables are covered automatically.

SQL

-- Existing tables
GRANT SELECT ON ALL TABLES IN SCHEMA sales_db.public TO ROLE junior_analyst;
GRANT SELECT ON ALL TABLES IN SCHEMA sales_db.public TO ROLE senior_analyst;

-- Future tables
GRANT SELECT ON FUTURE TABLES IN SCHEMA sales_db.public TO ROLE junior_analyst;
GRANT SELECT ON FUTURE TABLES IN SCHEMA sales_db.public TO ROLE senior_analyst;

💡Always pair ALL TABLES (existing) with FUTURE TABLES (new) to prevent access gaps.

Assign roles to users

Grant roles to individual users. Users can hold multiple roles and switch between them within a session.

SQL

GRANT ROLE junior_analyst TO USER alice;
GRANT ROLE senior_analyst TO USER bob;
GRANT ROLE data_engineer TO USER carol;

-- A user can also be granted multiple roles
GRANT ROLE junior_analyst TO USER dave;
GRANT ROLE senior_analyst TO USER dave;

💡Set a default role for each user with ALTER USER so they start in the correct context automatically.

Least Privilege Principle

🎯Least Privilege — A Core Exam Theme

The principle of least privilege means granting only the minimum privileges necessary for a role to perform its function. In Snowflake, this manifests as:

Never granting ACCOUNTADMIN for day-to-day work.
Using custom roles rather than system-defined roles for functional access.
Separating functional roles (e.g., analyst, loader) from access roles (e.g., db_read_only, schema_write).
Preferring USAGE over OWNERSHIP wherever possible.
Using FUTURE GRANTS to avoid granting overly broad blanket access.

RBAC

QUESTION

What is the difference between a functional role and an access role in Snowflake RBAC best practice?

Click to reveal answer

ANSWER

An ACCESS ROLE is granted privileges on specific objects (e.g., SELECT on a table). A FUNCTIONAL ROLE maps to a job function (e.g., analyst) and is granted one or more access roles. This separation makes it easy to adjust object-level privileges without reassigning users to different functional roles.

Click to see question

Quiz — Privilege Inheritance

RBAC

Role C is a child of Role B, which is a child of Role A. Role C has SELECT on table T. A user is assigned Role A. Can the user query table T?

RBAC Cheat Sheet

📋

Quick Reference

RBAC Quick Reference — COF-C02

🗄️

Database Privileges

USAGE

Required to access database at all— Must grant before schema access

CREATE SCHEMA

Create new schemas inside the database

MODIFY

Alter database properties

OWNERSHIP

Full control; only one role at a time— Transfer with GRANT OWNERSHIP ... REVOKE CURRENT GRANTS

📁

Schema Privileges

USAGE

Required to access schema objects— Must have DB USAGE too

CREATE TABLE/VIEW/STAGE/PIPE

Create objects of respective type— Each is a separate privilege

CREATE STREAM / TASK

Create CDC streams and scheduled tasks

OWNERSHIP

Full schema control

📊

Table Privileges

SELECT

Read rows— Most commonly required

INSERT / UPDATE / DELETE

Write operations

TRUNCATE

Remove all rows (not DELETE)— Distinct from DELETE privilege

REFERENCES

Create FK references to this table

OWNERSHIP

Full control including DROP

⚙️

Warehouse Privileges

USAGE

Run queries on the warehouse— Most roles need this

OPERATE

Start, suspend, abort queries

MODIFY

Change size and settings

MONITOR

View query history and usage stats

OWNERSHIP

Full control

🔑

Key GRANT Commands

GRANT privilege ON object TO role

Standard privilege grant

WITH GRANT OPTION

Allows grantee to re-grant privilege

GRANT ROLE child TO ROLE parent

Builds role hierarchy— Parent inherits child's privileges

GRANT SELECT ON ALL TABLES IN SCHEMA

Bulk grant on existing objects

GRANT SELECT ON FUTURE TABLES IN SCHEMA

Auto-grant on new objects— Does not backfill existing

GRANT OWNERSHIP ... REVOKE CURRENT GRANTS

Transfer ownership, clear old grants

🔍

SHOW GRANTS Commands

SHOW GRANTS TO ROLE r

What privileges does role r have?

SHOW GRANTS OF ROLE r

Who (users/roles) holds role r?

SHOW GRANTS ON TABLE t

What privileges are on table t?

SHOW FUTURE GRANTS IN SCHEMA s

What future grants are configured?

Summary

Snowflake’s RBAC model combines centralised role management with discretionary object-level control. The key principles to remember for the COF-C02 exam are:

Access requires privileges at every level — database, schema, and object.
USAGE is the gateway — without USAGE on a database and schema, object-level privileges are useless.
OWNERSHIP is exclusive — only one role owns an object; transfer with GRANT OWNERSHIP ... REVOKE CURRENT GRANTS.
Privilege inheritance flows upward — parent roles inherit all privileges of child roles.
FUTURE GRANTS automate privilege assignment for new objects but do not backfill existing ones.
DAC + RBAC: Object owners can grant access without central admin involvement.
Least privilege is the guiding principle — always grant the minimum required.

Reinforce what you just read

Study the All flashcards with spaced repetition to lock it in.

Study flashcards →