Roman Orlovskiy
03/27/2026, 4:20 PMloren
03/30/2026, 2:39 PMdepends_on, but instead to using the unknown value as the key in the for_each expression. the solution for that is "don't do that" 🙂 instead, use a known value as the key for the expression, and then use each.value... for the attribute you wantPaulo Gomes
06/08/2026, 2:49 PMdepends_on pointing to a resource with pending changes, Terraform defers the read to apply time, which then cascades into 'known after apply' on anything downstream.
For your SSO/SCIM case the cleanest workaround short of splitting the module is to avoid the data source lookup entirely. If you're creating the AD group in the same config, you likely already have the group name as a known value. You can pass it directly as a variable instead of looking it up via data source. The SCIM sync just needs to complete before the assignment, which depends_on handles, but the group ID lookup doesn't need to be a data source if the value is already in your config.
ignore_changes on the assignment resource works too but it's a footgun. You'll miss real changes down the line. Splitting the module is more surgical but the two-run requirement gets old fast.
There's no clean fix at the provider level. This is Terraform core behaviour that HashiCorp closed as by-design.