ADA-C01 Question 119
Single answerUse and monitor SCIMAn enterprise uses Microsoft Entra ID to provision Snowflake users and roles through SCIM. Over the last week, several newly hired analysts were successfully created in Snowflake, but they could not sign in because no default role was assigned. The identity team confirms that role memberships are being sent from Entra ID, and the Snowflake administrator wants to verify whether SCIM updates are being received and applied, without relying only on the IdP logs. Which Snowflake approach is the most appropriate to monitor and troubleshoot this provisioning activity?
- A
Query the ACCOUNT_USAGE event/audit views that record SCIM-related provisioning operations to review recent create/update activity and correlate it with affected users
- B
Run SHOW USERS and compare the current DEFAULT_ROLE values to the expected roles, because SHOW output includes a history of SCIM API requests and their status codes
- C
Use QUERY_HISTORY to find the SCIM REST calls, because all inbound SCIM provisioning requests are captured there as SQL statements executed by the security integration
- D
Review the login history of the affected users, because failed interactive logins expose the exact SCIM attribute mapping error that prevented DEFAULT_ROLE from being set
Show answer and explanation
Correct answer: A
Explanation
For SCIM troubleshooting, the administrator should use Snowflake’s monitoring and audit capabilities that expose provisioning activity rather than relying on object snapshots or login data alone. In practice, SHOW USERS helps validate current user attributes, but it is not a monitoring source for SCIM transactions. QUERY_HISTORY is limited to SQL activity and does not capture inbound SCIM API requests. LOGIN_HISTORY is useful for authentication troubleshooting, not provisioning diagnostics. Snowflake documentation for SCIM user and role provisioning, along with account usage and event/audit monitoring guidance, supports using Snowflake’s account-level telemetry to review identity lifecycle events and correlate them with affected principals. This is the best-practice approach when verifying whether SCIM updates were actually received and applied.
- A. Correct.
Correct. Snowflake provides account-level usage and audit visibility for identity lifecycle activity, including SCIM provisioning events, which is the appropriate Snowflake-native way to monitor whether create and update operations were received and applied. This helps the administrator validate whether user objects were created, whether updates occurred, and when those actions happened, without depending solely on the identity provider. From there, the admin can correlate provisioning activity with the affected users and investigate attribute mapping issues such as missing default-role assignment.
- B. Incorrect.
Incorrect. SHOW USERS is useful for inspecting the current state of user objects, including attributes like DEFAULT_ROLE, but it does not provide historical SCIM request telemetry or HTTP-level provisioning status. It can confirm that a value is missing now, but it cannot reliably show whether SCIM attempted to set it or when an update occurred.
- C. Incorrect.
Incorrect. QUERY_HISTORY tracks SQL statements executed in Snowflake, not inbound SCIM REST API calls from an identity provider. SCIM provisioning is not exposed as SQL text in query history, so this is a common but incorrect assumption when administrators are used to troubleshooting SQL-driven changes.
- D. Incorrect.
Incorrect. LOGIN_HISTORY can show whether the users attempted to log in and whether authentication succeeded or failed, but it does not reveal SCIM provisioning payload details or attribute-mapping failures. A user failing to sign in because of role-related issues does not mean login history will contain the root cause of the provisioning problem.