Terraform management of PIM Eligible Role Assignments via AzAPI

Question

Terraform management of PIM Eligible Role Assignments via AzAPI

Sumit Gaur 475

Hi,

I am looking for guidance on the recommended approach for managing Microsoft Entra PIM eligible role assignments through Terraform.

We initially attempted to use the native Terraform AzureRM resource: azurerm_pim_eligible_role_assignment

However, in our environment, the resource creation eventually times out because the provider is unable to reliably verify the state of the PIM request/assignment after it has been submitted. The PIM assignment itself is successfully created in Azure, but Terraform is unable to confirm the resulting state.

As an alternative, we are testing the AzAPI provider using the Azure API:

Microsoft.Authorization/roleEligibilityScheduleRequests

Using AzAPI, we are able to successfully create the eligible role assignment by submitting an AdminAssign request.

However, we have encountered a lifecycle-management issue when the Terraform resource needs to be deleted.

From our understanding, deleting the roleEligibilityScheduleRequests request resource does not remove the underlying PIM eligibility. To remove the eligibility, Azure requires a separate AdminRemove request.

This creates a mismatch with Terraform's resource lifecycle:

Terraform Create
       ↓
roleEligibilityScheduleRequests
       ↓
AdminAssign
       ↓
PIM Eligible Assignment created


Terraform Destroy
       ↓
Terraform resource deleted
       ↓
PIM Eligible Assignment still exists
       ↓
AdminRemove request is required separately

Our question is:

What is Microsoft's recommended and supported approach for managing the complete lifecycle of PIM eligible role assignments through Terraform when using Microsoft.Authorization/roleEligibilityScheduleRequests?

Specifically:

Is there a supported API/resource pattern where a Terraform destroy operation can reliably result in an AdminRemove request being submitted?

Is Microsoft.Authorization/roleEligibilityScheduleRequests intended to be managed directly as a Terraform resource, or should Terraform manage a different PIM resource representing the resulting eligibility?

Is there a recommended Azure API that allows us to directly manage the lifecycle of the PIM eligible assignment rather than managing the individual AdminAssign/AdminRemove requests?

Is the timeout/verification behavior of azurerm_pim_eligible_role_assignment a known limitation with the PIM APIs? If so, is there a recommended workaround or provider configuration?

If AzAPI is the recommended approach, could you provide an example of how Microsoft recommends implementing both AdminAssign and AdminRemove while maintaining Terraform state and idempotency?

We are specifically looking for a sustainable production approach, rather than relying on manual removal or Terraform destroy-time scripts/provisioners.

Any guidance on the recommended API/resource model for Terraform-based PIM lifecycle management would be greatly appreciated.

0 comments

1 answer

Your answer

Answer 1

Hello @Sumit Gaur

Your understanding of the lifecycle is correct.

Microsoft.Authorization/roleEligibilityScheduleRequests should be thought of as a request/action resource, rather than the PIM eligibility itself. Creating an AdminAssign request creates the eligible assignment, but deleting that request resource doesn't semantically reverse the operation. Removing the eligibility requires another request with requestType = AdminRemove.

Because of that, don't model roleEligibilityScheduleRequests as a normal Terraform CRUD resource and expect:

terraform destroy → DELETE request resource → eligibility removed

Those operations don't have equivalent semantics.

For Terraform, the preferred abstraction is currently the AzureRM provider's: azurerm_pim_eligible_role_assignment

This resource specifically manages the lifecycle of a PIM Eligible Role Assignment, including scope, role definition, principal, and schedule.

A basic example is:

resource "azurerm_pim_eligible_role_assignment" "example" {
  scope              = azurerm_resource_group.example.id
  role_definition_id = data.azurerm_role_definition.reader.id
  principal_id       = azuread_group.example.object_id
  schedule {
    expiration {
      duration_days = 365
    }
  }
}

In other words, AzureRM should own the desired eligibility, while the underlying PIM schedule-request API remains an implementation detail.

Your AzureRM timeout is the issue to investigate, not replacing the resource permanently with an AzAPI roleEligibilityScheduleRequests resource. The fact that eligibility is created successfully but Terraform times out while reading/verifying it suggests a provider/API reconciliation issue rather than a failure of the PIM assignment itself.

Capture the AzureRM provider version, Terraform debug log, assignment scope, principal type, and whether the assignment has an expiration schedule. If the assignment appears successfully in PIM after Terraform times out, that's particularly useful evidence for a HashiCorp AzureRM provider issue.

Before doing anything else, test against the current AzureRM provider release. The Terraform Registry currently documents azurerm_pim_eligible_role_assignment as a supported resource.

If you must use AzAPI as a workaround, don't expect a single azapi_resource representing the AdminAssign request to provide correct destroy semantics. The lifecycle would need to explicitly model:

Create desired eligibility > Submit AdminAssign > Wait/read resulting eligibility > Destroy desired eligibility >Discover current eligibility > Submit AdminRemove > Wait until eligibility disappears

That last step is especially important for idempotency. Verify the resulting eligibility schedule, not whether the original request object still exists.

This request-based model isn't unique to Azure RBAC PIM. Microsoft Graph exposes Entra PIM using the same conceptual separation: roleEligibilityScheduleRequest represents the request, while roleEligibilitySchedule represents the resulting eligibility. Microsoft documents the request API as supporting add, revoke and extend operations rather than ordinary CRUD semantics.

Avoid Terraform local-exec/destroy-time scripts if this is intended to be a long-lived production solution. They make it difficult for Terraform to determine whether AdminRemove completed, failed asynchronously, or was already performed outside Terraform.

So I recommend using azurerm_pim_eligible_role_assignment as the lifecycle resource and troubleshooting/reporting its post-create timeout. Use AzAPI only as a temporary workaround if the AzureRM provider issue blocks you.

If you can provide the AzureRM provider version and the final Terraform error/timeout message, we can narrow down whether you're hitting an existing provider issue or a particular PIM API/state-read condition.

References:

azurerm_pim_eligible_role_assignment - Terraform Registry

Microsoft Graph - Create role eligibility schedule request

Microsoft Graph - List role eligibility schedules

=============================================================================

Help make this community better for everyone: If this answer helped or resolved your issue, please accept it or upvote it. If not, share more details in a comment so we can continue the discussion and find the right solution. Thank you.