ADA-C01 Question 19
Select 2User-based Access Control (UBAC)A Snowflake administrator is enabling User-based Access Control (UBAC) for a small analytics team that has several service accounts and temporary contractors. The security team wants object privileges to be granted directly to individual users only in tightly controlled exceptions, while continuing to rely primarily on role-based access control for all standard access patterns. The administrator needs to identify which actions are valid and aligned with how UBAC works in Snowflake. Which TWO actions should the administrator take?
- A
Grant object privileges directly to a user only after enabling the account parameter that allows direct user grants, and ensure the user also has a role that is allowed to exercise those privileges in a session.
- B
Use direct grants to users as a replacement for roles, because once UBAC is enabled, users no longer need roles to access granted objects.
- C
Grant privileges directly to specific users for narrowly scoped exceptions, while continuing to use roles as the primary access model for broader, maintainable privilege management.
- D
Grant a database role directly to a user as part of UBAC, because database roles are object privileges and can be assigned the same way as SELECT or USAGE.
- E
Expect privileges granted directly to a user to be available regardless of whether secondary roles are enabled in the user's session.
Show answer and explanation
Correct answers: A, C
Explanation
Snowflake's User-based Access Control (UBAC) allows direct grants of object privileges to users, but only when the relevant account-level capability is enabled. Even then, Snowflake continues to recommend role-based access control (RBAC) as the primary access-management model because roles are easier to govern, audit, and maintain at scale. Direct user grants are best reserved for controlled exceptions, such as temporary or highly specific access needs. Another important nuance is session behavior: directly granted privileges are associated with secondary role usage, so administrators must understand how active and secondary roles affect privilege evaluation. Database roles are separate from direct object privilege grants and are not granted directly to users. These points are consistent with Snowflake documentation on access control, user grants, secondary roles, and best practices for privilege management.
- A. Correct.
Correct. In Snowflake, UBAC allows privileges on securable objects to be granted directly to users, but this capability must be enabled with the appropriate account-level setting. Also, direct user grants are considered in combination with the roles active in the session; they are not a complete replacement for having roles available. This reflects Snowflake guidance that direct user grants are an exception-oriented capability rather than the primary design pattern.
- B. Incorrect.
Incorrect. UBAC does not replace the role-based access control model. Snowflake security best practice remains to manage access through account roles and, where relevant, database roles. Direct user grants are intended for limited scenarios and do not eliminate the need for roles in user sessions.
- C. Correct.
Correct. This is the recommended operational approach. Snowflake supports direct grants to users under UBAC, but role-based access control remains the preferred model for scalability, auditing, and maintainability. Using direct grants only for exceptional, tightly scoped needs fits both the scenario and Snowflake best practices.
- D. Incorrect.
Incorrect. Database roles are granted to roles, not directly to users. A common misconception is to treat database roles like object privileges that can be assigned anywhere. In practice, database roles participate in role hierarchy and are granted to account roles or other database roles as supported, not directly to users as part of UBAC.
- E. Incorrect.
Incorrect. A key detail of UBAC is that direct user grants are considered through secondary role behavior in the session. If secondary roles are not enabled as needed, the user may not be able to exercise privileges granted directly to them. Assuming these privileges are always active regardless of session role configuration is a common mistake.