SnowPro Associate: Platform Question 130
Single answerRole typesA Snowflake account is being reorganized to improve security administration. The company wants one set of roles to be assigned directly to users based on job function, while a separate set of roles will hold privileges on warehouses, databases, schemas, and tables. The security team also wants to simplify future privilege changes by updating access in one place rather than editing many user assignments. Which approach best meets these requirements?
- A
Create database roles for users and grant account roles to objects, because database roles can span the full account and simplify central administration.
- B
Create account roles for job functions and grant privileges directly to each user, because account roles cannot be granted to other roles.
- C
Create account roles for users' job functions and use database roles or account roles as access roles that hold object privileges, then grant those access roles to the functional account roles.
- D
Create instance roles for business functions and grant them database privileges, because instance roles are designed to manage warehouses and schemas across the account.
Show answer and explanation
Correct answer: C
Explanation
Snowflake supports different role types with different scopes and purposes. For SnowPro Associate, a key distinction is that account roles are account-wide and can be granted to users and to other account roles, making them appropriate for functional roles such as ANALYST or ETL_ENGINEER. Database roles are scoped to a single database and are useful for grouping privileges on database objects within that database; they can be granted to account roles. A common best-practice design is to separate functional roles from access roles: users receive functional account roles, while object privileges are grouped into access roles. This simplifies administration, supports least privilege, and reduces the need to update many user-role assignments when object access changes. Snowflake documentation on access control and role hierarchy describes using account roles for broad RBAC and database roles for database-specific privilege management.
- A. Incorrect.
Incorrect. Database roles are scoped to a single database and are intended to manage privileges on objects within that database. They are not assigned directly to users. Also, objects such as warehouses are account-level objects, so database roles cannot be the universal role type for all access across the account.
- B. Incorrect.
Incorrect. While account roles are commonly assigned to users based on job function, granting privileges directly to users is not the recommended model for scalable administration. In Snowflake, account roles can be granted to other account roles, enabling role hierarchies that simplify privilege management.
- C. Correct.
Correct. This matches Snowflake best practice: assign users to functional account roles, and place object privileges in access roles. Those access roles can be implemented as account roles for account-level access or as database roles for database-scoped access. Then grant the access roles to the functional account roles. This separates user/job-function mapping from privilege ownership and makes future access changes easier to manage.
- D. Incorrect.
Incorrect. Instance roles are associated with specific classes/instances and are not the standard mechanism for granting general database, schema, table, or warehouse privileges across an account. They do not replace account roles or database roles for typical RBAC design.