Awscc_iot_domain_configuration ignores ignore_changes

We have the following code to create an IoT Domain Configuration:

resource "awscc_iot_domain_configuration" "custom" {
  domain_configuration_name   = trimsuffix(var.fqdn, ".${var.domain_name}")
  domain_configuration_status = "ENABLED"
  domain_name                 = var.fqdn
  server_certificate_arns     = [aws_acm_certificate.certificate.arn]
  service_type                = "DATA"

  tags = local.awscc_tags
  
  lifecycle {
    ignore_changes = [
      validation_certificate_arn,
    ]
  }
}

This creates the resource ok but in subsequent run the plan decides to replace the resource

  # module.test_1.awscc_iot_domain_configuration.custom must be replaced
-/+ resource "awscc_iot_domain_configuration" "custom" {
      ~ arn                         = "arn:aws:iot:eu-central-1:XXXXXXX:domainconfiguration/test1-702/qysea" -> (known after apply)
      + authorizer_config           = (known after apply)
      ~ domain_type                 = "CUSTOMER_MANAGED" -> (known after apply)
      ~ id                          = "test1-702" -> (known after apply)
      ~ server_certificates         = [
          - {
              - server_certificate_arn           = "arn:aws:acm:eu-central-1:XXXXXXXXX:certificate/3e948773-a577-4609-84d8-4e6a7ec06d0b" -> null
              - server_certificate_status        = "VALID" -> null
              - server_certificate_status_detail = "Server Certificate is valid" -> null
            },
        ] -> (known after apply)
      ~ tls_config                  = {
          ~ security_policy = "IoTSecurityPolicy_TLS13_1_2_2022_10" -> (known after apply)
        } -> (known after apply)
      + validation_certificate_arn  = (known after apply) # forces replacement
        # (5 unchanged attributes hidden)
    }

The validation_certificate_arn is a write only attribute and optional. We have set a lifecycle ignore_changes on this attribute but that has no impact.

Is there something we can do to force this?

That’s puzzling. Would you be able to show what the existing state of the resource looks like?

terraform state show module.test_1.awscc_iot_domain_configuration.custom

Sure:

resource "awscc_iot_domain_configuration" "custom" {
    arn                         = "arn:aws:iot:eu-central-1:XXXXXXXX:domainconfiguration/test1-702.chargers/glc44"
    domain_configuration_name   = "test1-702"
    domain_configuration_status = "ENABLED"
    domain_name                 = "test1-702. XXXXXXXX.com"
    domain_type                 = "CUSTOMER_MANAGED"
    id                          = "test1-702"
    server_certificate_arns     = [
        "arn:aws:acm:eu-central-1: XXXXXXXX:certificate/3e948773-a577-4609-84d8-4e6a7ec06d0b",
    ]
    server_certificates         = [
        {
            server_certificate_arn           = "arn:aws:acm:eu-central-1:XXXXXXXX:certificate/3e948773-a577-4609-84d8-4e6a7ec06d0b"
            server_certificate_status        = "VALID"
            server_certificate_status_detail = "Server Certificate is valid"
        },
    ]
    service_type                = "DATA"
    tags                        = [
        {
            key   = "ManagedBy"
            value = "Terraform"
        },
        {
            key   = "Purpose"
            value = "The purpose of the test"
        },
    ]
    tls_config                  = {
        security_policy = "IoTSecurityPolicy_TLS13_1_2_2022_10"
    }
}

Note that there is no value for the attribute causing the issue. Looking at the code on Github for this attribute I see this comment:

                        // ValidationCertificateArn is a write-only property.

Could this be related? Looking at the resource using the AWS CLI there is no value for the attribute either.

Have you upgraded the awscc provider version since you last performed a plan on this configuration?

I suspect that with the current code, every awscc_iot_domain_configuration without an explicitly specified validation_certificate_arn will be destroyed and recreated on every plan.

This is testing a module to put other the resource with a valid certificate and other impacted resources.

The workflow we use to test idempotency is:

terraform init
terraform plan -out plan
terraform apply plan
terraform plan
terraform plan -out plan -destroy
terraform apply plan

So the same version of the provider (v0.54.0) has been used for each run.

I’ll look at the validation certificate to see whether we can find one to use.

Ah, OK. I’m pretty sure this is a bug in the provider code, then. It doesn’t seem to be able to cope with write-only attributes that can be optionally not specified, properly.

As a workaround I’m going to use ignore_changes = all.

Its inelegant, but does allow me to use the resource until a fix is implemented.

Thanks for your help.