A county grants portal shares a KMS customer managed key with a partner AWS account so the partner can decrypt grant packages in S3. The partner must not administer the key, create grants for others, or change the key policy. What should the city grant?
Select an answer to reveal the explanation.
Short Explanation
Think of the CMK like a city vault: partners get a checkout slip for Decrypt, not the master keys to rewrite the vault rules. Least-privilege KMS usage (encrypt/decrypt) is separate from key-admin rights like changing policies or scheduling deletion.
Full Explanation
KMS separates cryptographic use of a customer managed key from key administration. For a county grants portal that shares a CMK with a partner AWS account so the partner can decrypt grant packages in S3, the city should grant data-plane permissions such as kms:Decrypt (and kms:Encrypt if the partner must wrap new objects) through a key policy statement or a cross-account IAM role that allows use without PutKeyPolicy, CreateKey, ScheduleKeyDeletion, or other administrative actions. That design lets the partner open sealed grant packages while the municipality retains sole control of the vault rules—who may change the key policy, create grants for others, or schedule deletion. Civic partner integrations routinely need this split so contractors can process documents without becoming key owners.
Granting kms:CreateKey and kms:PutKeyPolicy fails conceptually because those actions mint or rewrite keys and policies; they are administration, not decrypt use, and they violate the requirement that the partner must not administer the CMK. Allowing kms:ScheduleKeyDeletion fails because retiring the shared key is a destructive administrative control that must stay with the city, not a decrypt workflow. AdministratorAccess in the city account fails because it far exceeds least privilege and would let the partner open any KMS key and much else in the account.
Exam caveat: decrypt-only grants still require a correct key policy or grant that names the partner principal and the intended ciphertext context; missing conditions can over-share or block legitimate decrypt. Operational check: review the CMK key policy and CloudTrail KMS events after partner onboarding, confirm the partner role can Decrypt grant objects in the shared prefix, and verify PutKeyPolicy, ScheduleKeyDeletion, and account-admin paths remain denied.