What this prompt does
This prompt casts the AI as a senior cloud security engineer and asks it to return working Terraform HCL for storing application secrets in AWS Secrets Manager. Instead of vague advice, it forces a concrete pattern: secrets generated inside Terraform, rotation wired through a Lambda, IAM scoped to least privilege, and a KMS key to encrypt everything. The framing "return working HCL, not pseudocode" pushes the model past hand-waving and into code you can actually terraform plan.
The four placeholders steer the output to your environment. [consuming_services] tells the model which principals get read/decrypt IAM (so the policy isn't a wildcard), [rotation_cadence] sets the rotation schedule on the Lambda, [kms_strategy] decides whether you get a shared key or a dedicated customer-managed key per environment, and [current_secret_state] shapes the migration path — moving off a committed .env looks different from moving off SSM Parameter Store.
When to use it
- You inherited an app where secrets live in a committed
.envand need them out of source control safely. - You're standing up a new AWS service and want secrets, rotation, and IAM wired in one pass.
- You need least-privilege IAM scoped to specific consumers instead of a broad
secretsmanager:*policy. - You want automated rotation but aren't sure how to structure the Lambda rotation function in Terraform.
- You're setting up a dedicated KMS key per environment and need the key policy written correctly.
- You need a documented cutover and rollback plan before touching production secrets.
Example output
Expect two things: a set of HCL blocks and a written runbook. The HCL covers aws_secretsmanager_secret, a random_password resource so plaintext never enters your config, a rotation schedule pointing at a Lambda, scoped IAM policy documents, and a KMS key with rotation enabled. The runbook walks the migration from [current_secret_state] through cutover, a first rotation test, and a rollback step. It also includes guidance on reading secrets at runtime rather than baking them into images or Terraform state.
Pro tips
- Fill
[consuming_services]precisely — "ECS tasks and a Lambda API" produces tighter IAM than "my backend." Vague consumers give you vague policies. - Watch deliverable 1: never pass a plaintext secret through a Terraform variable. It lands in state. Always generate (via
random_password) or inject it out-of-band. - Set
[rotation_cadence]to a real number like "every 30 days, automated" so the model configures an actual schedule, not a placeholder comment. - For
[kms_strategy], a dedicated customer-managed key per environment costs a little more but isolates blast radius — say so explicitly if that's what you want. - After generating, run the first rotation test from the runbook in a non-prod account before trusting it in production.
- If your state file is local, fix that first — secrets in remote encrypted state with locking is the baseline this pattern assumes.
