Question

Difficulty: HardMulti-Account Governance and Organizational Structure

A multinational retail conglomerate manages its AWS environment using AWS Organizations. The organization contains a Security account under a CoreServices Organizational Unit (OU), and fifty member accounts under a Production OU. To satisfy strict industry regulatory standards, the corporate security team mandates that all new Amazon Elastic Block Store (EBS) volumes created within the Production OU must be encrypted using a specific customer managed key (CMK). The security team wants to manage the key centrally within the Security account to control key rotation and audit access logs from a single location. The solution must prevent member account users from creating unencrypted volumes or using their local AWS-managed keys, while allowing production workloads to auto-scale and launch instances without manual intervention from the security team. Which of the following strategies should a solutions architect implement to meet these requirements?

  1. A
    Create a Customer Managed Key (CMK) in the Security account and share it with all member accounts in the Production OU using AWS Resource Access Manager (RAM). Attach a Service Control Policy (SCP) to the Production OU that denies 'ec2:RunInstances' and 'ec2:CreateVolume' if the volume is not encrypted using the shared CMK.
  2. B
    Configure the key policy of the default AWS-managed KMS key for EBS (aws/ebs) in the Security account to grant access to the member accounts in the Production OU. Attach a Service Control Policy (SCP) to the Production OU that denies 'ec2:RunInstances' and 'ec2:CreateVolume' if the volume is not encrypted with this AWS-managed key.
  3. Create a Customer Managed Key (CMK) in the Security account. Configure the key policy of this CMK to allow the member accounts to perform 'kms:DescribeKey', 'kms:Decrypt', and 'kms:CreateGrant' actions. Attach a Service Control Policy (SCP) to the Production OU that denies 'ec2:RunInstances' and 'ec2:CreateVolume' if the volume is not encrypted, or if the encryption key used does not match the CMK in the Security account. Configure local IAM policies in the member accounts to permit workloads to use the central CMK.Answer
  4. D
    Create a Customer Managed Key (CMK) in the Security account. Attach a Service Control Policy (SCP) to the Production OU that explicitly allows the member accounts to access this CMK and denies 'ec2:RunInstances' and 'ec2:CreateVolume' if the volume is not encrypted with the CMK. Do not modify the key policy of the CMK to maintain security.

Answer

Create a Customer Managed Key (CMK) in the Security account, configure its key policy to allow member accounts to perform key actions including 'kms:CreateGrant', and use an SCP to deny EBS volume creation that is not encrypted with this key, while configuring local IAM policies to allow workload access.
The correct strategy requires creating a Customer Managed Key (CMK) in the central Security account, modifying its key policy to grant usage permissions to the member accounts (specifically including 'kms:CreateGrant' to allow EBS to manage encryption keys on behalf of users), enforcing encryption using an SCP on the Production OU, and configuring local IAM policies to allow workloads access. This satisfies all security and operational requirements.

Step-by-Step Solution

1
Create a Customer Managed Key (CMK) in the central Security account instead of using AWS-managed keys.
A CMK is created, which supports cross-account policy delegation.
AWS-managed keys cannot be shared across accounts.
2
Configure the CMK key policy to allow member accounts to perform 'kms:DescribeKey', 'kms:Decrypt', and 'kms:CreateGrant'.
Member account IAM principals can use the key, and AWS services can create grants on their behalf.
EBS and EC2 auto-scaling require these permissions to manage volume encryption.
3
Attach an SCP to the Production OU to deny 'ec2:RunInstances' and 'ec2:CreateVolume' unless the volume is encrypted with the specific CMK.
Unencrypted EBS volumes or volumes encrypted with other keys are prevented from being created in member accounts.
Ensures governance compliance across all member accounts in the OU.

Key Concept

Cross-account KMS key sharing and Service Control Policy guardrails
Rate this question