Examkin

Soru

Zorluk: Çok zorMulti-Account Governance and Organizational Structure

A medical device company uses AWS Organizations to manage a multi-account environment. A newly acquired division has several AWS accounts grouped under a dedicated Organizational Unit (OU) named Acquisition-OU. The corporate security team must enforce a strict compliance rule: all Amazon Elastic Block Store (Amazon EBS) volumes provisioned within Acquisition-OU must be encrypted. To ensure rapid mitigation in the event of a security incident, the encryption must use a Customer Managed Key (CMK) hosted in a centralized Security account, allowing the security team to revoke access instantly. The local administrators in the member accounts have full administrative privileges and must be able to launch Amazon EC2 instances with encrypted volumes without having IAM credentials or roles in the Security account. Which combination of configurations will meet these requirements while preventing member account administrators from bypassing the encryption guardrail?

  1. A
    In the Security account, create a Customer Managed Key (CMK). Configure the CMK's key policy to allow the member accounts' root principals to perform the kms:Decrypt, kms:GenerateDataKeyWithoutPlaintext, and kms:CreateGrant actions. Attach a Service Control Policy (SCP) to the Acquisition-OU that explicitly allows these KMS actions on the Security account's CMK, and denies ec2:RunInstances if the EBS volume is unencrypted. Rely on the SCP to authorize the pipeline IAM roles without adding local IAM policy permissions in the member accounts.
  2. In the Security account, create a Customer Managed Key (CMK). Configure the CMK's key policy to allow the member accounts' root principals (arn:aws:iam::<member-account-ID>:root) to perform the kms:Decrypt, kms:GenerateDataKeyWithoutPlaintext, and kms:CreateGrant actions. In each member account, grant the local IAM roles used to launch EC2 instances permissions to perform these same KMS actions on the central CMK. Attach a Service Control Policy (SCP) to the Acquisition-OU that denies the ec2:RunInstances action if the EBS volume is unencrypted or if the KMS key specified is not the central CMK ARN.Cevap
  3. C
    In the Security account, enable cross-account sharing on the AWS-managed KMS key for EBS (aws/ebs) by updating its key policy to trust the member accounts. In each member account, grant local EC2 execution roles permissions to use the Security account's aws/ebs key. Attach a Service Control Policy (SCP) to the Acquisition-OU that denies the ec2:RunInstances action if the EBS volume is unencrypted.
  4. D
    In the Security account, create a Customer Managed Key (CMK) and configure its key policy to trust the member accounts' root principals. In the member accounts, create and attach a customer managed IAM policy to all local IAM users and roles that denies the ec2:RunInstances action if the EBS volume is unencrypted or does not use the central CMK. Avoid attaching any Service Control Policies (SCPs) at the Organization level to minimize performance impact on API requests.

Cevap

Create a Customer Managed Key in the Security account, trust the member accounts' root principals in its key policy, grant the local EC2 roles in the member accounts permission to use the central key, and enforce the configuration using an OU-level Service Control Policy that blocks instance launches with unencrypted volumes or unauthorized keys.
The correct solution uses a Customer Managed Key (CMK) in the Security account because AWS-managed keys cannot be shared cross-account. It delegates key access to the member accounts via the root principal in the key policy, and then explicitly grants access to the local EC2 roles using local IAM policies. Finally, it uses a Service Control Policy (SCP) attached to the Organizational Unit to deny launching instances unless they use the approved central key, which cannot be bypassed by local administrators.

Adım Adım Çözüm

1
Select the correct KMS key type.
A Customer Managed Key (CMK) must be created in the central Security account because the default AWS-managed KMS key (aws/ebs) does not allow policy modification and cannot be shared across different AWS accounts.
Enables cross-account usage for EBS encryption.
2
Configure the central key policy.
The CMK policy must trust the root principal of the member accounts (arn:aws:iam::<member-account-ID>:root) for the required actions: kms:Decrypt, kms:GenerateDataKeyWithoutPlaintext, and kms:CreateGrant.
Enables the member accounts to delegate these permissions to their local roles.
3
Configure local IAM permissions in member accounts.
Local IAM policies must grant the EC2 execution roles permission to use the central CMK.
Allows the EC2 service to create a grant and use the key when launching instances, since SCPs only establish permission boundaries and do not grant permissions.
4
Enforce compliance via a Service Control Policy (SCP).
Attach an SCP to the Acquisition-OU that denies ec2:RunInstances if the volume is unencrypted or uses a key other than the central CMK.
Ensures that even local administrators cannot bypass the encryption policy, as SCPs apply to all principals in member accounts including administrators.

Anahtar Kavram

Cross-account KMS key delegation and Service Control Policy (SCP) enforcement in AWS Organizations
Tahmini Süre:3m 0s
Bu soruyu puanla

Konular

Multi-Account Governance and Organizational Structure

Bu konudan daha fazla soru