SnowPro Advanced: Security Engineer Question 8
Single answerAutomate RBAC management programmaticallyA security engineering team wants to automate RBAC onboarding for new analytics projects in Snowflake. Their CI/CD pipeline must create a project-specific role hierarchy, grant least-privilege access to existing schemas, and ensure every run is safe to repeat without creating inconsistent privilege states. The team also wants to avoid embedding broad administrative privileges in the automation account. Which approach best meets these requirements?
- A
Create a dedicated automation role that has MANAGE GRANTS globally, and use it to issue all GRANT statements directly in every deployment because this guarantees least privilege and idempotency.
- B
Implement the RBAC changes in version-controlled SQL or Snowflake Scripting, execute them through a dedicated role that owns only the managed access schemas or relevant objects, and make the deployment logic re-runnable by checking existing grants/roles before issuing DDL where needed.
- C
Run the pipeline as ACCOUNTADMIN so it can create roles and grant privileges across all projects, and rely on audit history later to detect any over-granting introduced by the scripts.
- D
Use future grants exclusively for all access control automation, because future grants automatically cover existing objects and remove the need to create role hierarchies programmatically.
Show answer and explanation
Correct answer: B
Explanation
The best answer is to treat RBAC as code and execute it with a narrowly scoped role rather than a broadly privileged administrative role. In Snowflake, programmatic RBAC automation commonly uses SQL, Snowflake Scripting, or API/driver-based execution from CI/CD. To satisfy least privilege, the automation role should be granted only the rights needed to create and manage the intended roles and object grants. For grant delegation, Snowflake ownership rules and managed access schemas are especially important: in managed access schemas, object owners do not control grants; the schema owner or a role with MANAGE GRANTS does. This makes managed access schemas a strong pattern for centralized, controlled privilege automation. For repeatable deployments, teams should design scripts to be idempotent or safely re-runnable by validating current state and only applying missing changes where necessary. Snowflake documentation on access control, role hierarchies, OWNERSHIP, MANAGE GRANTS, and managed access schemas supports these practices.
- A. Incorrect.
Incorrect. A role with MANAGE GRANTS is highly privileged and is not the best fit when the requirement is to avoid embedding broad administrative capabilities in the automation account. While MANAGE GRANTS can centralize grant administration, it does not by itself guarantee least privilege or idempotent deployments. Idempotency must be designed in the automation logic. This option also overstates the suitability of a global grant-management privilege for project-scoped onboarding.
- B. Correct.
Correct. This approach aligns with Snowflake best practices for programmatic RBAC automation: define role creation and grants as code, keep them in version control, and execute them using a narrowly scoped automation role. Where possible, the automation role should own only the relevant objects or managed access schemas so it can grant privileges without needing broad account-wide powers. Making the process re-runnable requires explicit handling in code, such as checking whether roles already exist and validating or reconciling grants before applying changes. This supports least privilege, repeatable deployments, and reduced operational drift.
- C. Incorrect.
Incorrect. ACCOUNTADMIN is powerful, but using it for routine automation violates least-privilege principles and increases blast radius if credentials are misused or scripts are incorrect. Audit history is valuable for monitoring and investigation, but it is not a substitute for preventive security design. The scenario explicitly requires avoiding broad administrative privileges in the automation account.
- D. Incorrect.
Incorrect. Future grants are useful for automatically granting privileges on objects created later, but they do not replace the need to handle existing objects, create role hierarchies, or manage all RBAC relationships programmatically. In fact, future grants do not automatically backfill access to existing objects; those typically require separate grants. Relying only on future grants would leave gaps in access management for current schemas and objects.