ADA-C01 Question 120
Single answerUse and monitor SCIMAn enterprise uses Microsoft Entra ID to provision Snowflake users and roles through SCIM. The security team reports that several terminated employees can still sign in to Snowflake with SSO, even though they were disabled in Entra ID more than a day ago. As the Snowflake administrator, you need to verify whether SCIM deprovisioning requests are reaching Snowflake and determine what happened to those identities after provisioning events were processed. Which action would provide the most direct evidence in Snowflake for this investigation?
- A
Query the ACCOUNT_USAGE.LOGIN_HISTORY view to confirm whether SCIM deprovisioning API calls were made and whether those calls succeeded
- B
Review the ACCOUNT_USAGE.PROVISIONING_HISTORY view to see SCIM create, update, and deactivate events and their outcomes for the affected users
- C
Run SHOW USERS and compare the DISABLED column for each affected user, because SCIM writes only to metadata and does not generate historical event records
- D
Inspect the ACCOUNT_USAGE.ACCESS_HISTORY view to identify when the identity provider sent SCIM disable requests and whether Snowflake rejected them
Show answer and explanation
Correct answer: B
Explanation
For SCIM investigations in Snowflake, the key requirement is to distinguish identity lifecycle events from authentication and query activity. When users are provisioned or deprovisioned through an identity provider such as Microsoft Entra ID or Okta, Snowflake exposes those SCIM-related events through ACCOUNT_USAGE.PROVISIONING_HISTORY. That view is the appropriate place to validate whether create, update, or deactivate operations were received and how Snowflake processed them. By contrast, LOGIN_HISTORY helps validate whether a user still authenticated after the expected deprovisioning time, but it does not prove that SCIM requests were sent or accepted. SHOW USERS provides only current state, not historical processing evidence. ACCESS_HISTORY is unrelated to SCIM and focuses on data access lineage and governance. In practice, administrators often correlate PROVISIONING_HISTORY with LOGIN_HISTORY to determine whether deprovisioning lag, IdP misconfiguration, or post-provisioning authentication settings allowed continued access.
- A. Incorrect.
Incorrect. LOGIN_HISTORY records user authentication attempts and session login activity, not SCIM provisioning operations. It may help confirm that users continued to authenticate, but it does not directly show whether Entra ID sent deprovisioning requests to Snowflake or whether those requests succeeded.
- B. Correct.
Correct. PROVISIONING_HISTORY is the Snowflake account usage view designed to monitor SCIM provisioning activity, including operations such as creating, updating, and deactivating users and roles, along with status details. For investigating whether deprovisioning requests reached Snowflake and what result Snowflake recorded, this is the most direct source of evidence.
- C. Incorrect.
Incorrect. SHOW USERS can reveal current state, such as whether a user is disabled, but it does not provide the event trail needed to investigate whether SCIM requests were received, when they were processed, or whether they failed. The misconception is assuming current object state is sufficient for auditing provisioning workflows.
- D. Incorrect.
Incorrect. ACCESS_HISTORY is used for data access and object-level query activity analysis, not identity lifecycle provisioning. It does not track SCIM API events from an identity provider. Someone might choose this because they associate 'access' with sign-in or authorization, but it is not the correct monitoring source for SCIM.