4 of the 6 questions we have for this objective, shown with the answer and the reasoning.
Design a multi-account AWS environment
Dalby Energy governs 60 accounts with AWS Control Tower. Application teams deploy infrastructure only through AWS CloudFormation. The cloud center of excellence wants to stop any CloudFormation stack from creating an S3 bucket without versioning or an RDS instance without storage encryption, and wants the check to happen before the resource is provisioned so that no noncompliant resource ever exists. It wants a managed control rather than custom code.
Which type of Control Tower control should the solutions architect enable on the workload OUs?
- ADetective controls, which use AWS Config rules to flag noncompliant buckets and DB instances.Detective controls report resources after they are created, so noncompliant resources would exist until someone fixes them.
- BPreventive controls implemented as service control policies that deny s3:CreateBucket and rds:CreateDBInstance.SCPs evaluate API actions and condition keys, and they cannot inspect the full CloudFormation resource configuration such as bucket versioning. Denying the create actions outright would block all buckets and databases.
- CProactive controls, which use CloudFormation hooks to evaluate resource configuration in a stack before provisioning.Proactive controls are implemented as CloudFormation hooks that check resource properties during stack operations and fail the operation if the resource would be noncompliant.
- DAn AWS Config conformance pack with automatic remediation through AWS Systems Manager Automation.Remediation runs after the resource exists, and it requires building and maintaining remediation documents rather than using a managed control.
Why: AWS Control Tower offers three behaviors for controls. Preventive controls use SCPs or RCPs to block actions, detective controls use AWS Config rules to find noncompliance after the fact, and proactive controls use CloudFormation hooks to check resources before they are provisioned through CloudFormation. When deployment is standardized on CloudFormation and the requirement is that noncompliant resources never exist, proactive controls are the fit. Mature governance models combine all three types.
Design a multi-account AWS environment
Rookwood Telecom's site reliability team works in an account named observability-prod and supports 50 workload accounts in eu-west-1. Engineers need to search CloudWatch metrics, logs and X-Ray traces from all workload accounts from observability-prod without switching roles. Separately, compliance requires that application logs from every workload account be streamed in near real time to a central S3 bucket in the log-archive account for long-term retention.
Which two actions should the solutions architect take? Each correct answer presents part of the solution.
- AConfigure CloudWatch cross-account observability with observability-prod as the monitoring account, and link the workload accounts as source accounts through an organization-wide setup.Cross-account observability lets a monitoring account view and query metrics, logs and traces from linked source accounts without switching roles, and AWS Organizations can link all accounts automatically.
- BCreate a CloudWatch Logs destination in log-archive backed by Amazon Data Firehose that writes to the S3 bucket, and add subscription filters in the workload accounts that send log groups to that destination.Cross-account subscriptions stream log events in near real time to a destination in another account, and Firehose delivers them to S3 for retention.
- CSchedule a Lambda function in each workload account that calls CreateExportTask daily to copy log groups to the log-archive bucket.Export tasks are batch operations that run one at a time per account, so a daily export is not near real time and adds custom code in 50 accounts.
- DSend application logs to the CloudTrail organization trail so that they are stored in log-archive.CloudTrail records AWS API activity. It does not ingest application logs from CloudWatch Logs.
- ECreate an AWS Config aggregator in observability-prod to view metrics and logs from all accounts.Config aggregators collect resource configuration and compliance data, not CloudWatch metrics, logs or traces.
Why: Central logging usually has two separate goals: operational visibility and durable retention. CloudWatch cross-account observability addresses visibility by letting a monitoring account query telemetry from many source accounts in place. Streaming through subscription filters to a cross-account destination, with Firehose writing to S3 in a log archive account, addresses retention and keeps the logs outside the workload accounts' control. Export tasks, CloudTrail and Config each solve a different problem.
Design a multi-account AWS environment
Ellesmere Bank must keep all customer data in eu-west-1 and eu-central-1 to meet a data residency rule. Its organization of 140 accounts does not use AWS Control Tower. Workloads use global services such as IAM, Amazon CloudFront, Amazon Route 53 and AWS Support, and a break-glass role named OrgBreakGlass must keep full access in all Regions for incident response. The control must be preventive and centrally managed.
Which service control policy design should the solutions architect apply to the Workloads OU?
- AA Deny statement with Action "*" and a StringNotEquals condition on aws:RequestedRegion for eu-west-1 and eu-central-1.Global services such as IAM and CloudFront process requests in us-east-1, so this blocks them, and it also locks out OrgBreakGlass.
- BA Deny statement with NotAction listing the global services that must be exempt, a StringNotEquals condition on aws:RequestedRegion for eu-west-1 and eu-central-1, and an ArnNotLike condition on aws:PrincipalARN that excludes the OrgBreakGlass role.NotAction exempts global services, the aws:RequestedRegion condition denies everything else outside the two Regions, and the aws:PrincipalARN condition exempts the break-glass role. Both conditions must match for the deny to apply.
- CAn IAM permissions boundary in every account that allows actions only in eu-west-1 and eu-central-1.Permissions boundaries must be attached to each role and user in each account and can be bypassed by principals without a boundary, so they are not a central preventive control.
- DAn AWS Config rule in each account that detects resources outside the approved Regions and deletes them with automatic remediation.This is detective and reactive. Data could already have been written outside the approved Regions before remediation runs.
Why: Region restriction is a common governance requirement and is implemented with an SCP that denies requests based on aws:RequestedRegion. Because some global services are served from us-east-1 endpoints, the deny must use NotAction to exempt them, and a condition on aws:PrincipalARN can exempt a tightly controlled break-glass or automation role. SCPs do not affect the management account, so sensitive workloads should not run there. AWS Control Tower offers a Region deny control built on the same pattern for organizations that use it.
Design a multi-account AWS environment
Ingleby Retail has 85 accounts in AWS Organizations and must keep a record of all management API activity in every account and Region for seven years. The records must be stored in a bucket in the log-archive account, and administrators in member accounts must not be able to stop or delete the logging. New accounts must be covered automatically.
What should the solutions architect do?
- ACreate an AWS CloudTrail organization trail from the management account or a CloudTrail delegated administrator account, applied to all Regions, that delivers to an S3 bucket in log-archive with a bucket policy allowing CloudTrail to write.An organization trail logs events for all member accounts, including new ones, and member accounts can see but cannot modify or delete it. Delivering to the log-archive bucket centralizes the records.
- BCreate a multi-Region trail in each of the 85 accounts that delivers to the log-archive bucket, and add a new trail whenever an account is created.Per-account trails can be stopped or deleted by account administrators and require extra work for each new account.
- CRely on the CloudTrail event history in each account and export it to log-archive monthly.Event history keeps only 90 days of management events per Region and account, and a manual monthly export is not reliable.
- DCreate an AWS Config aggregator in log-archive that collects configuration history from all accounts.AWS Config records resource configuration changes, not a full record of management API activity and who made each call.
Why: A CloudTrail organization trail is the standard way to centralize API activity logging across an organization. It is created once, applies to every current and future member account, and cannot be altered from member accounts. Combining it with a bucket in a dedicated log archive account, S3 Object Lock or lifecycle rules for retention, and log file validation produces a tamper-resistant audit record. Event history and Config aggregators serve different needs.