ADA-C01 Question 16
Single answerDiscretionary Access Control (DAC)A Snowflake administrator is reviewing access after a data engineering lead reported an unexpected privilege escalation. Role ANALYST_RW was granted SELECT on schema FINANCE.RAW by role DATA_ENG_ADMIN. Later, a different role, REPORTING_LEAD, was able to grant SELECT on several existing tables in FINANCE.RAW to another team, even though the security team expected only DATA_ENG_ADMIN to be able to delegate that access. The administrator discovers that REPORTING_LEAD had previously been granted SELECT on the same schema WITH GRANT OPTION by DATA_ENG_ADMIN. Which action should the administrator take to prevent REPORTING_LEAD from delegating that privilege in the future while preserving REPORTING_LEAD's own ability to query objects in the schema?
- A
Revoke SELECT on schema FINANCE.RAW from REPORTING_LEAD, then grant SELECT on schema FINANCE.RAW back to REPORTING_LEAD without GRANT OPTION
- B
Transfer ownership of schema FINANCE.RAW to SECURITYADMIN, because only the owning role can control downstream grants
- C
Revoke USAGE on database FINANCE from REPORTING_LEAD, because removing database visibility prevents further delegation of object privileges
- D
Grant MANAGE GRANTS to REPORTING_LEAD so that future grants can be centrally audited and controlled
Show answer and explanation
Correct answer: A
Explanation
This scenario tests practical understanding of Snowflake discretionary access control (DAC), specifically the effect of granting object privileges WITH GRANT OPTION. In Snowflake, if a role is granted a privilege such as SELECT on a securable object with GRANT OPTION, that role can grant the same privilege to other roles. To remove the ability to delegate while retaining the underlying access, the standard remediation is to revoke the current grant and reissue it without GRANT OPTION.
This is a common administrative issue when privileges were delegated for convenience but later violate least-privilege or separation-of-duties requirements. Changing ownership or adding broader administrative privileges like MANAGE GRANTS is not an appropriate fix for a narrowly scoped DAC problem. Likewise, revoking dependent privileges like USAGE may block access but does not address the delegation mechanism itself.
Relevant Snowflake documentation and best practices include the access control model, GRANT
- A. Correct.
Correct. In Snowflake's discretionary access control model, a role that receives a privilege WITH GRANT OPTION can grant that same privilege to other roles. To stop REPORTING_LEAD from further delegating SELECT while still allowing query access, the administrator should revoke the existing privilege and re-grant it without GRANT OPTION. This preserves the operational access but removes the delegation capability.
- B. Incorrect.
Incorrect. Ownership is powerful and can manage grants on the object, but changing ownership is unnecessary and potentially disruptive here. The issue is not who owns the schema; it is that REPORTING_LEAD holds SELECT WITH GRANT OPTION. Even if SECURITYADMIN owns the schema, REPORTING_LEAD could still delegate privileges already granted WITH GRANT OPTION until that specific grant is revoked or replaced.
- C. Incorrect.
Incorrect. Revoking USAGE on the database would block access resolution to objects in the database, which would affect REPORTING_LEAD's ability to query the schema. It also does not address the core DAC issue cleanly: REPORTING_LEAD's privilege includes GRANT OPTION. The requirement is to preserve query ability while preventing delegation.
- D. Incorrect.
Incorrect. MANAGE GRANTS is a powerful global privilege intended for centralized grant management and effectively allows a role to modify grants without owning the object. Giving REPORTING_LEAD MANAGE GRANTS would expand administrative capability, not restrict delegation. It is the opposite of the least-privilege goal in this scenario.