Unexpected Attributes in CloudFront Distribution Plan

[deepakraajesh]

Description

I am currently working with the terraform-aws-cloudfront module and encountered an issue while updating the CloudFront distribution with a response headers policy. Here’s the exact workflow I followed:

1.	I have a CloudFront distribution deployed via Terraform, using module version `v2.7.0`.
2.	I needed to apply a `response_headers_policy` in the CloudFront behavior. I noticed that this feature was introduced in module version `v2.9.0`.
3.	I updated to version `v2.9.0` and attempted to add the following resources:

provider "aws" {
  alias   = "cdn"
  version = "~> 3.0"
}

resource "aws_cloudfront_response_headers_policy" "cache_control_policy" {
  name     = "Cache-Control-Policy"
  provider = aws.cdn
  custom_headers_config {
    items {
      header   = "Cache-Control"
      override = true
      value    = "max-age=3600"
    }
  }
}

module "cdn_new" {
  source  = "terraform-aws-modules/cloudfront/aws"
  version = "2.9.0"
  providers = {
    aws = aws.cdn
  }
  ..................
  ordered_cache_behavior = [
    {
    ....
      response_headers_policy_id = aws_cloudfront_response_headers_policy.cache_control_policy.id
    ....
    }
  ]
}
....................

• [✅] ✋ I have searched the open/closed issues and my issue is not listed.

Versions

• Module version [Required]: v2.9.0
• Terraform version: v0.13.5
• Provider version(s): ~> 3.0

Reproduction Code [Required]

In the existing CloudFront module, try adding the response_headers_policy_id in the ordered_cache_behavior or default_cache_behavior along with the custom response header policy. This will result in unintended changes that we have not provided in the Terraform code.

However, if you break the steps into two: • Apply the policy first • Add the response_headers_policy_id in the cache_behavior You will not observe this issue.

Steps to reproduce the behavior:

Yes Yes

Expected behavior

When applying the above configuration, I expect the following changes:

# aws_cloudfront_response_headers_policy.cache_control_policy will be created
+ resource "aws_cloudfront_response_headers_policy" "cache_control_policy" {
  + etag = (known after apply)
  + id   = (known after apply)
  + name = "Cache-Control-Policy"
  
  + custom_headers_config {
    + items {
      + header   = "Cache-Control"
      + override = true
      + value    = "max-age=3600"
    }
  }
}

# module.cdn_new.aws_cloudfront_distribution.this[0] will be updated in-place
~ resource "aws_cloudfront_distribution" "this" {
  ~ ordered_cache_behavior {
    + response_headers_policy_id = "<policy_id_here>"
  }
}

Plan: 1 to add, 1 to change, 0 to destroy.

Actual behavior

However, the actual behavior I observed is:

# aws_cloudfront_response_headers_policy.cache_control_policy will be created
+ resource "aws_cloudfront_response_headers_policy" "cache_control_policy" {
  + etag = (known after apply)
  + id   = (known after apply)
  + name = "Cache-Control-Policy"
  
  + custom_headers_config {
    + items {
      + header   = "Cache-Control"
      + override = true
      + value    = "max-age=3600"
    }
  }
}

# module.cdn_new.aws_cloudfront_distribution.this[0] will be updated in-place
~ resource "aws_cloudfront_distribution" "this" {
  ~ ordered_cache_behavior {
    ~ allowed_methods           = ["GET", "HEAD", "OPTIONS"] -> (known after apply)
    + cache_policy_id           = (known after apply)
    ~ cached_methods            = ["GET", "HEAD"] -> (known after apply)
    + field_level_encryption_id = (known after apply)
    + origin_request_policy_id  = (known after apply)
    + realtime_log_config_arn   = (known after apply)
    ~ smooth_streaming          = false -> (known after apply)
    + function_association {
      + event_type   = (known after apply)
      + function_arn = (known after apply)
    }
    + lambda_function_association {
      + event_type   = (known after apply)
      + include_body = (known after apply)
      + lambda_arn   = (known after apply)
    }
  }
}

Plan: 1 to add, 1 to change, 0 to destroy.

Unexpectedly, attributes such as `field_level_encryption_id`, `cache_policy_id`, `realtime_log_config_arn`, `function_association`, and `lambda_function_association` are being added, although I did not provide any values for them.

Workaround:

To achieve the expected behavior, I had to apply the following workaround:

1.	I first created the `aws_cloudfront_response_headers_policy` resource without adding `response_headers_policy_id` in the `ordered_cache_behavior`.
2.	Once the `aws_cloudfront_response_headers_policy` was created, I added the `response_headers_policy_id` to the `ordered_cache_behavior` using `aws_cloudfront_response_headers_policy.cache_control_policy.id`.

After this, Terraform applied the changes correctly without adding the unexpected attributes.

Questions:

1.	Why are these additional fields (`field_level_encryption_id`, `cache_policy_id`, `realtime_log_config_arn`, etc.) being included in the plan even though they weren’t specified?
2.	Is there a way to resolve this issue without having to apply the workaround and run the plan twice?

I would appreciate any guidance on how to prevent this and if it’s a bug in the module or the provider itself.

Thank you for your help!

[ghost]

I just applied the changes. Terraform didn't add those changes.

[github-actions[bot]]

This issue has been automatically marked as stale because it has been open 30 days with no activity. Remove stale label or comment or this issue will be closed in 10 days

[github-actions[bot]]

This issue has been automatically marked as stale because it has been open 30 days with no activity. Remove stale label or comment or this issue will be closed in 10 days

[github-actions[bot]]

This issue was automatically closed because of stale in 10 days

[github-actions[bot]]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.