An enterprise manages its multi-account environment using AWS Organizations. An application running in a production account (Account A) writes transaction logs containing sensitive financial data to an Amazon S3 bucket in Account A. To comply with corporate data protection policies, these logs must be encrypted at rest using an encryption key managed by the central Security account (Account Sec). In addition, a compliance auditor role in Account Sec must have read access to these logs to conduct periodic compliance checks.
The Solutions Architect attempts to implement this by configuring the default server-side encryption (SSE-KMS) of the S3 bucket in Account A to use the AWS-managed KMS key for S3 (aws/s3) located in Account Sec. The architect also adds a bucket policy in Account A to grant s3:GetObject access to the compliance auditor role in Account Sec. Both the application in Account A and the auditor in Account Sec begin receiving Access Denied errors during write and read operations.
Which of the following describes the root cause of these failures and the correct way to resolve them?
- AThe failures are caused by restrictive boundaries at the organization level. To resolve this, the architect must attach a Service Control Policy (SCP) to the Organizational Unit (OU) containing both accounts, explicitly allowing s3:* and kms:* actions across accounts. Because SCPs act as permission boundaries that automatically inherit down, this policy will authorize the cross-account S3 and KMS actions without needing to modify local IAM or KMS key policies.
- AWS-managed KMS keys (such as aws/s3) cannot be used for cross-account operations because their key policies are managed by AWS and cannot be modified. To resolve this, the architect must create a customer-managed KMS key in Account Sec and configure its key policy to grant the application's IAM role in Account A permissions for kms:GenerateDataKey and kms:Decrypt. Additionally, the key policy must grant kms:Decrypt to the compliance auditor role in Account Sec, and the S3 bucket policy in Account A must grant the auditor role s3:GetObject permissions.Cevap
- CThe AWS-managed KMS key (aws/s3) in Account Sec is restricted from cross-account access because the S3 bucket in Account A has not enabled cross-account key sharing. To resolve this, the architect must modify the S3 bucket configuration to enable cross-account KMS delegation, which permits the S3 service in Account A to utilize the AWS-managed key from Account Sec without requiring a customer-managed key.
- DThe failures occur because S3 bucket policies have not been configured to manage decryption. To resolve this, the architect must create a customer-managed KMS key in Account Sec, and configure a bucket policy in Account A that grants both s3:GetObject and kms:Decrypt directly to the auditor's IAM role. Since S3 bucket policies centrally govern all access to the resource, this configuration allows the auditor to read and decrypt the logs without modifying KMS key policies.