Account Management and Security
Role-based access control
Privileges are granted to roles, roles to roles, and roles to users. The system roles - ACCOUNTADMIN, SECURITYADMIN, SYSADMIN, USERADMIN - should form a disciplined hierarchy: SYSADMIN owns warehouses and databases, SECURITYADMIN manages grants, USERADMIN manages users and roles, and ACCOUNTADMIN is break-glass. Role inheritance is transitive, but a role cannot be granted to itself or create a cycle. Ownership transfers and future grants are common exam topics: future grants apply only to objects created after the grant and only at the level specified (schema or database).
Authentication and network controls
Understand SSO via SAML, SCIM provisioning, MFA, key-pair authentication for service users, OAuth, and network policies (account-level and user-level; user-level overrides account-level). Tri-Secret Secure combines a Snowflake-managed key with a customer-managed key in a cloud KMS.
Traps
- A privilege on a database does not imply privileges on schemas inside it; USAGE must be granted at each level for navigation.
- Database roles live inside a database and are separate from account roles; they can be granted to account roles but not vice versa.
- Masking and row access policies are schema-level objects with their own ownership; only the policy owner (or a role with global MANAGE MASKING POLICY) sees unmasked data by default.
- Custom roles are not automatically granted to ACCOUNTADMIN.
Worked example: an analyst must query a table but not see PII - grant USAGE on database, schema, and warehouse plus SELECT on the table, attach a masking policy, and do not grant the policy-owner role.