Municipal app config currently hard-codes raw KMS key IDs. Operators want rotations and re-pointing without hunting every service for ARNs. What practice helps?
Select an answer to reveal the explanation.
Short Explanation
A KMS alias is the labeled hook on the wall—point services at alias/city-pii and rehang the key when you rotate or swap. Hard-coding raw key IDs everywhere turns every change into a scavenger hunt. Cleartext keys in env vars are worse.
Full Explanation
Applications should reference a KMS alias in configuration rather than scattering raw key IDs or full ARNs through every Lambda. Operators can re-point the alias to a new CMK during rotations or environment promotions without hunting every service for hardcoded key identifiers. Aliases provide a stable indirection for municipal platforms that must rotate keys under policy.
Hard-coding full key ARNs in every Lambda and refusing aliases maximizes toil on each rotation. Storing plaintext copies of every CMK in Secrets Manager under the name “alias” misunderstands both aliases and secret storage—CMK private material is not exported that way. Disabling KMS and embedding encryption keys as cleartext environment variables recreates the secret-sprawl problem aliases help avoid.
Exam caveat: aliases are per-account/region pointers; update alias targets carefully and ensure new keys’ policies still allow the same application roles before cutting over. Operational check: configure a service to encrypt via alias/city/case-cmk, re-point the alias to a newly created CMK in a lab, confirm the service encrypts/decrypts without code changes, and grep repos for raw key IDs that should become aliases.