DOP-C02 Security and Compliance Practice Question
A company uses AWS Key Management Service (KMS) to encrypt data at rest in Amazon S3. The security team wants to ensure that only users with a specific attribute in their SAML assertion can decrypt the data. Which KMS key policy should be used?
⚠ Common exam trap
A common mistake is to think that S3 bucket policies can control KMS decryption or that KMS key policies can directly inspect SAML assertions. KMS key policies only see the principal (the IAM role or user) and its attributes/tags. To enforce a SAML attribute, you must first map it to a session tag in the role trust policy, then condition on that tag in the KMS key policy.
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
✓
Modify the KMS key policy to include a condition that allows kms:Decrypt only if the SAML assertion contains the specific attribute.
KMS key policies are resource-based policies that can use IAM condition keys. To enforce a requirement based on a SAML assertion, you must first configure the IAM role's trust policy to map the SAML attribute to a session tag using sts:TagSession. Then, the KMS key policy can include a condition such as aws:PrincipalTag/attribute_name to allow kms:Decrypt only when that session tag matches the expected value. This ensures compliance at the key level, independent of S3 bucket policies. Note that saml:sub and other SAML condition keys are not supported in KMS key policies; they are only valid in IAM trust policies.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Create an S3 bucket policy that denies kms:Decrypt unless the request includes a specific tag.
Why it's wrong here
S3 bucket policies are resource-based policies that only authorize S3 data-plane actions such as s3:GetObject and s3:PutObject; they are not evaluated by the KMS service when a caller makes a kms:Decrypt API call. Even if you add a Deny statement for kms:Decrypt, S3 will ignore it because S3 does not enforce KMS permissions. Furthermore, S3 bucket policies cannot reference request tags or SAML attributes in a way that would affect KMS decryption because the KMS key policy and IAM policies are the authoritative documents for that KMS action.
- ✓
Modify the KMS key policy to include a condition that allows kms:Decrypt only if the SAML assertion contains the specific attribute.
Why this is correct
KMS key policies are resource-based policies attached directly to the customer master key, and they are evaluated for every KMS API action against that key. The policy can include a Condition block that references SAML-derived session attributes, such as a session tag mapped from an attribute in the SAML assertion, to allow kms:Decrypt only when the expected attribute value is present. This is the correct approach because it centralizes the decryption restriction at the key resource itself, ensuring that any principal attempting to use the key must satisfy the condition regardless of their IAM permissions.
- ✗
Attach a resource-based policy to the S3 bucket that allows decryption only for users with the specific attribute.
Why it's wrong here
S3 bucket policies control access to S3 actions, not to KMS keys, so attaching a resource-based policy to the S3 bucket cannot directly allow or deny kms:Decrypt. Even if the bucket policy allows the GetObject action, a separate kms:Decrypt permission is still required when the S3 object is encrypted with SSE-KMS, and that permission must come from the KMS key policy or an IAM policy. Moreover, S3 bucket policies do not evaluate the SAML assertion or its attributes in the context of KMS; they only govern S3 operations.
- ✗
Use an IAM policy that grants kms:Decrypt only if the user has the specific attribute.
Why it's wrong here
IAM identity-based policies can grant kms:Decrypt, but they cannot directly inspect the contents of an SAML assertion because SAML attributes are processed by STS to create role session tags. An IAM policy could use a condition like aws:PrincipalTag, but that would require at least one identity policy per user or role and is not the native place to enforce key-specific constraints. The KMS key policy is more appropriate because it is evaluated once for the key and can directly incorporate SAML-derived context keys, whereas IAM policies are less centralized and cannot directly reference raw SAML attributes.
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 DOP-C02 question from scratch — 1,013 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 DOP-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 DOP-C02 exam.