Terraform deployment fails when creating Azure Event Grid subscriptions for storage-based pipeline

Hey @Dimitrios Bardis

Thank you for reaching out to Microsoft Q&A.

Based on what you shared, this looks like Terraform is successfully reaching Azure, but the Event Grid event subscription create call is returning a generic internal server error and rolling back the impacted resources.

Because the provided docs don’t include Event Grid to Storage Queue specific “known causes” for subscription creation with managed identity, I can only map likely categories from the general troubleshooting guidance and the Terraform deployment failure guidance included below.

What you can check (from the provided guidance)

1) Validate storage/Event Grid trigger prerequisites (most common configuration blockers)

Even though your error says “internal server error”, configuration issues can still surface as non-actionable ARM failures. The provided storage trigger guidance suggests checking:

Storage account configuration

Ensure required settings are correct, specifically network settings (e.g., storage firewall/VNet restrictions) and access keys availability where applicable.

Event Grid subscription configuration

Confirm the subscription includes the intended event types (for you: Microsoft.Storage.BlobCreated).

Event subscription target expectations

Ensure the destination is configured correctly in Event Grid (you’re using Storage Queue as the endpoint type).

Additionally, there’s a related case note in the provided materials showing a similar Event Grid → Storage delivery scenario failing when:

the storage account was effectively not reachable due to private networking, and

the required queue message sender permission wasn’t present, until the role and connectivity were fixed.

So, even for subscription creation, it’s worth confirming network reachability and queue permissions are fully in place (see RBAC questions below).

2) Terraform race conditions / dependency ordering

The Terraform deployment guidance provided is generic, but it directly calls out two things that often produce vague “internal server error” outcomes during creates:

Avoid implicit dependencies: explicitly add depends_on where Event Grid subscriptions depend on:

storage account readiness,

event grid system topic readiness,

queue destination readiness/permissions,

any role assignments you apply for the managed identity.

Reduce Terraform parallelism: run with reduced parallelism to avoid parallel create operations that depend on each other.

(The guidance specifically suggests trying terraform apply parallelism =1.)

This is especially relevant in your step-by-step flow where you “enable a feature flag” and then run terraform apply that’s a classic way to accidentally trigger parallel creation.

3) Check whether you’re blocked by RBAC propagation / role assignment timing

Your question mentions managed identity/RBAC timing, and the provided materials support the general concept that permissions/network readiness must be correct and present before delivery/creation proceeds.

For your scenario, the minimum “shape” to verify is:

The user-assigned managed identity used by Event Grid delivery has the necessary role on the Storage Queue.

The provided related example explicitly references the need for Storage Queue Data Message Sender-type permissions for successful delivery.

Role assignment is definitely completed before subscription creation.

With Terraform, ensure it’s not created “in parallel” with the Event Grid subscription.

Is it more likely a Terraform/provider issue or an Azure resource validation issue?

From the provided docs alone:

The guidance for Terraform failures strongly suggests race/dependency issues (use depends_on, lower parallelism) as a first remediation path.

The storage trigger guidance suggests network/access configuration and event subscription correctness as another first path.

So, based on the included documentation, the most likely buckets are:

Dependency ordering / timing (Terraform creates Event Grid subscription before queue permissions/network assumptions are fully ready)

Storage account network/firewall/VNet settings preventing Event Grid from being able to validate/connect

Less likely (but possible): an Azure-side transient issue (“Please try again in a few minutes” is consistent with transient platform behavior)

Practical next steps to suggest in the forum post

Add explicit depends_on from each azurerm_eventgrid_event_subscription to:

the Event Grid system topic resource,

the storage account (and anything network/firewall-related),

the storage queue resource,

the role assignment granting queue message sender permissions to the managed identity.

Try running Terraform with lower parallelism (per the provided doc).

Re-try after a short wait (“few minutes”) to rule out transient platform issues.

In the Azure portal, confirm:

Event Grid subscription targets the correct Storage Queue endpoint configuration,

the storage networking/firewall doesn’t block required access at the time of create,

the managed identity has the right queue-level sender role.

If it still fails after the above, the most helpful forum/support path is to collect more evidence:

Terraform trace/debug output (the Terraform doc suggests using TF_LOG=DEBUG / TRACE),

whether other resources created in the same run succeed,

whether the issue correlates with private networking or storage firewall state.

Event Grid eventSubscriptions Terraform property shapes (endpointType StorageQueue):

https://learn.microsoft.com/azure/templates/microsoft.eventgrid/2019-01-01/eventsubscriptions

https://learn.microsoft.com/azure/templates/microsoft.eventgrid/eventsubscriptions