Design Solutions for Organizational Complexity practice questions

Use an SCP to deny changes to the password policy and to deny deactivation of MFA devices. Use AWS Config rules to detect non-compliant users.

SCPs set the guardrails: they deny member accounts the ability to weaken the password policy or deactivate MFA devices, satisfying the enforcement requirement. AWS Config rules then provide detective control, flagging users who remain non-compliant so remediation can follow.

The S3 bucket policy includes a condition that only allows access from the logging account's AWS service principals, not from individual IAM users.

A bucket policy condition restricting access to the logging account's service principals denies the analyst's IAM user even though the identity policy grants read-only S3 access. The explicit resource-based deny overrides the identity permission, which is why the analyst cannot reach the logs.

An SCP that denies the effect of actions that modify billing preferences.

An SCP denying billing-modification actions applies to every principal in every account under the root OU, including the finance team's read-only users. This satisfies the security team's requirement that no IAM user can alter billing preferences.

Create an SCP that denies the ec2:RunInstances action for specific instance types.

SCPs define the maximum permissions available to principals in member accounts, so denying ec2:RunInstances for named instance types blocks those launches organisation-wide. This is preventive enforcement at the account level, matching the requirement to restrict instance types across all accounts.

Use AWS Config rules to detect non-compliant instance types and automatically terminate them using AWS Systems Manager Automation.

AWS Config rules evaluate running resources against desired instance-type definitions and flag violations; Systems Manager Automation then terminates non-compliant instances. This is detective plus corrective control, complementing preventive SCPs rather than blocking the launch API call itself.

Use an SCP to prevent disabling of AWS Config in any account.

An SCP applied at the organisation root or OU level denies the `config:StopConfigurationRecorder` and `config:DeleteConfigurationRecorder` actions, enforcing the stem's requirement that AWS Config stays enabled across every account. This preventive guardrail complements Control Tower's detective controls, ensuring accounts cannot tamper with their configuration recorder.

Configure the central S3 bucket policy to allow cross-account log delivery from all accounts in the organization.

The central S3 bucket policy must grant s3:PutObject permission to the AWS Config service principals or roles in every member account. Without this cross-account allowance, delivery of configuration snapshots and history to the central bucket fails.

Enable AWS Config in the management account and use Control Tower's account factory to propagate the configuration to all accounts.

Control Tower's account factory applies a baseline that enables AWS Config in each newly provisioned account, propagating the configuration consistently. Enabling it only in the management account would not cover member accounts, so the factory mechanism is what satisfies the all-accounts requirement.

The user is not passing the MFA serial number and token code in the assume-role API call.

When a trust policy's Condition requires aws:MultiFactorAuthPresent via sts:AssumeRole, the caller must supply the MFA serial number and token code as parameters in the assume-role API call. Enabling MFA on the user alone does not satisfy the condition, so the request is denied.

Use AWS CloudFormation StackSets with a stack that includes an AWS::GuardDuty::Detector resource, and apply it to the organization root OU.

CloudFormation StackSets with service-managed permissions deploy the GuardDuty detector automatically to every account in the organisation root OU, including future accounts as they join. This satisfies the "newly created accounts" constraint without custom orchestration, since StackSets handle account enrolment and Region targeting natively, minimising operational overhead.

Attach an S3 bucket policy that denies access unless the aws:SourceVpce condition matches the approved VPC endpoint IDs.

The aws:SourceVpce condition in an S3 bucket policy restricts access to requests arriving through the approved VPC endpoint IDs, directly satisfying the requirement that access originate from approved VPCs. It also enforces TLS-only access when paired with aws:SecureTransport.

Configure AWS Network Firewall in the central security account to inspect traffic to the S3 endpoints and allow only encrypted traffic.

AWS Network Firewall in the central security account inspects traffic traversing the VPC endpoints, allowing only encrypted sessions to the S3 data lake. This satisfies the in-transit encryption mandate at the network layer, complementing identity-based bucket policy controls.

AWS Organizations Service Control Policies (SCPs)

SCPs define the maximum permissions for principals in member accounts, letting the DevOps team deny EC2 RunInstances outside approved Regions or with unapproved AMIs. They enforce these controls centrally across every account in AWS Organizations.

Use AWS Transit Gateway with a central appliance VPC, and configure route tables to send traffic to the firewall for inspection.

Transit Gateway centralises inter-VPC routing, so a single attachment to the appliance VPC lets the firewall inspect cross-account traffic without full-mesh peering or per-VPC route churn. Route tables steer traffic through the security account, satisfying the inspection mandate while keeping operational complexity low.

Apply tags to resources and enable cost allocation tags in Billing and Cost Management.

Cost allocation tags let Billing and Cost Management split consolidated-billing charges by business unit, since each unit already has its own account. Activating the tags in Billing and Cost Management enables filtering cost reports by business unit without building additional tooling, meeting the no-overhead constraint.

Use an SCP to deny the iam:UpdateAccountPasswordPolicy action and deploy a password policy using CloudFormation StackSets.

Denying `iam:UpdateAccountPasswordPolicy` via an SCP prevents member accounts from weakening the policy, while CloudFormation StackSets deploys the 14-character minimum consistently across every account. This pairing satisfies the preventive, automatically enforced control the security team requires, since SCPs block the API call outright rather than merely detecting drift afterwards.

Partition the S3 bucket by date (e.g., year/month/day) and use Athena partition projection.

Date-based prefixes let Athena prune irrelevant objects, scanning only the partitions a query touches. Partition projection removes the need for a Glue crawler or MSCK REPAIR, so recent-log queries stay fast and cheap, meeting both the cost and speed constraints.

Create separate OUs for each country (US, UK, Germany) under Control Tower. Apply SCPs at each country OU that deny access to resources in other country OUs.

Separate country OUs let you attach SCPs that deny cross-country resource access, enforcing data residency at the organisation level. SCPs applied per OU create a hard permission boundary, so UK roles cannot reach German accounts and vice versa, satisfying the residency requirement.

Apply service control policies (SCPs) to deny the creation of IAM roles with overly broad permissions, such as 'Action: *' and 'Resource: *'.

SCPs set the maximum permissions available to every principal in member accounts, so denying role creation with Action:* and Resource:* blocks overly broad IAM roles at the organisation level. This enforces least privilege centrally, regardless of individual account configuration.

Enable IAM Access Analyzer to review and identify IAM roles that grant permissions to external principals or have unused permissions.

IAM Access Analyzer continuously monitors resource policies and generates findings for roles granting access to external principals, plus unused-permission findings from CloudTrail activity. This directly satisfies the least-privilege constraint by surfacing over-permissive and unused IAM roles across every account in the organization, enabling remediation.

The management account must have an IAM role (StackSetsAdminRole) with permissions to create stack instances in member accounts.

StackSets use a service-managed or self-managed model; here the management account needs a role trusted by CloudFormation to assume into each member account and create stack instances. Without that cross-account role, deployments fail because CloudFormation cannot obtain credentials in the target accounts.

The execution role in member accounts must have permissions to create the resources defined in the CloudFormation template (e.g., VPC, subnets).

StackSets assume a role in each member account to create resources there, so that execution role must itself permit the VPC, subnet and related actions the template defines. Without these permissions, CloudFormation fails during resource creation regardless of the management account's own rights.

The management account must have permission to assume the execution role in member accounts (via IAM trust policy).

StackSets in the management account call sts:AssumeRole against a role in each target account. That role's trust policy must name the management account as a trusted principal, otherwise every stack operation fails at the assume-role step before any resource is created.

Enable cross-zone load balancing on the Gateway Load Balancer to distribute traffic evenly across all firewall instances in all Availability Zones.

Gateway Load Balancer distributes flows per Availability Zone by default, so instances in under-utilised zones stay idle while others saturate, causing latency and packet loss. Enabling cross-zone load balancing spreads flows across every firewall instance in all zones, restoring even scaling and low latency.

The KMS key policy does not grant the Firehose delivery stream permission to use the key for encryption.

Firehose encrypts the delivery stream with the KMS key, so its role needs kms:GenerateDataKey and kms:Decrypt in the key policy. If the policy omits the Firehose service principal, encryption calls fail and deliveries return AccessDenied even though CloudWatch Logs sends data correctly.

Create an SCP that denies ecs:RunTask and ecs:CreateService unless the networkConfiguration.awsvpcConfiguration.subnets are in the approved VPC.

SCPs provide preventive controls at the organization level.

Backup and Restore: Data is backed up to S3 and restored when needed.

This correctly describes the Backup and Restore strategy, which has the highest RTO/RPO but lowest cost.

Pilot Light: Core services run at minimal capacity, scaled up during failover.

This correctly describes Pilot Light, where a core set of services (like a pilot light) is always on and scaled up during failover.

Warm Standby: A scaled-down version of the environment runs and can be scaled up quickly.

This correctly describes Warm Standby, which has faster recovery than Pilot Light because more resources are already running.

Multi-Site Active/Active: Fully functional environment runs in multiple Regions, traffic routed via Route53.

This correctly describes Multi-Site Active/Active, which provides the lowest RTO/RPO but highest cost.