Examkin

Question

Difficulty: MediumMulti-Account Governance and Organizational Structure

A retail company uses AWS Organizations to manage its multi-account environment. The organization structure has a parent `Workloads` Organizational Unit (OU) containing a `Development` child OU and a `Production` child OU.

The security team wants to enforce the following governance controls:
1. Member accounts in the `Development` OU must be prevented from sharing AWS resources externally with accounts outside the AWS Organization using AWS Resource Access Manager (RAM).
2. Users in the `Development` OU must be blocked from deleting or modifying AWS Config rules to prevent disabling compliance checks.
3. These restrictions must be enforced even for the root user of the member accounts and must not be bypassable by administrator users in those accounts.

Which solution should a solutions architect implement to meet these requirements with the least administrative overhead?

  1. Enable resource sharing with AWS Organizations in AWS RAM from the management account. Attach a Service Control Policy (SCP) to the `Development` OU that denies `ram:CreateResourceShare` and `ram:AssociateResourceShare` actions if the `ram:AllowsExternalPrincipals` condition key is set to true, and denies the `config:PutConfigRule`, `config:DeleteConfigRule`, and `config:StopConfigurationRecorder` actions. Configure local IAM policies in the member accounts to grant standard developer permissions.Answer
  2. B
    Attach a Service Control Policy (SCP) to the `Development` OU that explicitly allows `ram:CreateResourceShare` only when sharing with the `Production` OU, and allows read-only access to AWS Config. Remove all local IAM policies from the member accounts, as the SCP will automatically delegate and restrict the permitted actions to all users.
  3. C
    Configure AWS Resource Access Manager (RAM) by enabling resource sharing with AWS Organizations in the management account. Rely on RAM's default behavior, which automatically blocks all external resource sharing when organizational sharing is enabled. For AWS Config, have local administrators in the member accounts attach an IAM permissions boundary to all developers to deny AWS Config rule modifications.
  4. D
    Configure SAML 2.0 federation for the member accounts. In the trust relationship policy of the federated IAM roles, include `ram:CreateResourceShare` and `config:PutConfigRule` under the action list alongside `sts:AssumeRoleWithSAML` to deny these permissions during federation.

Answer

Enable resource sharing with AWS Organizations in AWS RAM from the management account. Attach a Service Control Policy (SCP) to the `Development` OU that denies `ram:CreateResourceShare` and `ram:AssociateResourceShare` actions if the `ram:AllowsExternalPrincipals` condition key is set to true, and denies the `config:PutConfigRule`, `config:DeleteConfigRule`, and `config:StopConfigurationRecorder` actions. Configure local IAM policies in the member accounts to grant standard developer permissions.
The correct solution uses a Service Control Policy (SCP) attached to the child OU. SCPs act as guardrails that define the maximum available permissions for member accounts, applying to all users including the root user. By denying resource share creation when external principals are allowed, the SCP prevents sharing outside the organization. Denying Config rule modification and stopping the configuration recorder ensures compliance remains active. Enabling Organizations sharing in RAM allows internal sharing to work as expected. Local IAM policies are still required to grant actual permissions, as SCPs do not grant any permissions directly.

Step-by-Step Solution

1
Enable sharing within the organization in AWS Resource Access Manager (RAM) from the management account.
Allows RAM to support sharing across accounts within the AWS Organization structure.
This is a prerequisite for controlled internal sharing before enforcing restrictions on external sharing.
2
Create a Service Control Policy (SCP) to restrict external resource sharing and block changes to AWS Config rules.
An SCP is created with an explicit Deny on `ram:CreateResourceShare` and `ram:AssociateResourceShare` when the `ram:AllowsExternalPrincipals` condition key is true, and on `config:PutConfigRule`, `config:DeleteConfigRule`, and `config:StopConfigurationRecorder`.
SCPs apply to all users (including root) and cannot be bypassed or modified by administrators in the member accounts.
3
Attach the SCP to the Development OU.
The guardrails are applied to all member accounts residing in the Development OU, leaving the Production OU unaffected.
This target application satisfies the requirement to isolate the development environment restriction without impacting production.
4
Ensure local IAM policies are in place to grant developer permissions.
Users can execute actions allowed by local IAM policies, provided they do not violate the SCP guardrails.
SCPs act as filters and do not grant permissions; local IAM policies are still required to allow authorized activities.

Key Concept

Implementing Multi-Account Governance with Service Control Policies (SCPs) and Resource Access Manager (RAM).
Estimated Time:2m 0s
Rate this question

Topics

Multi-Account Governance and Organizational Structure

More questions from this topic