ARA-C01 Question 32
Single answerPrivilege inheritanceA Snowflake architect is designing access for a new analytics domain. The role hierarchy is: ANALYST -> SENIOR_ANALYST -> BI_LEAD, where BI_LEAD is granted SENIOR_ANALYST, and SENIOR_ANALYST is granted ANALYST. The ANALYST role has USAGE on database PROD_DB and schema PROD_DB.MART, and SELECT on all existing tables in PROD_DB.MART. BI_LEAD does not have any direct object grants. A user is assigned only the BI_LEAD role as their default role. During testing, the user can query existing tables in PROD_DB.MART successfully, but receives an authorization error when trying to query a newly created table in that schema. Which action should the architect take to ensure BI_LEAD users automatically inherit access to future tables while preserving least privilege?
- A
Grant SELECT on future tables in schema PROD_DB.MART to the ANALYST role.
- B
Grant OWNERSHIP on schema PROD_DB.MART to the BI_LEAD role.
- C
Grant SELECT on all future tables in database PROD_DB directly to the BI_LEAD role.
- D
Grant USAGE on warehouse(s) used for querying to the BI_LEAD role.
Show answer and explanation
Correct answer: A
Explanation
In Snowflake RBAC, privileges granted to a role are inherited by any role higher in the hierarchy that has been granted that role. In this scenario, BI_LEAD inherits the privileges of SENIOR_ANALYST and ANALYST, which is why the user can query existing tables without any direct grants to BI_LEAD. However, grants on existing tables do not automatically apply to tables created later. To cover new objects, the architect must use future grants, such as GRANT SELECT ON FUTURE TABLES IN SCHEMA PROD_DB.MART TO ROLE ANALYST. This is the most appropriate solution because it relies on privilege inheritance already in place and limits access to only what is required. Snowflake documentation on access control and future grants emphasizes that future grants are defined separately from grants on existing objects, and role hierarchy allows inherited privileges to flow upward through granted roles.
- A. Correct.
Correct. Privileges granted to a lower role in a role hierarchy are inherited by higher roles. Since BI_LEAD inherits SENIOR_ANALYST, which inherits ANALYST, granting SELECT on future tables in the schema to ANALYST ensures users operating with BI_LEAD automatically receive access to newly created tables as well. This preserves least privilege because the privilege is scoped only to future tables in the required schema rather than broadly at the database level or through ownership.
- B. Incorrect.
Incorrect. OWNERSHIP is the highest privilege and is not appropriate for read-only access requirements. Granting OWNERSHIP on the schema would violate least-privilege principles and unnecessarily allow BI_LEAD to manage the schema and transfer ownership. The issue is not with inheritance itself, but with the absence of future grants for new tables.
- C. Incorrect.
Incorrect. This could provide access to future tables, but it grants privileges directly to BI_LEAD and at a broader scope than required. The scenario already demonstrates that BI_LEAD correctly inherits privileges from ANALYST for existing objects. The missing piece is a future grant on the relevant schema, not a direct grant to the top-level role or a database-wide scope.
- D. Incorrect.
Incorrect. Warehouse USAGE is required to run queries, but it does not control access to table data. Because the user can already query existing tables, warehouse access is not the cause of the failure on newly created tables. The problem is object privilege coverage for future tables.