SAA-C03 Design Secure Architectures Practice Question

Exhibit

S3 bucket policy in Account A:
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {"AWS": "arn:aws:iam::222233334444:role/AppReadRole"},
      "Action": ["s3:GetObject"],
      "Resource": "arn:aws:s3:::finance-archive/*"
    }
  ]
}

KMS key policy for key arn:aws:kms:us-east-1:111122223333:key/abcd-1111:
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {"AWS": "arn:aws:iam::111122223333:root"},
      "Action": "kms:*",
      "Resource": "*"
    }
  ]
}

Application IAM policy in Account B:
{
  "Effect": "Allow",
  "Action": ["s3:GetObject"],
  "Resource": "arn:aws:s3:::finance-archive/*"
}

Based on the exhibit, an application role in Account B can reach an S3 bucket in Account A, but reads fail with AccessDenied on KMS. The bucket objects use SSE-KMS with a customer managed key in Account A. What change is required so the application can decrypt the objects while keeping the access restricted?

⚠ Common exam trap

The trap here is that candidates often focus only on the S3 bucket policy or IAM permissions, forgetting that SSE-KMS with a customer managed key requires explicit cross-account grants in the KMS key policy, not just in S3 or IAM policies.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

Add the Account B role ARN to the KMS key policy with kms:Decrypt and kms:DescribeKey permissions, scoped to S3 usage in us-east-1.

When using SSE-KMS with a customer managed key, cross-account access requires the KMS key policy to explicitly grant the external IAM role (from Account B) the kms:Decrypt and kms:DescribeKey permissions. Without these, S3 can retrieve the encrypted object, but KMS will deny the decryption request, resulting in an AccessDenied error. Scoping the policy to S3 usage in us-east-1 follows the principle of least privilege while enabling the necessary decryption.

Answer analysis

Option-by-option breakdown

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

✓
Add the Account B role ARN to the KMS key policy with kms:Decrypt and kms:DescribeKey permissions, scoped to S3 usage in us-east-1.
Why this is correct
S3 object retrieval with SSE-KMS requires that KMS authorize decryption, and that authorization must exist in the key policy for a CMK in another account. Scoping the statement to the specific role and S3 usage keeps the access narrow while allowing the object read to succeed.
✗
Add s3:GetEncryptionConfiguration to the Account B IAM policy so S3 can use the customer managed key on reads.
Why it's wrong here
There is no permission called s3:GetEncryptionConfiguration for this read path, and S3 does not use such an action to decrypt SSE-KMS objects. The failure occurs at KMS authorization time, not because the IAM role lacks an S3 encryption configuration permission.
✗
Change the bucket to SSE-S3 because SSE-S3 always allows cross-account reads without any KMS policy changes.
Why it's wrong here
Switching to SSE-S3 may avoid CMK policy management, but it changes the security model and is not the least disruptive fix. The scenario explicitly uses SSE-KMS with a customer managed key and asks how to keep the access restricted while restoring decryption.
✗
Add the Account B role to the bucket ACL with FULL_CONTROL so S3 can bypass KMS on behalf of the reader.
Why it's wrong here
Bucket ACLs do not grant KMS decrypt permissions and cannot bypass SSE-KMS authorization. Even if S3 access were granted at the bucket level, the key policy must still authorize decrypt operations for the encrypted objects to be returned.

Quick reference

AWS S3 Storage Class Comparison

Storage Class	Min Duration	Retrieval	Use Case
S3 Standard	None	Immediate	Frequently accessed data
S3 Standard-IA	30 days	Immediate	Infrequent access, rapid retrieval
S3 One Zone-IA	30 days	Immediate	Non-critical infrequent data
S3 Intelligent-Tiering	None	Immediate–hours	Unknown or changing access patterns
S3 Glacier Instant	90 days	Milliseconds	Archive with instant retrieval
S3 Glacier Flexible	90 days	Minutes–hours	Archive, flexible retrieval
S3 Glacier Deep Archive	180 days	Hours	Long-term compliance archive

Go deeper

SAA-C03 Design Secure Architectures Practice Question

Exhibit

Why each option matters

Option-by-option breakdown

AWS S3 Storage Class Comparison

Related to this question