A finance team requires that only a dedicated key-admin role may schedule deletion of a customer managed KMS key used by tax systems, while application roles may only encrypt and decrypt data. Which design best enforces that separation?
Select an answer to reveal the explanation.
Short Explanation
App roles get the “use the lock” permission; only key-admins get the “schedule throwing away the lock” permission. That key-policy split keeps tax crypto users from deleting tomorrow’s keys.
Full Explanation
Finance systems that separate cryptographic use from key destruction need a KMS key policy (and matching IAM permissions) that allows application roles to Encrypt/Decrypt/GenerateDataKey while permitting administrative actions such as ScheduleKeyDeletion only for a dedicated key-admin role. That separation of duties prevents a compromised app role—or a well-meaning developer with broad prod access—from scheduling deletion of the CMK that protects tax data. Key policies are the resource-based gate that make "who may throw away the lock" different from "who may use the lock."
Granting every IAM user kms:* including ScheduleKeyDeletion fails least privilege and collapses the separation model into account-wide superpowers. Storing KMS key material in a public S3 bucket fails the KMS trust model entirely—customer managed keys are not DIY blobs you rotate by uploading files. Disabling key policies and relying on unrestricted account-root equivalence for all staff fails governance; root-like power is for break-glass, not daily tax operations.
Exam caveat: IAM policies and key policies both must allow an action; a key policy allow without IAM allow (or the reverse) results in AccessDenied—design both sides deliberately and avoid kms:* on humans. Operational check: as an app role, encrypt/decrypt a sample tax object successfully; as the same role, attempt ScheduleKeyDeletion and confirm denial; as key-admin, confirm scheduling works and CloudTrail records the administrative event.