A county encrypts tax data with AWS KMS and must separate key administrators from key users while enabling automatic key rotation where appropriate. Which design should the architect prescribe?
Select an answer to reveal the explanation.
Short Explanation
The locksmith who cuts city keys should not be the same crew that opens every tax drawer all day. KMS key policies split admins from users, and automatic rotation refreshes eligible symmetric CMKs. Handing clerks delete/policy powers, skipping encryption, or parking a plaintext master key undoes the whole point.
Full Explanation
County tax-data encryption with AWS KMS should use customer managed keys whose key policies and IAM permissions separate key administrators from key users, and should enable automatic annual rotation on eligible symmetric CMKs. Administrators may manage policies and rotation without broad decrypt rights on production tax ciphertexts; application roles encrypt/decrypt without ScheduleKeyDeletion or PutKeyPolicy. That separation of duties plus rotation matches financial-data key-management hygiene.
Giving every tax clerk kms:ScheduleKeyDeletion and kms:PutKeyPolicy collapses admin and user roles and invites accidental or malicious key destruction. Disabling encryption to avoid key-management complexity and relying on VPC isolation alone abandons at-rest protection for tax data. Storing a single plaintext master key in Parameter Store as a non-SecureString shared by all applications bypasses KMS entirely and exposes the master secret.
Exam caveat: automatic rotation applies to eligible symmetric CMKs; asymmetric and imported key material have different rules—read the stem’s “automatic rotation where appropriate” cue. Operational check: create CMKs with split admin/user principals, enable rotation, encrypt a tax table or S3 prefix, prove clerks cannot delete keys or rewrite key policies, and audit KMS API calls in CloudTrail.