ADA-C01 Question 123
Single answerManage users and groups with SCIMA company uses Microsoft Entra ID to provision Snowflake users and groups through SCIM. The security team wants group membership in Entra ID to control access in Snowflake with minimal manual administration. During testing, a user is successfully created in Snowflake by SCIM, but after the user is added to the Entra ID group mapped to the ANALYST role, the user still cannot use the role in Snowflake. Which action should the Snowflake administrator take to ensure the SCIM integration can manage role membership as intended?
- A
Grant the SCIM security integration ownership of the ANALYST role so SCIM can update role grants directly.
- B
Create a Snowflake role for the Entra ID group and set the role's comment to match the group's object identifier.
- C
Ensure the ANALYST role is owned by the role associated with the SCIM security integration, such as the role in the RUN_AS_ROLE parameter.
- D
Assign the ACCOUNTADMIN role to the SCIM-provisioned users so role inheritance is recalculated after each synchronization.
Show answer and explanation
Correct answer: C
Explanation
When Snowflake is integrated with an identity provider through SCIM, user lifecycle actions such as creating or disabling users can succeed even if group-based role assignment later fails. A common cause is insufficient privilege for the Snowflake role used by the SCIM integration. To let SCIM manage membership for a Snowflake role mapped from an Entra ID group, the SCIM execution role must have the authority to grant and revoke that role, which in practice means the role is owned by or otherwise controllable by the SCIM run-as role. This aligns with Snowflake best practices for SCIM provisioning: configure the security integration to run as a dedicated administrative role, and ensure that role has the required ownership and user-management privileges rather than using broad administrative roles for end users. Relevant Snowflake documentation covers SCIM security integrations, the RUN_AS_ROLE behavior, and role ownership/privilege requirements for managing users and role grants.
- A. Incorrect.
Incorrect. A security integration does not own roles. In Snowflake, SCIM operations run using privileges granted to a Snowflake role, typically specified through the SCIM integration configuration (for example, the RUN_AS_ROLE). Role ownership in Snowflake must be assigned to an actual role, not to the integration object itself.
- B. Incorrect.
Incorrect. SCIM group provisioning to Snowflake does not rely on setting a Snowflake role comment to an identity provider group object ID. While external identity metadata can be useful operationally, Snowflake role membership management through SCIM depends on the mapping between the IdP group and the Snowflake role, along with sufficient privileges held by the SCIM execution role. Simply updating comments will not allow SCIM to grant the role to users.
- C. Correct.
Correct. For SCIM-managed group membership to update user-to-role assignments in Snowflake, the SCIM integration must run as a Snowflake role that has sufficient privileges to manage those assignments. In practice, the target role such as ANALYST must be owned by, or otherwise manageable through, the role used by the SCIM integration (commonly the role named in RUN_AS_ROLE). Without proper ownership/authority over the role, user provisioning may succeed but group-to-role membership updates can fail.
- D. Incorrect.
Incorrect. Granting ACCOUNTADMIN to end users is not a valid or secure way to address SCIM synchronization of role membership. SCIM does not require elevated privileges on the provisioned users themselves; it requires the provisioning process to run with a role that has authority to manage the target users and roles. This option reflects a common misconception that access issues should be solved by overprivileging users.