SAA-C03 Design Secure Architectures Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✓

  Update key-K’s key policy in account 3000 to allow kms:Decrypt for the specific role principal in account 4000.

  Why this is correct

  For customer-managed KMS keys, key policy is a required authorization layer. Even with an IAM identity policy granting kms:Decrypt, KMS will deny the request unless the key policy also authorizes the calling principal to use the key for Decrypt.

• ✗

  Update the S3 bucket policy to allow kms:Decrypt for account 4000 principals on key-K.

  Why it's wrong here

  An S3 bucket policy only authorizes S3 data-plane actions (e.g., s3:GetObject); it is not an authorization source that KMS evaluates. When S3 calls KMS to decrypt an object's envelope-encrypted data key, KMS checks the key policy, an IAM policy attached to the calling principal, and any grants — never the bucket policy. Consequently, adding kms:Decrypt to the bucket policy would be ignored by KMS and the AccessDenied error would persist. Correct remediation must be made in the KMS key policy itself.

• ✗

  Enable AWS managed key rotation on key-K and remove the existing key policy.

  Why it's wrong here

  Enabling key rotation for key-K merely schedules new cryptographic material to be generated for the backing key; it does not create permissions or change who is allowed to call kms:Decrypt. Removing the existing key policy would strip all authorization for the key, causing every caller — including account 3000's own principals — to lose access unless a separate policy grants them. Key rotation never substitutes for an authorization policy, so this action would not resolve the cross-account AccessDenied and would likely make the situation worse.

• ✗

  Switch the access from a role to an IAM user because KMS only supports user principals.

  Why it's wrong here

  This is incorrect because KMS does support IAM role principals; it explicitly accepts AWS account principals, IAM users, IAM roles, and federated principals in key policies. Switching from a role to an IAM user would not bypass KMS's authorization requirements — the new user principal would still need an explicit allow for kms:Decrypt in key-K's key policy. The observed AccessDenied is a classic symptom of a missing key policy grant for a valid principal, not a limitation on principal type.

Go deeper

Related to this question