Loading...
Loading...
This is continuation of #29716 since the original issue is closed and won't allow replies. It was closed because of no reproducible example, here providing one. ### Steps to Reproduce 1. have a key vault resource ```yaml resource "azurerm_key_vault" "example" { name = "examplekeyvault" location = azurerm_resource_group.example.location resource_group_name = azurerm_resource_group.example.name enabled_for_disk_encryption = true tenant_id = data.azurerm_client_config.current.tenant_id soft_delete_retention_days = 7 purge_protection_enabled = false sku_name = "standard" access_policy { tenant_id = data.azurerm_client_config.current.tenant_id object_id = data.azurerm_client_config.current.object_id key_permissions = [ "Get", ] secret_permissions = [ "Get", ] storage_permissions = [ "Get", ] } } ``` 2. key vault secret data source ```yaml data "azurerm_key_vault_secret" "example" { name = "secret-sauce" key_vault_id = data.azurerm_key_vault.example.id } ``` 3. have some resource referencing key vault secret value from data source 4. apply configuration 5. change some property for key vault (I've tested with disabling/enabling public access for key vault) 6. run plan and observe that the secret datasources must be read during apply and resources depending on them are going to be reconfigured or re-created. maybe that is working as intended, but it seems strange that secrets have to be read during apply, because of changing such irrelevant properties on the key vault
Click on a version to see all relevant bugs
Terraform Integration
Learn more about where this data comes from
Bug Scrub Advisor
Streamline upgrades with automated vendor bug scrubs
BugZero Enterprise
Wish you caught this bug sooner? Get proactive today.