SnowPro Advanced: Security Engineer Question 9
Single answerIntegrate RBAC management with IdPs using SCIM (user group membership)A company uses Microsoft Entra ID as its corporate identity provider and wants to reduce manual administration of Snowflake access. The security team has enabled SCIM provisioning from Entra ID to Snowflake and wants membership in Entra ID groups to control which Snowflake roles users receive. They also want access to be removed automatically when a user is removed from an Entra ID group. Which approach should the security engineer implement?
- A
Provision Entra ID groups to Snowflake as SCIM-managed groups, grant the appropriate Snowflake account roles to those groups, and let SCIM update group membership in Snowflake.
- B
Provision Entra ID users with SCIM, but manage role grants directly on each Snowflake user because SCIM cannot synchronize group membership to Snowflake.
- C
Use SAML assertions only to pass group names during login and rely on Snowflake to create and maintain role assignments automatically from those SAML groups.
- D
Create Snowflake database roles for each Entra ID group and grant those database roles directly to users through SCIM so that account-level access is removed when group membership changes.
Show answer and explanation
Correct answer: A
Explanation
The key requirement is to integrate RBAC management with the IdP so that user access follows corporate group membership and is removed automatically when membership changes. In Snowflake, SCIM is the provisioning mechanism used with supported identity providers to create and manage users and groups, including group membership updates. The recommended operational model is to provision groups from the IdP into Snowflake and then grant Snowflake roles to those groups. This lets the IdP remain the source of truth for membership while Snowflake enforces authorization through role grants. SAML is primarily for authentication and federation, not object provisioning and lifecycle management. Best practice is to avoid direct user-by-user grants when group-based access can be managed through SCIM-provisioned groups. This aligns with Snowflake documentation on SCIM-based user and group provisioning and with RBAC best practices that favor assigning privileges to roles and roles to groups rather than directly to individual users.
- A. Correct.
Correct. For centralized RBAC lifecycle management with an IdP, the practical pattern is to provision groups from the IdP into Snowflake using SCIM, then grant Snowflake roles to those groups. SCIM manages the group membership, so when a user is added to or removed from the IdP group, Snowflake group membership is updated accordingly. This reduces manual user-by-user grant maintenance and supports automatic removal of access when membership changes.
- B. Incorrect.
Incorrect. This reflects a common misconception. SCIM integration with supported IdPs is specifically used to provision users and groups, including group membership changes. Managing grants directly on each user would reintroduce manual administration and would not align with the requirement to automate access changes based on IdP group membership.
- C. Incorrect.
Incorrect. SAML handles authentication and can support some role selection or federation patterns at login, but it is not the mechanism Snowflake uses to provision and continuously maintain user and group objects. Relying only on SAML group claims does not provide SCIM-based lifecycle management of group membership in Snowflake.
- D. Incorrect.
Incorrect. Database roles are scoped to database objects and are not the direct construct to map corporate groups for broad account-level RBAC administration. The requirement is to control Snowflake role assignment from IdP group membership; the common and supported pattern is to grant account roles to SCIM-provisioned groups, not to grant database roles directly to users through SCIM.