Examkin

Question

Difficulty: Very hardMulti-Account Governance and Organizational Structure

A financial services company manages its multi-account environment using AWS Organizations. The security team has grouped all active workload accounts under a single Workloads Organizational Unit (OU). To comply with strict regulatory frameworks, the security team must enforce the following security policies:

1. All Amazon EBS volumes created in the member accounts must be encrypted at rest.
2. Volume encryption must only use Customer Managed Keys (CMKs) created within the local member accounts. The use of AWS-managed keys (such as aws/ebs) is strictly prohibited.
3. A centralized IAM role named SecurityAuditRole, which is deployed via AWS CloudFormation StackSets to all member accounts, must be protected from deletion or modification by any local administrator.
4. The CloudFormation StackSets service must still be allowed to update the SecurityAuditRole from the Management account during security maintenance windows.

Which solutions architect design represents the most secure and operationally efficient configuration to meet these requirements?

  1. A
    Enable EBS encryption by default in all member accounts. In each member account, modify the key policy of the AWS-managed KMS key for EBS (aws/ebs) to deny kms:CreateGrant to all local IAM users and roles except the SecurityAuditRole and AWSCloudFormationStackSetExecutionRole. Attach a Service Control Policy (SCP) to the Workloads OU that denies iam:DeleteRole, iam:UpdateRole, and policy modification actions targeting SecurityAuditRole unless the caller is AWSCloudFormationStackSetExecutionRole.
  2. Create and attach a Service Control Policy (SCP) to the Workloads OU that denies ec2:CreateVolume and ec2:RunInstances if ec2:Encrypted is false. In the same SCP, deny kms:CreateGrant if kms:KeyManager equals AWS when the request is made via the EC2 service principal. Additionally, deny iam:DeleteRole, iam:UpdateRole, and all policy modification actions targeting the SecurityAuditRole resource, except when the caller is the StackSet execution role AWSCloudFormationStackSetExecutionRole.Answer
  3. C
    Create and attach a Service Control Policy (SCP) to the Workloads OU that denies ec2:CreateVolume and ec2:RunInstances if ec2:Encrypted is false. In the SCP, include an explicit Allow statement granting the AWSCloudFormationStackSetExecutionRole the ability to modify the SecurityAuditRole in member accounts, and remove the corresponding local IAM permissions for role management from all local administrator groups to prevent unauthorized modifications.
  4. D
    Create and attach a Service Control Policy (SCP) to the Workloads OU that denies ec2:CreateVolume and ec2:RunInstances if ec2:Encrypted is false, and denies kms:CreateGrant if kms:KeyManager is AWS for EC2. Attach a separate SCP that denies iam:DeleteRole and iam:UpdateRole on SecurityAuditRole. Configure the trust policy of SecurityAuditRole to trust the Management account's root principal directly for all configuration changes, bypassing the need for AWSCloudFormationStackSetExecutionRole in the member accounts.

Answer

Create and attach a Service Control Policy (SCP) to the Workloads OU that denies ec2:CreateVolume and ec2:RunInstances if ec2:Encrypted is false. In the same SCP, deny kms:CreateGrant if kms:KeyManager equals AWS when the request is made via the EC2 service principal. Additionally, deny iam:DeleteRole, iam:UpdateRole, and all policy modification actions targeting the SecurityAuditRole resource, except when the caller is the StackSet execution role AWSCloudFormationStackSetExecutionRole.
The correct solution uses a single Service Control Policy (SCP) to implement all guardrails. The first statement ensures EBS encryption by denying volume creation if the encryption flag is false. The second statement blocks the use of AWS-managed keys by checking the kms:KeyManager condition key (which is set to AWS for AWS-managed keys and CUSTOMER for customer-managed keys) and denying the kms:CreateGrant action when called by the EC2 service. The third statement prevents modification of the SecurityAuditRole by local administrators while explicitly exempting the StackSet execution role, which is the standard mechanism for StackSets to manage resources across accounts.

Step-by-Step Solution

1
Enforce EBS Encryption at rest using an SCP.
Use an SCP with a deny statement that blocks ec2:CreateVolume and ec2:RunInstances if the ec2:Encrypted condition key is false.
This guarantees that no volume can be created unless encryption is requested and enabled.
2
Enforce Customer Managed Keys (CMKs) and block AWS-managed keys.
Restrict kms:CreateGrant actions by denying requests where the resource uses a key managed by AWS (kms:KeyManager equals AWS) and the request is initiated via EC2.
AWS-managed keys (like aws/ebs) have kms:KeyManager set to AWS, whereas Customer Managed Keys have it set to CUSTOMER. Denying grants on AWS-managed keys forces the use of CMKs.
3
Protect the SecurityAuditRole from local modification while allowing CloudFormation StackSets.
Add an SCP deny statement targeting iam:DeleteRole, iam:UpdateRole, and policy changes for the specific role resource, adding a Condition of StringNotLike or ArnNotEquals for the AWSCloudFormationStackSetExecutionRole.
This allows the StackSet execution role to modify the role during automated deployments while blocking local administrators in the member accounts.

Key Concept

Organizational governance using Service Control Policies (SCPs) to establish security guardrails without granting permissions, utilizing KMS condition keys (kms:KeyManager) to enforce key ownership requirements, and managing cross-account deployment roles (AWSCloudFormationStackSetExecutionRole) safely.
Estimated Time:3m 0s
Rate this question

Topics

Multi-Account Governance and Organizational Structure

More questions from this topic