Task 1.4: Design a multi-account AWS environment.

• AKeep replicating the S3 data into a bucket in each consumer account and have every account catalog its copy with its own Glue crawler

  Incorrect

  S3 Replication copies objects asynchronously into other buckets, including buckets owned by other accounts, so every consumer account would keep its own duplicate of the data, which the standard forbids.

• BGrant the consumer accounts access to the tables in a Data Catalog resource policy and to the data prefixes in the S3 bucket policy

  Incorrect

  Catalog resource policies and bucket policies grant access to named Data Catalog resources and S3 objects. The grants do not follow classification labels or reach individual columns, and every newly classified table would mean editing both policies.

• CLoad the tables into an Amazon Redshift cluster in the platform account and share them with each consumer account through Redshift datashares

  Incorrect

  Datashares give other accounts live access without copying data between warehouses, but loading the lake with COPY puts a second copy of the data into Redshift tables, and the analysts would no longer query the lake with Athena.

• DRegister the S3 locations with Lake Formation, assign LF-Tags to the catalog resources, and grant tag-based permissions to the accounts

  Correct

  LF-Tags can be assigned to databases, tables and columns, and a grant on an LF-Tag expression covers every resource with a matching tag, including tables tagged later. Cross-account grants keep the data in place, the consumer's data lake administrator grants the shared data to its own principals, and Athena queries it through resource links.

The constraints are no duplicate data, access by classification down to the column, automatic coverage of newly classified tables, and consumer-side control of who sees the shared data. Replication duplicates the lake, Redshift loading duplicates it too, and catalog and bucket policies grant access by resource name rather than by label. Lake Formation tag-based access control shares the catalog resources across accounts by LF-Tag, and each consumer's data lake administrator grants them on to its own analysts.

• ACreate a multi-Region organization trail with log file validation turned on that delivers to the bucket in the log archive account

  Correct

  An organization trail logs events for all accounts in the organization, member accounts cannot modify or delete it, and log file validation lets auditors detect changes to delivered log files.

• BDeploy a multi-Region trail to every account with a CloudFormation StackSet and point all trails to the bucket in the log archive account

  Incorrect

  A trail created in a member account belongs to that account, so its administrators can stop or delete it.

• CCreate an AWS Config aggregator in the log archive account that collects configuration history from all accounts and Regions

  Incorrect

  AWS Config records resource configuration changes, not the API activity that CloudTrail management events capture.

• DStream each account's CloudTrail event history to Amazon CloudWatch Logs with a subscription filter to the log archive account

  Incorrect

  Event history is per account and per Region and is not a trail that member administrators are prevented from changing; it does not give tamper-evident log files either.

An organization trail is created once, covers all accounts including new ones, and cannot be changed by members; log file validation provides the integrity proof.

• AGive each team a VPC in its own account and attach every VPC to a shared transit gateway

  Incorrect

  This works but multiplies VPCs and transit gateway attachments, and the application teams would own and be able to change their own route tables.

• BPeer each application team's VPC with the central VPC and route the application subnets through it

  Incorrect

  Peering still gives every team its own VPC, which the company wants to avoid, and the teams would manage their own routing.

• CShare the subnets of the central VPCs with the application accounts through AWS RAM

  Correct

  With VPC sharing, participant accounts create their own resources in subnets that the owner shares, while the owner keeps control of the VPC resources, which participants cannot modify.

• DCreate a cross-account IAM role in the network account that lets the teams launch resources there

  Incorrect

  Resources would be created in the network account itself, so teams would lose separate ownership and billing, and the role would need broad permissions in the central account.

Centrally managed networks with workloads in separate accounts is VPC sharing: the owner shares subnets, participants launch into them, and only the owner changes the network.

• AAn SCP attached to the organization root that denies organizations:LeaveOrganization

  Correct

  An SCP limits every principal in the member accounts it applies to, including the root user of those accounts, so a deny on LeaveOrganization stops any of them from leaving.

• BA resource control policy that denies S3 access when the requesting principal is not in the organization, with exceptions for AWS service principals

  Correct

  Resource control policies set the maximum permissions on resources in member accounts, whoever the requesting principal is, so they can stop external access even when a bucket policy allows it.

• CAn SCP that denies s3:GetObject to every principal whose aws:PrincipalOrgID is not the organization's ID

  Incorrect

  SCPs apply only to IAM users and roles in the member accounts. They have no effect on principals from outside the organization.

• DA permissions boundary on every IAM role in the member accounts that denies organizations:LeaveOrganization

  Incorrect

  A permissions boundary limits only the IAM entities it is attached to. It does not apply to the root user, and administrators can create roles without it.

• EA tag policy that requires every S3 bucket to carry an owner tag with an approved organization value

  Incorrect

  Tag policies standardize tags. They do not grant or deny access to a bucket.

SCPs cap what principals in your accounts can do; RCPs cap what can be done to resources in your accounts, including by outsiders. One requirement is about principals, the other about resources.

• ARegister the governance account as the delegated administrator of IAM Identity Center and express the controls as permission sets

  Incorrect

  Delegated administration of IAM Identity Center lets a member account manage workforce access to accounts. Permission sets grant access to users; they are not organization policies attached to OUs.

• BKeep a role in the management account for the team, limited to Organizations policy actions and assumed from the governance account

  Incorrect

  A narrower role is still a role in the management account used for day-to-day work, which the standard forbids. AWS recommends using the management account only for tasks that must be performed there.

• CIn the management account, add an Organizations delegation policy that lets the governance account manage only SCPs and tag policies

  Correct

  A resource-based delegation policy lets specified member accounts perform policy actions that are otherwise available only to the management account, and the organizations:PolicyType condition limits which policy types the governance account can create, update and attach.

• DRegister the governance account as the AWS Firewall Manager administrator and define the controls as Firewall Manager policies

  Incorrect

  Firewall Manager centrally applies AWS WAF rules, Shield Advanced, security groups, Network Firewall and DNS Firewall policies across accounts. It does not create or attach SCPs or tag policies.

The management account should be used only for what must happen there, and Organizations can delegate its own policy management to a member account through a resource-based delegation policy. Scoping that policy with the organizations:PolicyType condition keeps backup policies with the team that owns them. Firewall Manager and IAM Identity Center have their own delegated administrators, but neither manages SCPs or tag policies.

• AKeep eu-central-1 and eu-west-1 as the only governed Regions and turn on the Region deny control in the landing zone settings

  Correct

  The landing zone Region deny control applies to every OU with the Control Tower baseline and is inherited by lower OUs. It denies requests in Regions that are not governed, keeps actions allowed in governed Regions, and exempts certain global services such as IAM and Organizations. Control Tower maintains the SCP behind it.

• BRemove every other Region from the landing zone's governed Regions so that Control Tower stops covering those Regions

  Incorrect

  Governed Regions decide where Control Tower baselines accounts and applies its controls. A Region that is not governed can still be used; its resources are simply outside Control Tower governance, so nothing is enforced.

• CAttach an SCP to the organization root that denies requests whose aws:RequestedRegion is not one of the two, exempting global services

  Incorrect

  A policy built on aws:RequestedRegion with a NotAction list of global services does enforce Region limits, but the team would write it and keep its list of exempted global services current itself, which it does not want to do.

• DFrom the management account, disable every Region except the two in the Region settings of each member account

  Incorrect

  Only opt-in Regions can be enabled or disabled. Regions launched before March 20, 2019 are enabled by default and cannot be disabled, so most Regions would stay usable.

Three constraints decide it: enforcement rather than reporting, coverage of future accounts, and no custom policy to maintain. Narrowing the governed Regions alone only changes where Control Tower governs, not where people can deploy. Disabling Regions works only for opt-in Regions. A hand-written SCP enforces the rule but leaves the team maintaining it. The landing zone Region deny control enforces the governed Regions in every enrolled account, current and future, with global services exempted and the policy managed by Control Tower.

• ACreate service-managed StackSets for the templates that target the OU with automatic deployment turned on

  Incorrect

  StackSets with automatic deployment push the same stacks into every account of the target OU. That suits a baseline the platform team controls, but developers could not launch their own stacks when a project needs one.

• BPublish the templates in a versioned S3 bucket that the OU can read, and grant developers CloudFormation and service permissions

  Incorrect

  A versioned bucket keeps the approved templates available, but developers would launch them with their own credentials, which needs permissions for CloudFormation and every service the stacks use, and they could deploy any other template too.

• CAdd the templates to Account Factory Customization blueprints in AWS Control Tower and apply them to the accounts in the OU

  Incorrect

  Account Factory Customization applies a blueprint of resources when an account is provisioned or updated through Account Factory. It standardizes accounts; it is not a catalog that developers browse to launch stacks for their projects.

• DAdd the templates to a Service Catalog portfolio with a launch constraint role and share it with the OU

  Correct

  A launch constraint makes Service Catalog launch with its own IAM role, so end users need only minimal permissions. A portfolio shared with an OU reaches all of its accounts without an import, and new product versions are available to everyone who has access to the portfolio.

The constraints are self-service launches, no direct resource permissions for developers, and versions that flow out centrally. StackSets and Account Factory Customization deploy what the platform team decides, not what a developer requests. A shared template bucket gives self-service but needs broad permissions. A Service Catalog portfolio shared with the OU, with a launch constraint role on each product, meets all three.

• ASubscribe the distribution list to the RSS feed of AWS Security Bulletins and retire the old addresses from the mail system

  Incorrect

  Security Bulletins publish public posts about security issues that AWS investigates, and the feed keeps the posts of the last 30 days. They are not the notices that AWS sends about a specific account, which still go to the stale contacts.

• BHave the root user of each member account sign in once and update the security contact on that account's Account page

  Incorrect

  A standalone account updates its own alternate contacts this way, and it would work here, but it means 150 root sign-ins, which the policy forbids, and it cannot be rerun as a script.

• CConfigure AWS User Notifications in the management account to forward security events to the distribution list

  Incorrect

  User Notifications is a central location for managing AWS notifications, but it does not change the alternate contacts recorded on each account, and this setup would run from the management account.

• DDelegate AWS Account Management to the security tooling account and call PutAlternateContact for every member account

  Correct

  Once trusted access for the Account Management service is turned on, a user in the management account or in a delegated admin account can update the alternate contacts of any member account through the console, the AWS CLI or the SDKs.

The constraints are central change, no management account in daily use, no root sign-ins and a repeatable script. The public bulletin feed and User Notifications keep the team informed but leave each account's contacts as they are. Root sign-ins would update the contacts but break the policy. A delegated admin for AWS Account Management can set the security alternate contact of every member account with PutAlternateContact from the security tooling account.

• AAn Amazon Inspector delegated administrator

  Incorrect

  Inspector scans for vulnerabilities; it does not configure Systems Manager.

• BRun Command executed in each account by hand

  Incorrect

  Running commands in each account by hand is the scripting work the team wants to avoid.

• CSystems Manager Quick Setup configured for the organization

  Correct

  Quick Setup configures frequently used services and features with recommended best practices, automating common tasks.

• DCloudFormation templates deployed separately in each account

  Incorrect

  Separate deployments must be repeated for every account and Region.

Recommended Systems Manager settings at organization scale come from Quick Setup.