Blog · Terraform

Importing AWS Secrets Manager without clobbering live creds

If you use ignore_secret_changes=true, you must import both the secret and its version resource. Or the first apply silently overwrites the running password.

Posted 2026-04-30 · Terraform / Terragrunt / AWS Secrets Manager

The pattern

You're adopting the terraform-aws-modules/secrets-manager module for an existing AWS Secrets Manager secret whose value was set out-of-band -- maybe rotated by a different system, maybe injected by a CI job. You set ignore_secret_changes = true so Terraform won't trample the live value on every apply.

The trap

If you only terraform import the secret itself, Terraform still creates a brand-new aws_secretsmanager_secret_version resource on first apply -- using the placeholder secret_string from your module input. ignore_secret_changes protects you on subsequent runs; it does not protect you on the first.

Net effect: your first apply overwrites the live credential with the placeholder, and your dependent service immediately starts failing auth. We have seen this happen. It is unpleasant.

The fix

Import both resources, not just one:

# the secret
terragrunt import module.secret.aws_secretsmanager_secret.this[0] arn:aws:secretsmanager:us-east-1:...:secret:my-secret-XXXXXX

# the version too
terragrunt import module.secret.aws_secretsmanager_secret_version.this[0] arn:aws:secretsmanager:us-east-1:...:secret:my-secret-XXXXXX|AWSCURRENT

The workflow we use

  1. Open the import PR.
  2. Run the imports in a single region first.
  3. Confirm plan is a clean no-op.
  4. terragrunt state rm both resources so the real import runs on merge in CI.
  5. Merge. Watch CI re-import cleanly. Move on to the remaining regions.

Same convention works for any module that pairs an "outer" resource with version / config siblings -- IAM policy versions, Lambda code, etc.

← Back to blog

Talk to an engineer →