A school district's training-data S3 bucket holding student records must be encrypted with a customer-managed key, and only the training role should be able to decrypt objects in that bucket. What should the team configure?
Select an answer to reveal the explanation.
Short Explanation
A key that everyone in the building can turn isn't really locked. Scoping the KMS key policy so only the training role holds decrypt permission keeps the encryption meaningful instead of decorative. Default server-side encryption alone doesn't give you that role-level control.
Full Explanation
A customer-managed KMS key lets the team write a key policy that names exactly which principal — here, the training role — holds decrypt permission, which is the mechanism that satisfies a requirement for role-scoped decryption; the bucket's data stays encrypted, but only the named role can turn it back into plaintext. Default S3-managed server-side encryption does handle encryption at rest, but it doesn't offer the fine-grained, principal-specific decrypt control the requirement asks for — it isn't built around a customer-managed key policy that names a single role. Granting decrypt permission to every role in the account and then relying on the bucket policy for restriction duplicates and weakens the control: the bucket policy governs S3 access, not KMS decrypt permission, so a broad key policy leaves any role with S3 read access and a path to the key able to decrypt the objects. Client-side encryption with the key stored in the same bucket as the encrypted objects defeats the purpose of the control entirely, since anyone who can read the bucket can also read the key. Scope caveat: confirm the training role's own IAM policy also grants it the necessary KMS actions (like Decrypt), since both the key policy and the role's IAM policy need to align for access to actually work. Operational check: attempt to read an object in the bucket using a role other than the training role and confirm decryption fails.