ADA-C01 Question 26
Single answerAnalyze the implications of role inheritance when granting or revoking privilegesA Snowflake administrator is troubleshooting why analysts can still query FINANCE_DB.RAW.TRANSACTIONS after a cleanup effort. The role hierarchy is:
- ANALYST was granted to user JSMITH.
- REPORTING was granted to ANALYST.
- FINANCE_READ was granted to REPORTING.
Previously, FINANCE_READ had USAGE on database FINANCE_DB, USAGE on schema RAW, and SELECT on table FINANCE_DB.RAW.TRANSACTIONS. To remove access, the administrator revoked SELECT on the table directly from role ANALYST, but JSMITH can still query the table when using ANALYST as the active role.
Which action will correctly remove JSMITH's ability to query FINANCE_DB.RAW.TRANSACTIONS through this role path?
- A
Revoke SELECT on FINANCE_DB.RAW.TRANSACTIONS from FINANCE_READ, or revoke the grant of FINANCE_READ to REPORTING.
- B
Revoke USAGE on FINANCE_DB from ANALYST, because child roles override inherited object privileges.
- C
Revoke REPORTING from ANALYST, then grant REPORTING back to ANALYST so inherited privileges are recalculated.
- D
Revoke SELECT on FINANCE_DB.RAW.TRANSACTIONS from user JSMITH directly, because direct user privilege revocation takes precedence over role inheritance.
Show answer and explanation
Correct answer: A
Explanation
This scenario tests a core RBAC principle in Snowflake: role privileges are additive and inherited through the role hierarchy. If role A is granted role B, then role A inherits the privileges of role B. A revoke must target either the role that actually holds the object privilege or the role-to-role grant that provides the inheritance path. Revoking a privilege from a different role in the chain does not cancel or override an inherited privilege from another granted role. In this case, ANALYST did not own the SELECT privilege directly; FINANCE_READ did. Therefore, the correct remediation is to revoke SELECT from FINANCE_READ or revoke FINANCE_READ from REPORTING. This aligns with Snowflake documentation on role hierarchy, privilege grants to roles, and the additive nature of access control in RBAC.
- A. Correct.
Correct. JSMITH still has access because ANALYST inherits privileges through REPORTING and then FINANCE_READ. Revoking SELECT directly from ANALYST has no effect if ANALYST was not the role that actually held the privilege. In Snowflake RBAC, privileges available through granted roles are inherited by the active role. To remove access, the administrator must revoke the privilege from the role that owns it (FINANCE_READ) or break the inheritance path by revoking FINANCE_READ from REPORTING.
- B. Incorrect.
Incorrect. Snowflake does not use a model where a child role can override inherited privileges by removing them locally. Also, revoking USAGE on the database from ANALYST would not necessarily remove inherited USAGE coming from FINANCE_READ. Privileges are additive through the role hierarchy; they are not negated by revoking a similar privilege from another role in the chain.
- C. Incorrect.
Incorrect. Regranting REPORTING is unnecessary and does not change the underlying privilege assignments. Snowflake role inheritance is evaluated from current grants; there is no separate recalculation step needed to remove inherited privileges. If FINANCE_READ is still granted to REPORTING and still has SELECT on the table, access remains.
- D. Incorrect.
Incorrect. In standard Snowflake access control, object privileges are granted to roles, and users obtain them by activating roles. The issue here is inherited role-based access, not a direct user grant. Revoking from the user would not address privileges inherited through ANALYST -> REPORTING -> FINANCE_READ.