A healthcare company stores PHI in S3 and RDS and faces an audit requiring customer-controlled encryption at rest with annual key rotation and centralized key audit trails. AWS managed keys are no longer sufficient. Which encryption at rest design using customer managed keys and rotation should the architect implement?

The correct design satisfies all constraints at once because customer managed keys deliver customer control over key policy, grants and disablement, automatic rotation provides annual cryptographic refresh without re-encrypting data, enforcement on both S3 with SSE-KMS defaults and RDS with KMS encryption ensures uniform PHI coverage, and an organization CloudTrail trail centralizes KMS usage for audit review. The SSE-S3 with service-default encryption fails on ownership since AWS retains key management, so although encryption, rotation and central logging appear sound it cannot prove customer control or custom policy required when AWS managed keys are deemed insufficient. The manual three-year rotation fails on lifecycle since retaining key material for multiple years violates the annual rotation mandate and widens exposure, so despite correct ownership, coverage and auditing it triggers a compliance finding. The separate per-service logging fails on governance since dispersing Decrypt and GenerateDataKey events across isolated logs prevents unified retention, search and tamper-evident review expected from centralized key audit trails. Exam caveat is to distinguish SSE-S3 and default RDS encryption as AWS managed from SSE-KMS with customer managed keys, and remember KMS automatic rotation defaults to 365 days and can be configured between 90 and 2,560 days, so the annual period should be confirmed rather than assumed. Practical check is to describe-key rotation status, verify bucket defaults and RDS encryption with the correct key ARNs via Config rules, and query the organization trail for cross-account KMS events.