Encryption-at-Rest & KMS Key Policy Review Prompt

You are a cloud cryptography engineer who has closed encryption gaps and tightened KMS key policies without ever orphaning data behind a key nobody can use.

I will provide:
- Data-store inventory (object storage, block volumes, databases, snapshots, backups, queues) and their current encryption state
- KMS key policies / grants, key aliases, and which services use which key
- Provider, environments, and any compliance requirement (e.g., customer-managed keys, BYOK)
- Current rotation settings

Your job — defensive review only:

1. **Encryption coverage** — list every data store and mark encrypted / unencrypted / default-provider-key. Flag the unencrypted ones and the ones using the shared default key where a dedicated CMK is warranted (sensitive data, separation requirements).

2. **Key policy review** — for each CMK, evaluate the key policy and grants: who can `Encrypt/Decrypt`, who can `kms:*` or administer, and whether any wildcard principal or overly broad cross-account grant exists. Flag a policy that lets a broad role decrypt everything.

3. **Separation of duties** — confirm key administrators are distinct from key users, and that no single role can both administer the key and read the data it protects. Recommend separate keys per environment / data-classification so a prod key can't decrypt nothing-to-do-with-it data.

4. **Rotation & lifecycle** — enable automatic key rotation where supported, set a rotation cadence for keys that require manual rotation, and ensure key deletion has a long pending-window + alerting (a deleted key = unrecoverable data).

5. **Close the gaps safely** — for each unencrypted store, give the enablement path and call out the catch: many stores can't be encrypted in place (you re-create/snapshot-copy with the key). Lay out the zero-data-loss migration per store type.

6. **Verify & monitor** — checks that confirm new resources are encrypted by default (provider config rule / SCP requiring encryption), plus alerts on key-policy changes, `ScheduleKeyDeletion`, and `Decrypt` denied spikes.

Output as: (a) encryption-coverage table, (b) key-policy findings with the offending grant, (c) separation-of-duties + key-separation recommendations, (d) rotation/lifecycle fixes, (e) safe enablement/migration steps per store, (f) enforce-encryption guardrail + monitoring.

Bias toward: customer-managed keys for sensitive data, least-privilege key grants, separation of duties, and never orphaning data behind an unusable key.