Examkin

Soru

Zorluk: Çok zorMulti-Account Governance and Organizational Structure

An international retail consortium manages its multi-account structure using AWS Organizations. The security team has established a dedicated workloads Organizational Unit (OU) that houses several production and development member accounts. Each member account has local administrator access granted to the respective engineering leads.

The security team has a new compliance directive: only a centralized, pre-approved IAM role named AnalyticsConsumer (which will be deployed across all member accounts) must be permitted to run queries using Amazon Athena. Local administrators must be blocked from executing Athena queries under their own sessions. Crucially, the design must prevent these local administrators from tampering with the AnalyticsConsumer role, deleting it, or recreating a role with the same name to bypass the restriction.

Which solution represents the most secure and operationally efficient configuration to meet these requirements?

  1. Deploy the AnalyticsConsumer role across the member accounts using AWS CloudFormation StackSets. Attach an SCP to the workloads OU that denies all athena:* actions if the aws:PrincipalARN condition is not like arn:aws:iam::*:role/AnalyticsConsumer. Attach a second SCP to the workloads OU that denies all iam:* actions on the resource arn:aws:iam::*:role/AnalyticsConsumer unless the principal is the AWS CloudFormation StackSets execution role.Cevap
  2. B
    Attach an SCP to the workloads OU that allows athena:* actions only for the AnalyticsConsumer role, and denies Athena actions for all other roles. Create a local IAM policy in each member account that restricts local administrators from running iam:DeleteRole or iam:UpdateRole on any role prefixed with Analytics.
  3. C
    Deploy the AnalyticsConsumer role using AWS CloudFormation StackSets. Use AWS Resource Access Manager (RAM) to share the AnalyticsConsumer role from the management account to all member accounts in the workloads OU. Attach an SCP to the workloads OU that denies all athena:* actions if the request is not initiated by a shared RAM principal.
  4. D
    Deploy the AnalyticsConsumer role across the member accounts. Attach an SCP to the workloads OU that denies athena:* actions unless the principal is the AnalyticsConsumer role. To prevent local administrators from modifying the role, configure an AWS KMS customer managed key in the security account and configure the key policy to restrict IAM role modifications by local administrators.

Cevap

Deploying the AnalyticsConsumer role across the member accounts using AWS CloudFormation StackSets, attaching an SCP that denies Athena access if the principal is not the AnalyticsConsumer role, and attaching another SCP that denies IAM actions on that role unless the caller is the CloudFormation StackSets execution role.
The correct solution involves deploying the role via CloudFormation StackSets to ensure consistency. To enforce the restriction, the first SCP acts as a guardrail by denying Athena access to all principals except the AnalyticsConsumer role. The second SCP secures the AnalyticsConsumer role itself by denying any IAM modifications on the role resource unless performed by the StackSets execution role. This prevents local administrators from bypassing the restriction by deleting or modifying the role, while still allowing central administrators to maintain it.

Adım Adım Çözüm

1
Use AWS CloudFormation StackSets to deploy the AnalyticsConsumer role to all member accounts in the workloads OU, ensuring a consistent and centrally managed role configuration.
The AnalyticsConsumer role is successfully created in all target member accounts with the necessary local permissions to run Athena queries.
This establishes a consistent cross-account administrative baseline and decouples role provisioning from local member account control.
2
Attach a Service Control Policy (SCP) to the workloads OU that contains a Deny statement for all athena:* actions with a condition that checks if the aws:PrincipalARN is NOT the AnalyticsConsumer role.
All Athena actions are blocked for all users, groups, and roles in the member accounts, except when assuming the AnalyticsConsumer role.
This establishes the permission guardrail, restricting access to Athena to only the approved role regardless of local administrator status.
3
Attach a second SCP to the workloads OU that denies all iam:* actions targeting the AnalyticsConsumer role resource (arn:aws:iam::*:role/AnalyticsConsumer) unless the calling principal is the central CloudFormation StackSets execution role.
Local administrators are blocked from modifying, deleting, or recreating the AnalyticsConsumer role, while the central StackSets mechanism retains management access.
This prevents local administrators from tampering with the role to bypass the Athena access restriction, solving the principal bypass vector.

Anahtar Kavram

Multi-account permission guarding using Service Control Policies (SCPs) combined with centralized identity provisioning.
Bu soruyu puanla

Konular

Multi-Account Governance and Organizational Structure

Bu konudan daha fazla soru