ADA-C01 Question 11
Single answer1.2 Given a set of business requirements, design access control frameworkA company is redesigning access control in Snowflake after several audit findings. The security team wants to enforce least privilege and simplify administration across 12 business domains. Each domain has its own schemas and future objects in a shared database. Data engineers need full object management within their domain schemas, analysts need read-only access to selected schemas, and a central platform team must retain the ability to grant roles and manage warehouses. Auditors also require that object ownership does not become fragmented across individual user roles. Which approach best meets these requirements?
- A
Use a DAC-centric model where individual users own the schemas and tables they create, and grant privileges directly to end users as needed for flexibility.
- B
Create a hierarchy of custom account roles using RBAC, with functional roles for analysts and engineers, domain-specific roles for schema access, and separate custom roles that own objects; grant these roles to users through higher-level business roles while keeping administrative privileges in dedicated platform roles.
- C
Grant SYSADMIN to all data engineers so they can manage domain objects, and use secondary roles for analysts to inherit read access from the engineers' roles when needed.
- D
Use only database roles inside the shared database for all access control needs, including warehouse administration and user management, because database roles can replace account roles in a centralized design.
Show answer and explanation
Correct answer: B
Explanation
The best answer is to implement a structured RBAC framework with custom account roles organized hierarchically, while separating object ownership from end-user roles. This aligns with Snowflake best practices for scalable access control design: grant privileges to roles, grant roles to other roles, and grant roles to users. For this scenario, a common pattern is to create domain-specific access roles, functional roles such as ANALYST and ENGINEER, and distinct owner roles that hold OWNERSHIP on schemas and future objects. This prevents individual users from becoming long-term object owners and supports consistent privilege management. Administrative responsibilities such as warehouse management and role grants should remain in dedicated platform roles, typically managed by central administrators. Snowflake documentation distinguishes between DAC and RBAC, and recommends role hierarchies for least-privilege administration. It also notes that database roles are scoped to a database and cannot be used for account-level administrative privileges, so they complement rather than replace account roles in enterprise designs.
- A. Incorrect.
This is incorrect because it relies on discretionary access control through individual ownership and direct user grants, which is difficult to audit and scale. It also conflicts with the requirement that ownership should not become fragmented across individual user roles. Snowflake best practice is to use role-based access control with grants assigned to roles rather than directly to users wherever possible.
- B. Correct.
This is correct. Snowflake recommends designing access with RBAC using roles granted to roles, separating functional access from administrative access, and assigning object ownership to controlled roles rather than individual users. Domain-specific roles can encapsulate schema-level privileges, analyst roles can receive read-only privileges, engineer roles can receive object creation and modification privileges, and dedicated owner roles can hold OWNERSHIP on schemas and objects. Administrative capabilities such as warehouse management and role grants should remain in dedicated platform roles, avoiding over-privileging domain users.
- C. Incorrect.
This is incorrect because SYSADMIN is a powerful account-level administrative role and granting it broadly violates least privilege. Data engineers who only need to manage objects within their domain schemas should receive narrowly scoped privileges through custom roles. Using SYSADMIN for domain-level work also makes auditing and separation of duties harder.
- D. Incorrect.
This is incorrect because database roles are useful for managing privileges on objects within a database, but they do not replace account roles for account-level privileges such as warehouse administration, user management, or global role administration. A complete enterprise design typically uses account roles, and may optionally incorporate database roles for database-scoped delegation.