Impact Assessment
Severity: Moderate
This patch release resolves API payload formatting issues for Data Factory identity fields and unblocks slot deployments for container-based Linux Function Apps. It primarily addresses persistent diffs and deployment failures encountered when removing user-assigned identities or provisioning containerized slots.
Editor's Note: We view this as a routine maintenance patch aimed at smoothing out edge cases introduced in recent 4.x releases. The Azure API has become increasingly strict about payload types, which explains the shift from empty strings to empty objects for identity removals. If you manage Data Factory customer-managed keys, double-check your state files for lingering empty string values before applying this update.
Detailed Breakdown
#### Data Factory Identity Payload Fixes
Resources: azurerm_data_factory, azurerm_data_factory_customer_managed_key
* What changed: Removing customer_managed_key_identity_id (in azurerm_data_factory) or user_assigned_identity_id (in azurerm_data_factory_customer_managed_key) now sends an empty object ({}) to the Azure API instead of an empty string (""). Additionally, the provider includes a fix for a persistent ID parsing error on user_assigned_identity_id that occurred when Azure returned an empty string.
* Why this matters: The Azure Resource Manager API rejects empty strings for these specific identity fields, which previously caused terraform apply failures when attempting to detach an identity. The parsing fix also prevents perpetual diffs or state errors during routine planning phases.
* Migration steps: Review configurations where you actively remove or nullify these identity fields. Run a terraform plan after upgrading to verify the provider cleanly updates the state without attempting to recreate the Data Factory resources.
#### Linux Function App Container Slots
Resource: azurerm_linux_function_app_slot
* What changed: The provider includes a fix for an issue that prevented the deployment of a slot to a container-based function app.
* Why this matters: Teams relying on Docker containers for their Linux Function Apps were previously blocked from utilizing deployment slots natively, which disrupts blue/green deployment pipelines and staging environments.
* Migration steps: If you implemented workarounds (such as using the azapi provider or local-exec scripts) to create these slots, you can now refactor your code to use the native azurerm_linux_function_app_slot resource.
Before You Upgrade
1. Run terraform state list | grep azurerm_data_factory to identify all Data Factory instances in your current workspace.
2. Inspect the current state of your customer-managed keys using terraform state show 'azurerm_data_factory_customer_managed_key.example' to check for empty string values in the user_assigned_identity_id field.
3. Search your codebase for any nullified identity assignments using grep -r "customer_managed_key_identity_id = null" . to anticipate where the new empty object payload will apply.
4. Identify any Linux Function App configurations to see if they use the site_config { application_stack { docker { ... } } } block alongside slot resources.
5. Execute a terraform plan -refresh-only to help confirm your local state accurately reflects the remote Azure environment before upgrading the provider.
6. Update the provider version constraint in your versions.tf file to ~> 4.62.1 to pull in the patch.
7. Initialize the new provider version by running terraform init -upgrade.
8. Review the output of a standard terraform plan to verify that no unexpected resource replacements are triggered by the identity parsing fixes.
Sources & Timeline
* [Release v4.62.1](https://github.com/hashicorp/terraform-provider-azurerm/releases/tag/v4.62.1)
* [Release v4.62.0](https://github.com/hashicorp/terraform-provider-azurerm/releases/tag/v4.62.0)
Last Verified: 2026-03-02T22:04:10.020970+00:00