CLF-C02 Security and Compliance Practice Question
A company uses an IAM role to allow an application running on Amazon EC2 to decrypt data stored in Amazon S3. The security team wants to enforce that the application can only use the decryption permission when the IAM role has a specific tag (e.g., 'Environment=Production'). Which approach should the security team implement to meet this requirement?
⚠ Common exam trap
Many candidates confuse which policy document (IAM policy vs. key policy vs. bucket policy) and which condition key (PrincipalTag vs. RequestTag) is appropriate for restricting actions based on the caller's tags.
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 a condition to the IAM policy that grants the 'kms:Decrypt' permission with a condition on 'aws:PrincipalTag' to require the tag.
The condition key 'aws:PrincipalTag' in an IAM policy allows you to control access based on tags attached to the IAM principal (the role). By adding a condition that requires 'aws:PrincipalTag/Environment' to equal 'Production', the 'kms:Decrypt' permission is only effective when the IAM role has that specific tag. This directly enforces the security team's requirement at the IAM policy level, which is the appropriate place to restrict permissions based on principal attributes.
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 a condition to the KMS key policy that uses the 'kms:RequestTag/ConditionKey' to require the tag on the caller.
Why it's wrong here
Incorrect. KMS key policies use condition keys such as 'kms:EncryptionContext' or 'kms:ViaService', but not 'kms:RequestTag/ConditionKey' for principal tags. Principal tags are checked using 'aws:PrincipalTag' in the key policy, but this is not the most straightforward approach and the key policy alone cannot enforce this if the IAM policy also grants permission. Moreover, the option uses an incorrect condition key name.
When this WOULD be correct
If the requirement were to enforce that the KMS API request itself includes a specific tag (e.g., to track usage or enforce tagging policies on decryption requests), then using 'kms:RequestTag' in the key policy would be correct.
- ✗
Add a condition to the IAM role's trust policy that denies the 'kms:Decrypt' action unless the role has the tag.
Why it's wrong here
Incorrect. A role's trust policy controls which principals can assume the role, not what actions the role can perform. The trust policy cannot directly limit the decryption permissions of the role. The permissions are governed by the IAM policy attached to the role.
When this WOULD be correct
If the requirement were to restrict which principals (users or services) can assume the IAM role based on a tag (e.g., only allow EC2 instances with a specific tag to assume the role), then adding a condition on 'aws:PrincipalTag' in the trust policy would be correct.
- ✓
Add a condition to the IAM policy that grants the 'kms:Decrypt' permission with a condition on 'aws:PrincipalTag' to require the tag.
Why this is correct
Correct. IAM policies support the 'aws:PrincipalTag' condition key, which checks the tags attached to the IAM principal (user or role) making the request. By adding a condition like 'StringEquals': {'aws:PrincipalTag/Environment': 'Production'} to the IAM policy that grants 'kms:Decrypt', the decryption action is only allowed when the role has the specified tag. This is a form of attribute-based access control (ABAC).
- ✗
Add a condition to the S3 bucket policy that denies all access unless the IAM role has the required tag.
Why it's wrong here
Incorrect. An S3 bucket policy controls access to S3 actions (like s3:GetObject), but it does not control the KMS decrypt action. Even if the bucket policy allows access, the application still needs explicit permission to use the KMS key. Additionally, S3 bucket policies can use 'aws:PrincipalTag' conditions, but that would only affect S3 API calls, not the decryption operation.
When this WOULD be correct
If the requirement were to restrict access to S3 objects based on the IAM role's tag (e.g., only allow read access when the role has 'Environment=Production'), then adding a condition to the S3 bucket policy using 'aws:PrincipalTag' would be correct.
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 CLF-C02 exam frequently reuses these exact scenarios with slightly different constraints.
✓Add a condition to the IAM policy that grants the 'kms:Decrypt' permission with a condition on 'aws:PrincipalTag' to require the tag.Correct answer▾
Why this is correct
Correct. IAM policies support the 'aws:PrincipalTag' condition key, which checks the tags attached to the IAM principal (user or role) making the request. By adding a condition like 'StringEquals': {'aws:PrincipalTag/Environment': 'Production'} to the IAM policy that grants 'kms:Decrypt', the decryption action is only allowed when the role has the specified tag. This is a form of attribute-based access control (ABAC).
✗Add a condition to the KMS key policy that uses the 'kms:RequestTag/ConditionKey' to require the tag on the caller.Wrong answer — click to see why▾
Why this is wrong here
The condition 'kms:RequestTag/ConditionKey' checks for tags on the KMS API request, not on the IAM role. The requirement is to enforce that the IAM role has a specific tag, not that the request includes a tag.
★ When this WOULD be the correct answer
If the requirement were to enforce that the KMS API request itself includes a specific tag (e.g., to track usage or enforce tagging policies on decryption requests), then using 'kms:RequestTag' in the key policy would be correct.
Why candidates choose this
Candidates may confuse request tags with principal tags, or think that KMS key policies can directly evaluate IAM role tags via request conditions.
✗Add a condition to the IAM role's trust policy that denies the 'kms:Decrypt' action unless the role has the tag.Wrong answer — click to see why▾
Why this is wrong here
The IAM role's trust policy controls who can assume the role, not what actions the role can perform. Adding a condition to deny 'kms:Decrypt' in the trust policy is ineffective because trust policies do not evaluate permissions for service actions like KMS decryption.
★ When this WOULD be the correct answer
If the requirement were to restrict which principals (users or services) can assume the IAM role based on a tag (e.g., only allow EC2 instances with a specific tag to assume the role), then adding a condition on 'aws:PrincipalTag' in the trust policy would be correct.
Why candidates choose this
Candidates may confuse the purpose of trust policies with identity-based policies, thinking that conditions in trust policies can control the role's permissions to perform actions, rather than just controlling who can assume the role.
✗Add a condition to the S3 bucket policy that denies all access unless the IAM role has the required tag.Wrong answer — click to see why▾
Why this is wrong here
The S3 bucket policy cannot enforce conditions on the IAM role's tags for KMS decryption; it controls access to S3 objects, not KMS actions. The requirement is to restrict the KMS decryption permission, which is governed by IAM policies and KMS key policies, not S3 bucket policies.
★ When this WOULD be the correct answer
If the requirement were to restrict access to S3 objects based on the IAM role's tag (e.g., only allow read access when the role has 'Environment=Production'), then adding a condition to the S3 bucket policy using 'aws:PrincipalTag' would be correct.
Why candidates choose this
Candidates may think S3 bucket policies can control all related actions (including KMS decryption) because the data is stored in S3, or they may confuse the scope of S3 bucket policies with IAM policies.
Analysis generated from the official CLF-C02blueprint 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 CLF-C02 question from scratch — 988 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 CLF-C02 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 CLF-C02 exam.