Description
This is very interesting and I didn't notice this until today.
When I created an aws_acm_certificate everything was fine. I didn't need to run apply on it again. Today, for reasons outside the scope of this issue, I ran another terraform apply to the same file with no changes made to it. To my surprise, it actually wanted to destroy the current cert and make a new one. All because the subject_alternative_names were in a different order. This is a bit concerning because the order of these did not change in the script. How the data was stored was not the order I had it in.
NOTE: this does not show anything if you run terraform plan
One would think, ok so perhaps just keep it in alphabetical order.. nope. The order seems to be whatever it wants. So it seems it's best to run terraform apply a second time afterwards and update your order in the script to match what is stored.
This cannot be expected behavior.
This is an area of concern because you would not expect this to happen without updating your script. Perhaps a note on the docs about this?
Example:
resource "aws_acm_certificate" "default" {
domain_name = "mydomain.com"
validation_method = "DNS"
subject_alternative_names = [
"*.mydomain.com",
"*.cdn.mydomain.com",
"*.assets.cdn.mydomain.com"
]
lifecycle {
create_before_destroy = true
}
}
Output is something like:
Terraform will perform the following actions:
# aws_acm_certificate.default must be replaced
+/- resource "aws_acm_certificate" "default" {
~ arn = "arn:aws:acm:us-east-1:REMOVED:certificate/REMOVED" -> (known after apply)
domain_name = "ott.oly.cloud"
~ domain_validation_options = [REMOVED_AS_NOT_NECESSARY ] -> (known after apply)
~ id = "arn:aws:acm:us-east-1:REMOVED:certificate/REMOVED:REMOVED:certificate" -> (known after apply)
~ subject_alternative_names = [ # forces replacement
+ "*.mydomain.com",
"*.cdn.mydomain.com",
"*.assets.cdn.mydomain.com",
- "*.mydomain.com",
]
~ validation_emails = [] -> (known after apply)
validation_method = "DNS"
}
Plan: 1 to add, 0 to change, 1 to destroy.