SOA-C02 Security and Compliance Practice Question
A SysOps administrator is managing a multi-account AWS environment using AWS Organizations. The security team has mandated that all Amazon S3 buckets across all accounts must be encrypted with SSE-KMS using a centrally managed KMS key. The administrator has created a KMS key in the master account and enabled key rotation. The key policy allows the root user of each member account to use the key. However, users in member accounts report that they cannot upload objects to their S3 buckets with SSE-KMS using the central key, even though they have s3:PutObject permissions. The administrator verifies that the KMS key policy includes the necessary permissions for the member accounts. What should the administrator do to resolve the issue?
⚠ Common exam trap
The trap is assuming that a permissive KMS key policy is sufficient for cross-account access — candidates forget that IAM policies in the member account must also grant the KMS actions.
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
✓
Attach an IAM policy to the users/roles in the member accounts that allows kms:GenerateDataKey using the central KMS key.
Cross-account KMS usage requires permissions on both sides: the key policy must allow the external account, and the IAM principal in that account must also be granted kms:GenerateDataKey (and kms:Decrypt) via an IAM policy. The key policy alone is insufficient.
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 a new KMS key in each member account and configure S3 bucket default encryption accordingly.
Why it's wrong here
Creating a new KMS key in each member account and applying it as the S3 bucket default encryption would fragment key management across accounts, undermining the centralized control and audit trail the organization wants through the master account. With a member-account key, the master account cannot directly administer or rotate the key, and CloudTrail logs of key usage would be spread across multiple accounts, making compliance and monitoring harder. This approach solves connectivity only locally, but the requirement is to enforce central governance, so a single master-managed key is still necessary.
- ✗
Ensure that the KMS key policy allows the master account to administer the key.
Why it's wrong here
Because the KMS key already resides in the master account, the master account is the key administrator by default and can already manage the key policy. Adjusting the key policy to allow the master account to administer the key does nothing to grant member-account IAM principals the permission to call kms:GenerateDataKey for encryption. Even if the key policy is perfectly configured to trust the member accounts, the member-account users/roles still need an explicit IAM permission that references the central key ARN; without that, the key policy alone cannot authorize the encryption operation.
- ✓
Attach an IAM policy to the users/roles in the member accounts that allows kms:GenerateDataKey using the central KMS key.
Why this is correct
For S3 objects encrypted with SSE-KMS, the IAM principal performing the PutObject call must have kms:GenerateDataKey permission on the key that encrypts the object. In a cross-account scenario using a central KMS key in the master account, the member-account users/roles must be explicitly allowed, via an IAM policy, to use that key. The key policy in the master account should grant access to the member account principals, and this IAM policy in the member account completes the authorization chain, enabling the S3 encryption to succeed with the centrally managed key.
- ✗
Update the S3 bucket policy to allow the s3:PutObject action only when encryption is set to SSE-KMS.
Why it's wrong here
A bucket policy condition that requires SSE-KMS can enforce that objects are encrypted, but it cannot authorize the KMS operation needed to perform that encryption. When S3 encrypts an object with SSE-KMS, the service calls KMS as the requester, so the IAM principal still needs kms:GenerateDataKey (and kms:Decrypt for reads) on the key. The bucket policy only controls access to the S3 resource; KMS actions are governed separately by the key policy and the caller's IAM permissions, so this option does not fix the missing KMS permission.
Visual reference
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
This SOA-C02 question is part of Courseiva's 1,169-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
JA
Written and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official Amazon Web Services exam blueprint
This SOA-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 SOA-C02 exam.