Examkin

Question

Difficulty: MediumMulti-Account Governance and Organizational Structure

A financial enterprise is designing its multi-account governance structure using AWS Organizations. The security team wants to ensure that developers operating within the Sandbox Organizational Unit (OU) are restricted to using only Amazon EC2, Amazon S3, and Amazon DynamoDB. The developers must be blocked from using any other AWS services, even if they have administrative privileges in their local accounts. This control must be enforced centrally with the least administrative overhead. How should the Solutions Architect implement this governance control?

  1. Attach a Service Control Policy (SCP) to the Sandbox OU that uses a Deny effect with a NotAction element specifying ec2:*, s3:*, dynamodb:*, and organizations:*, while keeping the default FullAWSAccess SCP attached. Grant developers access locally using IAM policies.Answer
  2. B
    Attach a Service Control Policy (SCP) to the Sandbox OU with an Allow effect for ec2:*, s3:*, and dynamodb:* actions, and instruct developers that this policy grants them the necessary access permissions directly.
  3. C
    Create an AWS-managed KMS key in the organization's management account and modify its key policy to deny access to any services other than EC2, S3, and DynamoDB for all sandbox account principals.
  4. D
    Create a centralized IAM policy in a shared services account and use AWS Resource Access Manager (RAM) to share this policy with the Sandbox OU, forcing all local IAM roles to inherit its limits.

Answer

Attach a Service Control Policy (SCP) to the Sandbox OU that uses a Deny effect with a NotAction element specifying ec2:*, s3:*, dynamodb:*, and organizations:*, while keeping the default FullAWSAccess SCP attached. Grant developers access locally using IAM policies.
The correct solution attaches a Service Control Policy (SCP) using a Deny effect with a NotAction element to the Sandbox OU. This acts as a centralized guardrail, blocking all services except EC2, S3, DynamoDB, and Organizations. Since SCPs do not grant permissions, developers must still be granted access locally via IAM policies.

Step-by-Step Solution

1
Identify the mechanism for central permission guardrails in AWS Organizations.
Service Control Policies (SCPs) are identified as the correct tool for restricting services across accounts.
SCPs allow administrators to set the maximum available permissions for member accounts at the OU or account level.
2
Formulate the SCP structure to permit only EC2, S3, and DynamoDB with minimal overhead.
A Deny policy with a NotAction clause for ec2:*, s3:*, dynamodb:*, and organizations:* is created, keeping the default FullAWSAccess SCP in place.
Using Deny with NotAction avoids the complexity of removing and recreating the default FullAWSAccess policy, which would require defining every allowed action explicitly.
3
Determine the local account requirements to allow developers to perform work.
Local IAM policies must be created in the sandbox accounts to explicitly grant permissions to EC2, S3, and DynamoDB.
SCPs restrict permissions but do not grant them; an IAM policy is still required within the local account to allow access.

Key Concept

Service Control Policies (SCPs) act as filters that limit the maximum permissions of IAM users and roles in member accounts, but they do not grant permissions directly. A common pattern for whitelisting specific services with minimal maintenance is using a Deny effect with a NotAction block.
Rate this question

Topics

Multi-Account Governance and Organizational Structure

More questions from this topic