Amazon SAP-C02: Organizational Complexity & Multi-Account Strategy — Study Guide
Part of the AWS Solutions Architect Professional SAP-C02 — Study Guide. Practice with verified answers in the Amazon exam hub, or take timed practice tests on ExamRoll.io.
Multi-account strategy and account vending
A multi-account strategy begins with a clear separation of responsibilities: security and audit, shared networking, production workloads, and sandbox or developer accounts. Using AWS Organizations with either AWS Control Tower or a custom landing zone enforces this separation from day one. Control Tower’s Account Factory provides an account vending pattern that automates account creation, baseline IAM roles, VPC templates, and guardrails, while a custom landing zone built from CloudFormation/CDK and Service Catalog offers more flexibility for bespoke networks and governance. The primary trade-off is operational overhead versus blast-radius reduction: more accounts increase management surface area (automation, cross-account roles, billing visibility) but limit domain compromise exposure and simplify per-account compliance. Networking choices—VPC sharing with AWS Resource Access Manager, Transit Gateway hub-and-spoke, or isolated VPCs with VPC peering—drive cost and latency trade-offs. Shared services (DNS, NAT, Active Directory) often live in a networking or shared-services account; account vending should automatically attach new accounts to these shared resources or provision delegated VPCs. Plan quotas and automation: centralize pipelines for baseline artifacts so account scale doesn’t multiply manual toil.
Governance: SCPs, Control Tower guardrails, and organizational policies
Governance in a multi-account AWS environment depends on policy enforcement at the organization level and on delegated runtime controls. Service Control Policies (SCPs) set the ceiling for allowed actions across accounts; they are powerful but unforgiving—deny rules at the root OU prevent even administrators from creating service-linked roles or using services unless explicitly allowed. Control Tower offers prebuilt guardrails (mandatory, strongly recommended, elective) that implement common SCPs and Config rules, but it can be restrictive for advanced service patterns. The design decision centers on centralized vs delegated governance: a strict root-level deny-list maximizes compliance but increases friction for product teams and automation, while permissive baselines with permission boundaries and IAM role controls enable faster developer velocity. Logging and auditing policies (organization CloudTrail, AWS Config aggregator, Security Hub and GuardDuty delegated administrators) must be enforced from the management account to ensure immutable audit trails. A pragmatic approach is layered governance: organization SCPs for high-impact restrictions, permission boundaries for developer scope, and automated guardrails applied by landing-zone CI/CD to maintain consistency without manual gating.
Security boundaries: cross-account roles, KMS, and resource policies
Cross-account access is a core pattern and must be implemented with least privilege and strong trust controls. The common pattern delegates access via IAM roles in each account that trusted principals assume with STS: roles for CICD deployment, monitoring (CloudWatch/SSM), and third-party integrations should require MFA where appropriate and use external IDs for partner access. Resource-based policies on S3, SQS, and KMS keys enable direct cross-account access, but KMS adds complexity: a KMS key policy must explicitly allow the trusting account’s principals and services, and grants or grants-with-constraints may be needed for temporary access. Using a centralized KMS key in the logging or security account simplifies centralized encryption but creates operational coupling and potential availability considerations; per-account keys reduce blast radius but multiply key rotation and grant management. Common traps include SCPs inadvertently denying KMS or service-linked-role creation, bucket policies that conflict with SCPs, and forgetting to add the delegation role to Config/CloudTrail in the collector account. Design decisions should weigh administrative simplicity, least privilege, and cross-account latency.
Centralized logging, billing, and automation patterns
Centralized logging and billing are the backbone of enterprise visibility. An organization CloudTrail with trails delivered to an S3 bucket in a centralized security or audit account ensures tamper-evident event capture; supplement with CloudWatch Logs subscription filters to Kinesis Data Firehose for analytics, and aggregate Config data with an aggregator to the same account. Cost visibility requires consolidated billing in Organizations, Cost Explorer, Budgets, and Cost and Usage Reports delivered centrally; tag governance and automated tag enforcement via Config rules improve chargeback accuracy. Automation patterns that scale across accounts commonly use a shared CI/CD pipeline or deployment account that assumes cross-account deployment roles, or CloudFormation StackSets with a delegated administrator for mass provisioning. Use Systems Manager Automation and State Manager for cross-account patching and configuration, but remember each account must grant necessary roles and SSM permissions. Trade-offs balance centralization and latency: central aggregation reduces duplicated storage and simplifies analysis but creates network and availability dependencies; distributed logging duplicates data but isolates failures. Plan for retention, lifecycle rules, cross-region replication for DR, and encryption key management consistent with compliance requirements.
Practical Problem: Use-Case Scenario
Scenario: Contoso Media operates an enterprise AWS environment with Organizations and Control Tower in place. They have a management account, a shared-services networking account, and 20 member accounts running production, staging, and developer workloads across two Regions.
Challenge: Contoso needs to onboard 15 new project accounts quickly while ensuring centralized logging, appropriate SCP guardrails, automated network connectivity to the shared-services account via Transit Gateway, and deployment pipelines that do not require manual IAM setup per account.
Recommended Approach:
- Use Control Tower Account Factory or an automated AWS Organizations API workflow to vend accounts with a baseline CloudFormation/CDK template that registers the account in AWS Config, enables an organization CloudTrail pointing to the audit account S3 bucket, and applies required tags.
- Attach SCPs at the OU level that enforce high-impact denies (for example, deny cross-region key deletion and disallowed regions) while keeping development-permission OUs less restrictive; validate SCPs in a sandbox before broad application.
- Configure Transit Gateway in the shared-services networking account and create attachments for each new account’s Transit Gateway VPC attachment using Infrastructure-as-Code and a delegated admin or cross-account role the vending process assumes to automate attachment creation and route propagation.
- Provision a centralized CI/CD deployment pipeline in a tooling account that uses cross-account IAM roles (assume-role) created by the account-vending process; use CloudFormation StackSets (delegated admin) or cross-account CodePipeline actions for initial baseline provisioning and ongoing updates.
Rationale: Automating account vending with baseline artifacts enforces governance while minimizing manual steps; delegating network and deployment tasks via cross-account roles and Transit Gateway centralizes shared services, reduces blast radius, and scales onboarding without sacrificing security or auditability.
Practice these questions → · Timed practice on ExamRoll.io →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
Pass your exam →