SAA-C03 Design Secure Architectures Practice Question
You use a customer managed AWS KMS key (CMK) to encrypt objects in an S3 bucket using SSE-KMS. A specific IAM role must be able to decrypt objects. Where should you grant kms:Decrypt permissions so that the role can decrypt data encrypted with that CMK?
⚠ Common exam trap
It's easy for candidates to assume S3 bucket policies or IAM identity policies alone are sufficient for decryption, forgetting that KMS enforces its own authorization layer and the key policy is the gatekeeper for all KMS operations.
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
✓
In the KMS key policy, allowing kms:Decrypt (and any other required KMS permissions) for the role’s principal ARN.
When using a customer managed KMS key (CMK) with SSE-KMS, the KMS key policy is the primary access control mechanism. To allow a specific IAM role to decrypt objects, you must grant kms:Decrypt (and typically kms:DescribeKey) in the key policy for that role's principal ARN. Without this explicit permission in the key policy, the role will be denied decryption even if it has s3:GetObject permissions, because KMS enforces its own authorization.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
In the KMS key policy, allowing kms:Decrypt (and any other required KMS permissions) for the role’s principal ARN.
Why this is correct
With SSE-KMS, KMS decryption is authorized by KMS for the specific CMK. The CMK key policy is a primary authorization layer; if the key policy does not allow kms:Decrypt for the role (or a matching principal), S3 requests that require KMS decryption will fail even if the S3 or IAM identity policies allow s3:GetObject.
- ✗
Only in the S3 bucket policy by granting s3:GetObject, because S3 bucket policy controls decryption.
Why it's wrong here
S3 bucket policies govern S3 control-plane and data-plane operations such as s3:GetObject for retrieving the object, but they have no authority over KMS actions. When an object is encrypted with SSE-KMS, S3 invokes KMS to decrypt the data key on the caller's behalf, and KMS authorizes that call by evaluating the key policy and the caller's IAM policies against the kms:Decrypt action. Granting only s3:GetObject in the bucket policy gives the caller access to the encrypted ciphertext but does not allow KMS to decrypt it, so the GetObject request fails if the role lacks the necessary KMS permissions.
When this WOULD be correct
In a scenario where the question asks how to grant access to decrypt objects encrypted with SSE-S3 (not SSE-KMS) or when the question specifies that the CMK's key policy already allows the account root and the role has an IAM policy granting kms:Decrypt, then the answer would focus on S3 bucket policy for s3:GetObject.
- ✗
Only in the IAM role identity policy; the KMS key policy does not need changes for SSE-KMS.
Why it's wrong here
For customer-managed keys, a restrictive CMK key policy can deny or omit access. In that case, identity-policy kms:Decrypt permission alone is insufficient because the key policy is also evaluated and must allow the role to use the key for decryption.
When this WOULD be correct
This would be correct if the question asked about granting permissions to decrypt objects encrypted with SSE-S3 (not SSE-KMS), where S3 manages the encryption keys and no KMS permissions are needed. In that case, only S3 bucket policy or IAM policy granting s3:GetObject is required.
- ✗
By enabling S3 default encryption; KMS permissions are automatically granted to all IAM roles in the account.
Why it's wrong here
Enabling S3 default encryption only configures the encryption applied to newly written objects; it is a write-time bucket setting that does not modify the customer-managed CMK's key policy or grant any IAM principal permissions to call kms:Decrypt. Even if default encryption is enabled, KMS evaluates each decryption request independently against the key policy, so roles attempting to read objects must be separately authorized to use that CMK. Without explicit kms:Decrypt permission in the key policy, or a matching IAM policy that the key policy allows, S3 GetObject requests will fail with an AccessDenied error.
When this WOULD be correct
If the question asked about using SSE-S3 (AES-256) with S3 default encryption, then no KMS permissions are needed, and the bucket policy or IAM policy would control access to the objects.
Option-by-option analysis
Why each answer is right or wrong
Understanding why wrong answers are wrong — and when they would be correct — is what separates a 750 score from a 900. The SAA-C03 exam frequently reuses these exact scenarios with slightly different constraints.
✓In the KMS key policy, allowing kms:Decrypt (and any other required KMS permissions) for the role’s principal ARN.Correct answer▾
Why this is correct
With SSE-KMS, KMS decryption is authorized by KMS for the specific CMK. The CMK key policy is a primary authorization layer; if the key policy does not allow kms:Decrypt for the role (or a matching principal), S3 requests that require KMS decryption will fail even if the S3 or IAM identity policies allow s3:GetObject.
✗Only in the S3 bucket policy by granting s3:GetObject, because S3 bucket policy controls decryption.Wrong answer — click to see why▾
Why this is wrong here
S3 bucket policies control S3 actions like s3:GetObject, but they cannot grant KMS permissions. Decrypting SSE-KMS objects requires explicit kms:Decrypt permission on the CMK, which must be granted via the KMS key policy or an IAM policy that the key policy allows.
★ When this WOULD be the correct answer
In a scenario where the question asks how to grant access to decrypt objects encrypted with SSE-S3 (not SSE-KMS) or when the question specifies that the CMK's key policy already allows the account root and the role has an IAM policy granting kms:Decrypt, then the answer would focus on S3 bucket policy for s3:GetObject.
Why candidates choose this
Candidates may mistakenly think that S3 bucket policies are sufficient for all aspects of S3 access, including decryption, and overlook that SSE-KMS requires separate KMS permissions.
✗Only in the IAM role identity policy; the KMS key policy does not need changes for SSE-KMS.Wrong answer — click to see why▾
Why this is wrong here
The KMS key policy must explicitly grant kms:Decrypt to the IAM role; without it, the role cannot decrypt objects even if it has an IAM policy allowing kms:Decrypt, because KMS key policies control access to the CMK and can override IAM policies.
★ When this WOULD be the correct answer
This would be correct if the question asked about granting permissions to decrypt objects encrypted with SSE-S3 (not SSE-KMS), where S3 manages the encryption keys and no KMS permissions are needed. In that case, only S3 bucket policy or IAM policy granting s3:GetObject is required.
Why candidates choose this
Candidates may think that IAM policies alone are sufficient for all AWS services, forgetting that KMS uses a resource-based policy (key policy) that must explicitly allow access, especially when the key is in a different account or when the key policy denies default IAM access.
✗By enabling S3 default encryption; KMS permissions are automatically granted to all IAM roles in the account.Wrong answer — click to see why▾
Why this is wrong here
Enabling S3 default encryption does not automatically grant KMS permissions to IAM roles; you must explicitly grant kms:Decrypt in the key policy or IAM policy for the role to decrypt objects encrypted with a customer managed CMK.
★ When this WOULD be the correct answer
If the question asked about using SSE-S3 (AES-256) with S3 default encryption, then no KMS permissions are needed, and the bucket policy or IAM policy would control access to the objects.
Why candidates choose this
Candidates may mistakenly think that S3 default encryption automatically handles all permissions for decryption, overlooking that SSE-KMS requires explicit KMS key permissions separate from S3 actions.
Analysis generated from the official SAA-C03blueprint and verified against question context. The “when correct” sections are what AI assistants cite when candidates ask “what’s the difference between these options?”
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
Related to this question
About these practice questions
Courseiva writes every SAA-C03 question from scratch — 935 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This SAA-C03 practice question is part of Courseiva's free Amazon Web Services certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the SAA-C03 exam.