stackit_resourcemanager_project creation fails with "must be part of the same hierarchy" against an unrelated organization, only when iam experiment is enabled

[TimBitzer]

Description

When the iam experiment is enabled in the provider block (required for stackit_authorization_organization_role_assignment / stackit_authorization_project_role_assignment resources used elsewhere in our config), creating a stackit_resourcemanager_project under a folder fails with a FailedPrecondition 409, citing a completely unrelated organization as the folder's "parent organization" — even though the target folder is verifiably parented under the correct organization via the resource-manager API directly. The identical create operation, issued via the stackit CLI with the same service-account credentials, succeeds immediately. Disabling iam makes the exact same stackit_resourcemanager_project resource plan and (if the other iam-gated resources are temporarily removed) apply cleanly, pointing at a side effect of the iam experiment on unrelated resource types rather than a problem with the resource itself.

Steps to reproduce

provider "stackit" {
  experiments = ["iam"] # required elsewhere in config for stackit_authorization_organization_role_assignment
}

resource "stackit_resourcemanager_folder" "example" {
  name                 = "example-folder"
  parent_container_id  = var.organization_id
  owner_email          = var.owner_email
}

resource "stackit_resourcemanager_project" "example" {
  parent_container_id = stackit_resourcemanager_folder.example.container_id
  name                = "example-project"
  owner_email         = var.owner_email
}

resource "stackit_authorization_organization_role_assignment" "sa_owner" {
  # unrelated resource elsewhere in config that requires the iam experiment
  resource_id = var.organization_id
  role        = "organization.owner"
  subject     = var.service_account_email
}

1. Authenticate Terraform via a service-account key (STACKIT_SERVICE_ACCOUNT_KEY_PATH) that has organization.owner on the target organization, created inside a project that is itself a direct child of that same organization.
2. Run terraform apply with the config above.
3. Observe stackit_resourcemanager_project.example fail with a 409 FailedPrecondition.
4. With stackit auth activate-service-account using the identical service-account credentials, run stackit project create --parent-id <same folder container ID> via the plain CLI — this succeeds immediately.
5. Confirm via GET /v2/folders/{folderId} (e.g. stackit curl https://resource-manager.api.stackit.cloud/v2/folders/{folderId}) that the folder's real parent is the correct organization, with no reference anywhere to the organization named in the error.
6. Temporarily set experiments = [] (removing iam) — terraform plan now shows stackit_resourcemanager_project.example as a clean "to be created" with no errors, confirming the resource type itself isn't gated by iam.

Actual behavior

terraform apply fails on stackit_resourcemanager_project with:

Error: Error creating project

  with stackit_resourcemanager_project.example,
  on main.tf line X, in resource "stackit_resourcemanager_project" "example":
   X: resource "stackit_resourcemanager_project" "example" {

Calling API: 409 Conflict, status code 409, Body: {"timeStamp":"...","path":"/resource-management/v2/projects","status":409,"error":"Conflict","message":"object folder landing-zones-public-e3oz6n1 parent organization prodyna-se-eAz2wz1: rpc error: code = FailedPrecondition desc = object must be part of the same hierarchy"}

Trace ID: "3451f608111657f9addda16fe114707c"

This is 100% reproducible across multiple terraform apply runs, days apart (ruling out an eventual-consistency/propagation issue). The organization named in the error (prodyna-se-eAz2wz1) is not our organization, is not the folder's actual parent (confirmed via direct API query), and is an organization our credentials have no visibility into at all (a GET on it returns 403 Forbidden). The same project creation, with the same folder and same service-account credentials, succeeds without error via the stackit CLI directly. Interestingly, creating other projects via the same Terraform run under a different sibling folder (e.g. one used for our "platform" project) succeeds without issue — only some folders/projects are affected.

Expected behavior

stackit_resourcemanager_project creation should succeed via Terraform whenever the identical operation succeeds via the stackit CLI with the same credentials, regardless of whether the iam experiment is enabled elsewhere in the provider configuration. Enabling iam for unrelated stackit_authorization_* resources should not alter how the provider resolves organizational/hierarchy context for stackit_resourcemanager_project.

Environment

• OS: Windows 11 Enterprise (10.0.26200)
• Terraform version (see terraform --version): v1.15.8
• Version of the STACKIT Terraform provider: v0.101.0

Additional information

Workaround currently in use: create the project via stackit CLI directly, then bring it under Terraform management with a declarative import block (the classic terraform import CLI command does not work around this, since it hits an unrelated "Invalid count argument" error during its full-config refresh). The rest of the module's iam-gated resources (RBAC role assignments, service accounts) then apply normally against the already-existing, imported project.