using a KMS alias for server_side_encryption_kms_key_arn results in "updating" the key on every apply

[nergdron]

Description

We use KMS key aliases to manage which keys are the current active ones in our infrastructure. However, when using an alias for server_side_encryption_kms_key_arn, either the module or the service replaces it with the ARN of the key the alias points to, and so on every run Terraform thinks it needs to change the key being used, since the underlying key ARN doesn't match the alias we provide.

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

Versions

• Module version [Required]: 4.2.0

• Terraform version: Terraform v1.9.8

• Provider version(s):

+ provider registry.terraform.io/carlpett/sops v1.1.1
+ provider registry.terraform.io/hashicorp/aws v5.74.0
+ provider registry.terraform.io/hashicorp/random v3.6.3

Reproduction Code [Required]

resource "aws_kms_key" "a" {}

resource "aws_kms_alias" "a" {
  name          = "alias/something"
  target_key_id = aws_kms_key.a.key_id
}

module "dynamodb" {
  source = "terraform-aws-modules/dynamodb-table/aws"

  name                        = "dynamo-table"
  hash_key                    = "id"
  deletion_protection_enabled = true

  server_side_encryption_enabled     = true
  server_side_encryption_kms_key_arn = resource.aws_kms_alias.a.arn

  attributes = [
    {
      name = "id"
      type = "N"
    }
  ]
}

Steps to reproduce the behavior:

• used terraform-aws-dynamodb-table module configured with a KMS key alias to deploy a table.
• ran terraform apply again, and saw that the state showed the base key ARN, not the alias ARN, and wanted to replace the key used even though they're actually the same key under the hood.

Expected behavior

terraform state contained the alias ARN, not the underlying key ARN, and so correctly showed that no configuration update was necessary.

Actual behavior

See "Steps to reproduce behaviour" above.

Additional context

This is the first module from terraform-aws-modules I've encountered that has this issue, other ones such as sqs, s3-bucket, and elasticache correctly keep the alias intact. this makes me think this might just be an issue with the dynamodb service and it is the place the key is getting forcibly converted from alias to underlying key ARN, in which case there's not much to be done. but if it's something that can be fixed in this module, that'd be extremely helpful for me.