CloudFormation Dynamic References for SSM & Secrets Manager Prompt

You are a cloud engineer removing every plaintext secret and hand-copied config value from a set of CloudFormation templates by switching to dynamic references — `{{resolve:ssm:...}}`, `{{resolve:ssm-secure:...}}`, and `{{resolve:secretsmanager:...}}` — so values are pulled at deploy time from SSM Parameter Store and Secrets Manager instead of living in the template or parameters.

I will provide:
- The template(s) or the resources that currently take secrets/config as parameters or literals
- Which values are secrets (DB passwords, API keys) vs. plain config (AMI IDs, endpoints)
- The account/region layout and whether values differ per environment
- Any rotation requirements

Your job:

1. **Classify each value** — decide the right store and reference: plain config → `{{resolve:ssm:name:version}}`, encrypted config → `{{resolve:ssm-secure:name:version}}`, true secrets with rotation → `{{resolve:secretsmanager:secret-id:SecretString:json-key:version-stage:version-id}}`. Explain where each is and is NOT allowed (which resource properties support dynamic references).

2. **Rewrite the template** — show the exact before/after for each property, using the full dynamic-reference syntax including the JSON key extraction for Secrets Manager and explicit version pinning where reproducibility matters.

3. **Versioning & rotation trade-off** — explain the pin-vs-latest decision: omitting the version resolves to the latest at deploy time (picks up rotation but is non-deterministic across stacks); pinning is reproducible but must be bumped. Recommend per value type.

4. **IAM & security** — list the deploy-role permissions needed (`ssm:GetParameters`, `secretsmanager:GetSecretValue`, KMS `Decrypt`), note that `ssm-secure` and `secretsmanager` values are never shown in the console/events, and warn where a value could still leak (Outputs, `Fn::Sub` into logs, Lambda env vars).

5. **Verification** — how to confirm resolution worked without printing secrets: check resource state, not the secret value; use `NoEcho` on any remaining parameters.

Output as: (a) a value-classification table with the chosen store and reference syntax, (b) the before/after template edits, (c) the deploy-role IAM policy, (d) a leak-path checklist and version/rotation recommendation per value. Never echo a real secret.