Design Solutions for Organizational Complexity practice questions

Create a support ticket to AWS to remove the account.

Why wrong: Incorrect. AWS does not require a support ticket to remove an account from an organization; the management account can close it directly.

Remove the account's payment method.

Why wrong: Incorrect. Removing the payment method alone does not suspend or close the account. The account must be closed to be removed from the organization.

The management account can directly remove the account without any prerequisites.

Why wrong: Incorrect. The management account cannot directly remove a member account that was created within the organization without first closing it. Only invited accounts can be removed directly.

Deploy AD in two Regions and use a VPN connection between the VPCs to replicate data.

Why wrong: Incorrect. VPN connections between VPCs do not require a transit gateway and do not integrate with a central inspection VPC.

Deploy a single AD domain in one Region and use AD replication over a VPC peering connection to a second Region.

Why wrong: Incorrect. VPC peering does not support transitive routing through an inspection VPC, and cross-Region peering alone cannot enforce firewall inspection.

Deploy AD in two Regions, attach both VPCs to a transit gateway in the primary Region, and use a transit gateway inter-Region peering attachment. Configure route tables to force traffic through the inspection VPC in the primary Region.

Why wrong: Incorrect. VPCs in different Regions cannot be attached to the same transit gateway; transit gateway attachments are regional. This architecture is not feasible.

Apply a service control policy (SCP) at the production OU level that denies s3:CreateBucket unless versioning and KMS encryption are specified in the request.

Why wrong: Incorrect. SCPs cannot enforce versioning during bucket creation because the versioning configuration is set after bucket creation using PutBucketVersioning. The headers mentioned in the explanation do not exist. SCPs can deny actions but cannot require specific API parameters that do not exist.

Use AWS CloudTrail to monitor bucket creation and send alerts to the security team.

Why wrong: Incorrect. CloudTrail alerts only notify after the fact; they do not prevent noncompliant buckets or enforce compliance automatically.

Create an IAM policy that requires versioning and KMS encryption when creating buckets, and attach it to all users.

Why wrong: Incorrect. IAM policies attached to users are not enforceable at the OU level and can be bypassed by users with sufficient permissions (e.g., admin). Additionally, versioning cannot be enforced at creation time via IAM conditions.

Use AWS Config rules to mark non-compliant instances and use AWS Lambda to terminate them.

Why wrong: AWS Config rules and Lambda functions provide reactive enforcement, not preventive control. They cannot prevent non-compliant instances from being launched.

Use IAM policies to deny non-compliant instance types for the Production OU, and attach a different IAM policy to exception accounts.

Why wrong: IAM policies cannot be attached to OUs; they apply only to users, groups, or roles. SCPs are the correct mechanism for OU-level control.

Use an SCP to deny non-compliant instance types at the OU level, and use resource-based policies on exception accounts to allow them.

Why wrong: Incorrect because EC2 instances do not support resource-based policies. Exceptions must be implemented via SCP conditions, not resource-based policies.

Set the bucket policy to allow the source accounts to write logs, and enable default encryption on the bucket with the KMS key.

Why wrong: Default encryption alone does not grant the log delivery service access to use the KMS key.

Create an IAM role in the logging account and allow the source accounts to assume it, then configure the source accounts to use that role for logging.

Why wrong: S3 server access logging does not support assuming roles; it uses the bucket policy.

Configure the logging account's KMS key with a policy that allows the S3 service to use it, and set the bucket policy to allow the source accounts to write logs.

Why wrong: The S3 logging service uses the bucket owner's permissions, not the source account's.

{"Version":"2012-10-17","Statement":[{"Effect":"Deny","Action":"ec2:DeleteSecurityGroup","Resource":"*"}]}

Why wrong: Denies only ec2:DeleteSecurityGroup, which does not prevent modification of rules or attributes. Fails to meet requirement.

{"Version":"2012-10-17","Statement":[{"Effect":"Deny","Action":"ec2:ModifySecurityGroupRules","Resource":"arn:aws:ec2:*:*:security-group/*","Condition":{"StringEquals":{"ec2:Vpc":"arn:aws:ec2:*:*:vpc/*"}}}]}

Why wrong: Denies only ec2:ModifySecurityGroupRules, and uses a condition that targets all VPCs (wildcard), not specifically the default security group. Also misses other modify actions. Incorrect.

{"Version":"2012-10-17","Statement":[{"Effect":"Deny","Action":"ec2:CreateSecurityGroup","Resource":"*"}]}

Why wrong: Denies only ec2:CreateSecurityGroup, which does not prevent modification of existing security groups. Fails to meet requirement.

Use an SCP with an Allow effect for approved services.

Why wrong: This is incorrect because SCPs with an Allow effect do not grant permissions; they only filter permissions. Additionally, an Allow effect alone would not deny unapproved services.

Use an SCP with a Deny effect for unapproved services.

Why wrong: This is incorrect because it only denies specific unapproved services, but any unapproved service not listed is implicitly allowed by default, failing the requirement to allow only approved services.

Use an IAM policy with a Deny effect for unapproved services.

Why wrong: This is incorrect because IAM policies apply to users and roles, not to organizational accounts centrally. SCPs are the appropriate mechanism for organization-wide controls.

Use IAM policies with conditions to restrict deletion to certain IP addresses.

Why wrong: Using IAM policies with conditions is not an SCP strategy and does not provide organization-wide control. IAM policies are account-specific and can be overridden by account administrators.

Attach an SCP to the root that allows all actions, and rely on IAM policies in each account.

Why wrong: Attaching an SCP that allows all actions does nothing to restrict deletion; it essentially has no effect. Relying solely on IAM policies is insufficient because account administrators could change them.

Ensure that the SCPs are evaluated in the correct order, with deny statements taking precedence.

Why wrong: Incorrect. SCPs are not order-dependent; all SCPs are evaluated together and any explicit deny takes precedence regardless of order. This statement is misleading.

Attach an SCP that denies all actions except those necessary for CloudTrail and S3 operations.

Why wrong: Incorrect. SCPs cannot use 'deny all except' logic; they can only explicitly allow or deny actions. This strategy is not valid in AWS.

An SCP that denies s3:DeleteObject for all member accounts.

Why wrong: SCPs affect permissions of IAM principals, not bucket policies.

An SCP that denies s3:DeleteObject for all accounts except the management account.

Why wrong: SCPs cannot be applied to resources like S3 buckets.

A bucket policy that allows s3:DeleteObject only for the organizational unit containing the management account.

Why wrong: Bucket policies cannot reference organizational units directly.

All actions are allowed only if MFA is not used.

Why wrong: The condition denies when MFA is false.

Only the root user is required to use MFA.

Why wrong: SCPs do not affect root user.

All IAM users must use MFA to access the console, but API calls are not affected.

Why wrong: The SCP applies to all actions, including API calls.

Neither account.

Why wrong: Production account is affected.

Both accounts.

Why wrong: Management account is not affected.

The ManagementAccount (111111111111) only.

Why wrong: Management account is not affected.

Create an IAM role that all users must assume to create buckets, and attach a policy requiring encryption.

Why wrong: Roles cannot be enforced for all API calls across accounts.

Use AWS CloudTrail to monitor bucket creation and trigger a Lambda function to enable encryption.

Why wrong: This is reactive, not preventive.

Enable default encryption on each S3 bucket using a custom AWS Config rule.

Why wrong: This requires per-bucket configuration and is not centralized.

Use AWS CloudTrail to monitor cluster creation and alert the security team.

Why wrong: Incorrect. AWS CloudTrail only records API activity for auditing; it does not prevent the action.

Create an IAM policy that denies redshift:CreateCluster and attach it to the developers' IAM groups in each account.

Why wrong: Incorrect. IAM policies in each account require manual application and maintenance, and developers with sufficient privileges could modify them.

Use AWS Config rules to detect Redshift cluster creation and automatically delete them.

Why wrong: Incorrect. AWS Config rules can detect resource creation but cannot deny it; remediation requires additional services like Lambda.

Create a subscription filter in each member account's log groups that sends logs to the central S3 bucket.

Why wrong: CloudWatch Logs subscription filters cannot send logs directly to an S3 bucket. They require Kinesis Data Firehose or Lambda as a destination.

Apply an SCP that requires all log groups to export logs to the central bucket.

Why wrong: SCPs can control permissions but cannot enforce a positive action like exporting logs. They are not a direct mechanism for log centralization.

Use AWS CloudTrail to deliver logs to the central bucket.

Why wrong: CloudTrail delivers its own logs to S3, not all CloudWatch Logs from member accounts.

Use AWS CloudFormation StackSets to deploy AMI approval rules via EC2 launch templates.

Why wrong: Launch templates are not enforced; users can still launch instances without templates.

Use AWS Config with a custom rule that triggers a Lambda function to terminate non-compliant instances.

Why wrong: This is reactive, not preventive, and instances may run for a short time.

Create an IAM policy condition that only allows ec2:RunInstances if the AMI ID matches a list in the condition.

Why wrong: IAM policies have size limits and cannot handle a frequently changing large list.

Create IAM roles in each account that can be assumed from the central account with limited permissions.

Why wrong: This option centralizes management by allowing the central team to access child accounts; it does not delegate management to individual account administrators.

Share the root user credentials of each account with the respective administrator.

Why wrong: Sharing root credentials violates security best practices and undermines centralized governance.

Grant each account administrator full access to the management account.

Why wrong: Granting full access to the management account compromises centralized governance and security.

Use AWS Config aggregator to collect configuration data from all accounts into a central account.

Why wrong: Config aggregator collects configuration items, not logs; logs are delivered per account.

Enable VPC Flow Logs in each account and deliver them to a central CloudWatch Logs group.

Why wrong: VPC Flow Logs cannot be delivered across accounts to a central S3 bucket directly; they go to CloudWatch Logs or S3 per account.

Use AWS CloudTrail to log management events and set up a CloudWatch Events rule that triggers on StopLogging API calls.

Why wrong: A CloudWatch Events rule triggered by `StopLogging` API calls would only detect manual disabling of CloudTrail, but it would not enforce that all accounts have CloudTrail enabled in the first place, nor would it detect other methods of disabling logging, such as deleting the trail or modifying the S3 bucket policy. This option is tempting because it directly addresses the notification requirement for `StopLogging` events, which would be a correct approach if the sole goal were to alert on a specific API action rather than to enforce and audit a mandatory baseline across all accounts.

Use an SCP that requires all accounts to have a specific trust policy for CloudTrail. Use CloudTrail Insights to detect anomalous activity.

Why wrong: Trust policies are not applicable; CloudTrail Insights does not notify on trail disabling.

Deploy a Lambda function in each account that periodically checks CloudTrail status and sends an SNS message if disabled.

Why wrong: Periodic checks are inefficient and may miss short-term disabling.

Use AWS Config rules to detect unencrypted buckets and trigger a Lambda function to encrypt them retroactively.

Why wrong: Reactive approach; does not prevent creation of non-compliant buckets.

Deploy a CloudFormation StackSet that creates a bucket policy in each account requiring encryption.

Why wrong: Bucket policies do not override account-level permissions for bucket creation.

Create an IAM policy in each account that denies PutBucketEncryption unless the specified KMS key is used.

Why wrong: Requires manual per-account configuration and does not prevent root user actions.

Use AWS Config rules to detect non-compliant security groups and trigger a Lambda function to remove the offending rules.

Why wrong: Reactive; rules exist temporarily and removal may break connectivity.

Create an SCP that denies ec2:AuthorizeSecurityGroupIngress for SSH ports unless the CIDR is in an approved list.

Why wrong: SCPs cannot check the value of parameters like CIDR; they can only deny actions based on resource tags or other condition keys that are not available for security group rules.

Use AWS Firewall Manager to centrally manage security group rules across accounts.

Why wrong: AWS Firewall Manager's content audit policies enforce compliance against a static list of CIDRs within the policy itself, not against a dynamically managed whitelist stored externally—such as in AWS Systems Manager Parameter Store—meaning any change to approved ranges requires manually updating every policy. This fails the scenario’s need for a scalable, auditable mechanism where the approved CIDR list is centrally maintained and automatically applied across accounts. The option is tempting because Firewall Manager is explicitly built for centralised security group governance across AWS Organizations and provides compliance dashboards, making it ideal when the set of approved CIDRs is fixed and rarely updated.