Exam Context #
- Exam: AWS SAP-C02
- Scenario Category: Governance Automation
- Decision Focus: Control Tower managed governance vs custom multi-account architecture
The SAP-C02 exam tests your ability to evaluate when AWS Control Tower provides appropriate governance automation versus when custom implementations are necessary. These scenarios require understanding both the capabilities and limitations of managed landing zones, as well as the operational trade-offs involved in each approach.
👉🏻 Read more pillar articles at Pillars
Every enterprise AWS journey starts with the same question: “How do we set up accounts the right way from day one?”
Control Tower is AWS’s opinionated answer. But SAP-C02 doesn’t just test whether you know Control Tower exists—it tests whether you understand when it’s the right choice, where its boundaries are, and why certain governance patterns succeed or fail at scale.
This pillar covers the architectural thinking behind Landing Zones and the practical decision framework for Control Tower that SAP-C02 demands.
Exam Context & Decision Framing #
Before diving into architecture, understand how SAP-C02 positions Control Tower within the broader governance landscape.
Why Control Tower Appears in SAP-C02 #
Control Tower occupies a specific niche in the SAP-C02 exam:
It’s not about the service itself—it’s about recognizing when automated governance accelerates enterprise outcomes versus when it constrains them.
| Exam Focus | What SAP-C02 Tests |
|---|---|
| Speed vs flexibility trade-off | When to accept Control Tower’s opinions vs build custom |
| Governance layering | How Control Tower relates to Organizations, SCPs, Config |
| Enterprise readiness | Whether Control Tower fits existing organizational complexity |
| Compliance automation | How guardrails map to regulatory requirements |
Key insight: “Rapid, standardized multi-account governance” is the core keyword. When exam scenarios emphasize speed and standardization, Control Tower is likely the answer. When they emphasize customization or existing complexity, it’s likely not.
Typical Exam Triggers #
SAP-C02 uses specific scenario patterns to signal Control Tower questions:
| Scenario Pattern | Signal Strength | Typical Correct Answer |
|---|---|---|
| “New organization needs multi-account setup quickly” | Strong | Control Tower |
| “Startup scaling to enterprise, needs governance baseline” | Strong | Control Tower |
| “New business unit requires isolated accounts with standard controls” | Strong | Control Tower + Account Factory |
| “Acquired company needs to integrate into existing AWS organization” | Moderate | Depends on existing structure |
| “Highly regulated industry with custom compliance requirements” | Weak | Often custom Landing Zone |
| “Existing complex OU structure needs governance improvements” | Weak | Usually not Control Tower |
Exam trigger keywords:
- “Quickly establish” / “rapidly deploy”
- “Standardized governance” / “consistent baseline”
- “New accounts with security controls”
- “Automated account provisioning”
Anti-trigger keywords:
- “Existing complex organization”
- “Custom compliance framework”
- “Non-standard OU requirements”
- “Migrate existing governance”
What Is an AWS Landing Zone (Architectural View) #
Understanding the distinction between the concept and the implementation is crucial for SAP-C02.
Landing Zone ≠ Control Tower #
This is a fundamental distinction the exam tests:
| Concept | Definition | Relationship |
|---|---|---|
| Landing Zone | An architectural pattern for multi-account AWS environments | The what—design principles and components |
| Control Tower | AWS’s managed implementation of a Landing Zone | The how—one specific implementation |
| Custom Landing Zone | Self-built implementation using Organizations, CloudFormation, etc. | Alternative how—more flexible, more effort |
Analogy: Landing Zone is like “a house with proper foundation, plumbing, and electrical.” Control Tower is like “buying a pre-built house from a developer.” Custom Landing Zone is like “hiring an architect and building from scratch.”
SAP-C02 tests whether you can identify which approach fits a given scenario.
Core Components of a Landing Zone #
Regardless of implementation, every Landing Zone addresses these foundational elements:
| Component | Purpose | Implementation Examples |
|---|---|---|
| Account structure | Logical separation of workloads and responsibilities | OUs for Security, Infrastructure, Workloads, Sandbox |
| Network baseline | Consistent, secure network foundation | VPC templates, Transit Gateway, DNS |
| Identity baseline | Centralized authentication and authorization | IAM Identity Center, federated access |
| Logging & security baseline | Centralized visibility and compliance | CloudTrail, Config, Security Hub, GuardDuty |
| Guardrails | Preventive and detective controls | SCPs, Config Rules, automated remediation |
**[Mermaid Diagram: Landing Zone Logical Architecture showing:
- Top: Management Account (Organizations, Control Tower, Billing)
- Second tier: Core Accounts (Log Archive, Security/Audit, Network/Shared Services)
- Third tier: Organizational Units (Security OU, Infrastructure OU, Workloads OU, Sandbox OU)
- Bottom: Workload Accounts within each OU
- Arrows showing: CloudTrail logs flowing to Log Archive, Security Hub aggregating to Security Account, Network connectivity through Shared Services]**
Control Tower Architecture Deep Dive #
Control Tower implements the Landing Zone pattern with specific architectural decisions that SAP-C02 expects you to understand.
Control Plane vs Workload Plane #
Control Tower creates a clear separation:
| Plane | Accounts | Responsibilities | Access Pattern |
|---|---|---|---|
| Control Plane | Management Account | Organizations management, Control Tower operations, billing | Highly restricted; break-glass only |
| Governance Plane | Log Archive, Audit/Security | Centralized logging, security monitoring, compliance | Security team access; read-heavy |
| Workload Plane | All other accounts | Application workloads, development, production | Team-based access; day-to-day operations |
Exam insight: Questions often test whether you understand that the Management Account should have minimal direct workloads—it’s for governance, not applications.
Mandatory Accounts Explained #
Control Tower creates three accounts automatically. Understanding their roles is essential:
Management Account #
| Aspect | Detail |
|---|---|
| Purpose | Root of the organization; Control Tower operations |
| Contains | Organizations service, Control Tower dashboard, consolidated billing |
| Access | Extremely restricted; only organization administrators |
| Workloads | None recommended; governance only |
| Exam note | Never deploy applications here; it’s a control plane |
Log Archive Account #
| Aspect | Detail |
|---|---|
| Purpose | Immutable, centralized log storage |
| Contains | S3 buckets for CloudTrail, Config, and other logs |
| Access | Read-only for security team; write-only for log sources |
| Protection | S3 Object Lock, bucket policies preventing deletion |
| Exam note | Separation ensures logs survive account compromise |
Audit / Security Account #
| Aspect | Detail |
|---|---|
| Purpose | Security operations and compliance monitoring |
| Contains | Security Hub, GuardDuty aggregation, Config aggregator |
| Access | Security team; cross-account read access to all accounts |
| Role | Investigate, monitor, respond—not prevent (that’s SCPs) |
| Exam note | Also called “Security” account in some documentation |
| Account Type | Primary Responsibility | Who Accesses | Exam Trap to Avoid |
|---|---|---|---|
| Management | Organization governance | Org admins only | Don’t deploy workloads here |
| Log Archive | Immutable log storage | Security (read), Services (write) | Don’t give delete permissions |
| Audit/Security | Security monitoring | Security team | Don’t confuse with preventive controls |
Guardrails: Preventive vs Detective Controls #
Guardrails are Control Tower’s mechanism for enforcing governance. SAP-C02 frequently tests the distinction between guardrail types.
What Guardrails Really Are #
Guardrails are not a new AWS service—they’re a Control Tower abstraction over existing services:
| Guardrail Type | Underlying Mechanism | Behavior | Example |
|---|---|---|---|
| Preventive | Service Control Policies (SCPs) | Blocks actions before they happen | “Disallow changes to CloudTrail configuration” |
| Detective | AWS Config Rules | Detects non-compliance after the fact | “Detect whether S3 buckets have public access” |
Key insight: Preventive guardrails stop actions. Detective guardrails report violations. Both are necessary for comprehensive governance.
Guardrail Categories #
Control Tower organizes guardrails into three categories with different enforcement characteristics:
Mandatory Guardrails #
- Cannot be disabled
- Applied to all OUs managed by Control Tower
- Essential for Control Tower’s operation
- Examples: Disallow changes to Log Archive bucket policy, Disallow deletion of CloudTrail logs
Strongly Recommended Guardrails #
- Enabled by default, can be disabled
- Represent AWS security best practices
- Should only be disabled with clear justification
- Examples: Detect public S3 buckets, Detect unencrypted EBS volumes
Elective Guardrails #
- Disabled by default, opt-in
- Address specific compliance or operational needs
- Enable based on organizational requirements
- Examples: Detect EC2 instances without detailed monitoring, Disallow internet access for VPCs
| Category | Default State | Can Disable? | Typical Use |
|---|---|---|---|
| Mandatory | Enabled | No | Control Tower integrity |
| Strongly Recommended | Enabled | Yes (with justification) | Security best practices |
| Elective | Disabled | Yes (opt-in) | Specific compliance needs |
**[Mermaid Diagram: Guardrail Enforcement Flow showing:
- User attempts action (e.g., modify CloudTrail)
- Decision: Preventive guardrail exists?
- Yes → SCP blocks action → Action denied
- No → Action proceeds
- Action completes
- Detective guardrail evaluates
- Non-compliance detected?
- Yes → Config Rule triggers → Finding sent to Security Hub → Alert/remediation
- No → Compliant state recorded]**
Account Factory & Account Provisioning #
Account Factory is how Control Tower standardizes account creation—a frequent SAP-C02 topic.
How Account Factory Works #
Account Factory automates the “day zero” setup that every account needs:
| Step | What Happens | Customizable? |
|---|---|---|
| 1. Request | User requests account via Service Catalog | Account name, email, OU placement |
| 2. Creation | Organizations creates new account | Automatic |
| 3. OU Placement | Account placed in specified OU | Yes—within Control Tower OUs |
| 4. Baseline | CloudTrail, Config, IAM roles deployed | Limited—Control Tower managed |
| 5. Network | VPC baseline deployed (optional) | Yes—via Account Factory settings |
| 6. Identity | IAM Identity Center access configured | Yes—via Identity Center |
| 7. Guardrails | OU guardrails automatically apply | Inherited from OU |
Result: A new account that’s immediately compliant with organizational standards, ready for workloads.
Exam-Relevant Constraints #
SAP-C02 tests awareness of Account Factory limitations:
| Feature | Constraint | Exam Gotcha |
|---|---|---|
| OU placement | Must be a Control Tower-managed OU | Can’t place in OUs outside Control Tower |
| Region settings | Governed regions set at Control Tower level | Can’t enable non-governed regions per account |
| Email addresses | Must be unique; cannot reuse | Email management becomes operational overhead |
| Account naming | Follows organizational conventions | No automatic naming enforcement |
| VPC configuration | Uses Account Factory network settings | Limited customization without CfCT |
| Baseline timing | Takes 20-60 minutes | Not instant; plan for provisioning time |
| Existing accounts | Can enroll, but with limitations | Enrollment may fail if account doesn’t meet prerequisites |
Exam trap: “Account Factory can create accounts in any OU” is false. It only works within Control Tower’s managed OU structure.
Customizations for Control Tower (CfCT) #
Control Tower is opinionated by design. CfCT (Customizations for Control Tower) extends it for enterprise needs.
Why Customization Is Needed #
Control Tower’s “opinions” are intentional constraints:
| Control Tower Limitation | Enterprise Need | CfCT Solution |
|---|---|---|
| Standard VPC only | Custom CIDR ranges, complex networking | Deploy custom VPC templates |
| Basic IAM roles | Custom permission boundaries, roles | Deploy additional IAM resources |
| Limited Config Rules | Industry-specific compliance rules | Deploy custom Config Rules |
| No application baseline | Standard security agents, monitoring | Deploy baseline applications |
| Single region focus | Multi-region requirements | Extend to additional regions |
CfCT Architecture #
CfCT uses a GitOps-style pipeline to deploy customizations:
Pipeline-Based Deployment #
- Source: Git repository (CodeCommit or external)
- Trigger: Commit to main branch or manual
- Deployment: CodePipeline orchestrates rollout
CloudFormation StackSets #
- Mechanism: StackSets deploy resources across accounts/regions
- Targeting: By OU, by account, or by tag
- Updates: Changes propagate automatically
Lifecycle Hooks #
- Trigger: Account creation, OU change, guardrail update
- Action: Run custom Lambda functions or Step Functions
- Use case: Post-provisioning configuration, notifications
**[Mermaid Diagram: CfCT Deployment Flow showing:
- Git Repository (manifest.yaml, templates/)
- CodePipeline triggered by commit
- CodeBuild validates templates
- StackSets deployment stage
- Target selection: OUs (Security, Workloads) and/or specific accounts
- CloudFormation stacks deployed to target accounts
- Lifecycle events trigger additional customizations]**
Control Tower vs Custom Governance (Key SAP-C02 Decision) #
This is the core decision framework SAP-C02 tests. Knowing when to recommend Control Tower versus custom solutions separates professional-level answers.
When Control Tower Is the Right Answer #
| Scenario | Why Control Tower Fits |
|---|---|
| New AWS organization | No existing structure to conflict with |
| Standard compliance needs | SOC2, basic PCI—guardrails cover common requirements |
| Speed priority | Need governance in days, not months |
| Limited platform team | Managed service reduces operational burden |
| Greenfield workloads | No legacy patterns to accommodate |
| AWS-native strategy | Willing to adopt AWS’s opinions |
Exam signal: “The company is new to AWS and needs to establish a multi-account environment quickly with security best practices.”
When NOT to Use Control Tower #
| Scenario | Why Control Tower Doesn’t Fit |
|---|---|
| Complex existing Organizations | Control Tower may conflict with existing OU structure |
| Non-standard OU requirements | Control Tower enforces specific OU patterns |
| Custom compliance frameworks | Guardrails may not map to specific regulatory needs |
| Multi-cloud governance | Control Tower is AWS-only |
| Existing automation | May duplicate or conflict with existing pipelines |
| Specific region requirements | Control Tower’s governed regions may not match needs |
Exam signal: “The company has an existing AWS organization with 200 accounts and custom OU structure. They want to improve governance.”
Core Comparison Table #
| Dimension | Control Tower | Custom Landing Zone |
|---|---|---|
| Deployment speed | Days to weeks | Weeks to months |
| Flexibility | Limited—AWS’s opinions | Full—your design |
| Operational overhead | Lower—managed service | Higher—you maintain everything |
| Customization | Via CfCT (additional complexity) | Native—build what you need |
| Guardrail management | Simplified UI | Manual SCP + Config management |
| Account provisioning | Account Factory (Service Catalog) | Custom automation required |
| Existing org compatibility | Limited—may require restructuring | Full—works with any structure |
| Compliance mapping | Pre-built guardrails | Custom Config Rules + SCPs |
| Exam recommendation | New orgs, standard compliance, speed | Existing orgs, custom needs, flexibility |
Common SAP-C02 Scenarios & Patterns #
These scenarios represent typical exam question patterns. Understanding the decision logic helps you identify correct answers quickly.
Scenario: Rapid Multi-Account Bootstrap #
Situation: A startup has grown and needs to establish proper AWS governance. They currently have a single account with all workloads. They need to separate production, development, and security functions quickly.
Correct approach: Control Tower
Why:
- No existing multi-account structure to conflict with
- Speed is priority (“quickly”)
- Standard separation needs (prod/dev/security)
- Account Factory handles provisioning
Why other options fail:
- “Build custom Landing Zone” → Too slow for stated urgency
- “Use Organizations only” → Missing governance automation
- “Keep single account with IAM separation” → Doesn’t address account isolation requirement
Scenario: Post-Merger Governance #
Situation: Company A (using Control Tower) acquires Company B (100 accounts with custom OU structure). They need to integrate Company B’s accounts into unified governance.
Correct approach: Hybrid—evaluate Control Tower enrollment feasibility, likely custom integration
Why:
- Company B’s existing structure may not fit Control Tower’s OU requirements
- Enrollment of existing accounts has prerequisites
- May need to maintain parallel governance temporarily
Control Tower limitations here:
- Cannot easily restructure 100 accounts into Control Tower OUs
- Existing SCPs may conflict with Control Tower guardrails
- Account enrollment may fail for non-compliant accounts
Scenario: Regulated Industry #
Situation: A healthcare company needs to establish AWS governance that meets HIPAA requirements. They need audit trails, encryption enforcement, and access controls.
Correct approach: Control Tower + additional guardrails + custom Config Rules
Why:
- Control Tower provides baseline (CloudTrail, Config, centralized logging)
- Strongly recommended guardrails cover encryption, access controls
- Elective guardrails add specific controls
- CfCT can deploy HIPAA-specific Config Rules
Key insight: Control Tower is a starting point for compliance, not a complete solution. SAP-C02 tests whether you understand this nuance.
| Scenario | Recommended Approach | Why Other Options Fail |
|---|---|---|
| Startup needs quick governance | Control Tower | Custom is too slow; Organizations alone lacks automation |
| Post-merger integration | Evaluate + likely hybrid | Control Tower can’t easily absorb complex existing structures |
| HIPAA compliance | Control Tower + customization | Control Tower alone isn’t HIPAA-complete; custom alone is slower |
| Existing 500-account org | Custom improvements | Control Tower restructuring too disruptive |
| New subsidiary, standard needs | Control Tower + Account Factory | Fastest path to compliant accounts |
Integration with Other Governance Services #
Control Tower doesn’t operate in isolation. SAP-C02 tests understanding of how it integrates with the broader governance ecosystem.
Control Tower + Organizations #
| Aspect | Relationship |
|---|---|
| Dependency | Control Tower requires Organizations; creates OUs within it |
| OU management | Control Tower manages specific OUs; others can coexist |
| SCP application | Control Tower applies SCPs to its OUs; you can add more |
| Account creation | Account Factory uses Organizations API |
Exam note: Control Tower uses Organizations—it doesn’t replace it. You can have Control Tower-managed OUs alongside non-managed OUs.
Control Tower + SCP Design #
| Aspect | Relationship |
|---|---|
| Guardrail SCPs | Control Tower creates and manages preventive guardrail SCPs |
| Custom SCPs | You can add custom SCPs to Control Tower-managed OUs |
| Precedence | All SCPs apply; most restrictive wins |
| Management | Guardrail SCPs managed via Control Tower; custom SCPs via Organizations |
Exam trap: “Control Tower guardrails replace the need for custom SCPs” is false. Guardrails provide baseline; custom SCPs add organization-specific restrictions.
Control Tower + Security Hub #
| Aspect | Relationship |
|---|---|
| Aggregation | Security Hub aggregates findings to Audit account |
| Guardrail findings | Detective guardrails create Security Hub findings |
| Standards | Security Hub standards complement guardrails |
| Response | Security Hub enables automated remediation |
Control Tower + IAM Identity Center #
| Aspect | Relationship |
|---|---|
| Integration | Control Tower configures Identity Center automatically |
| Permission sets | Pre-built sets for Control Tower roles |
| SSO access | Users access accounts via Identity Center portal |
| Federation | Can integrate with external IdP |
**[Mermaid Diagram: End-to-End Governance Stack showing:
- Layer 1 (Identity): IAM Identity Center → External IdP (optional)
- Layer 2 (Organization): AWS Organizations → OUs → Accounts
- Layer 3 (Preventive): SCPs (Guardrails + Custom)
- Layer 4 (Detective): Config Rules → Security Hub → CloudWatch/SNS
- Layer 5 (Logging): CloudTrail → Log Archive Account
- Layer 6 (Response): Security Hub → EventBridge → Lambda/SSM
- Arrows showing data flow between layers]**
Exam Traps & Anti-Patterns #
SAP-C02 includes deliberately misleading options. Recognizing these patterns helps you eliminate wrong answers.
Common Wrong Assumptions #
| Wrong Assumption | Reality |
|---|---|
| “Control Tower is fully automatic—set and forget” | Requires ongoing management, updates, customization |
| “Control Tower works with any OU structure” | Has specific OU requirements; may conflict with existing structures |
| “Guardrails replace all SCP design” | Guardrails are baseline; custom SCPs often still needed |
| “Account Factory creates accounts instantly” | Takes 20-60 minutes; not suitable for real-time provisioning |
| “Control Tower manages all accounts automatically” | Only manages accounts in Control Tower OUs; others are unaffected |
| “Control Tower handles all compliance requirements” | Provides foundation; specific compliance needs additional controls |
How SAP-C02 Tests These Traps #
| Trap Pattern | How It Appears | Correct Response |
|---|---|---|
| “Use Control Tower for existing complex org” | Scenario describes 200+ accounts with custom structure | Recognize Control Tower isn’t ideal for complex existing orgs |
| “Control Tower alone for HIPAA” | Scenario requires specific compliance | Recognize additional controls needed beyond guardrails |
| “Account Factory for immediate provisioning” | Scenario requires accounts “immediately” | Recognize provisioning takes time; may need pre-provisioned accounts |
| “Guardrails prevent all security issues” | Scenario describes specific threat | Recognize guardrails are baseline, not comprehensive security |
Decision Checklist (Answering SAP-C02 Questions) #
Use this framework when encountering Control Tower questions on the exam.
5-Step Control Tower Decision Flow #
| Step | Question to Ask | If Yes | If No |
|---|---|---|---|
| 1. New or existing? | Is this a new AWS organization or greenfield? | Control Tower likely fits | Evaluate existing complexity |
| 2. Standard or custom? | Are governance needs standard (SOC2, basic security)? | Control Tower guardrails may suffice | Custom controls likely needed |
| 3. Speed or flexibility? | Is rapid deployment the priority? | Control Tower accelerates | Custom allows more flexibility |
| 4. Compliance intensity? | Are compliance requirements basic or highly specific? | Basic → Control Tower; Specific → Custom + Control Tower | Evaluate guardrail coverage |
| 5. Team capability? | Does the team have capacity for custom governance? | Custom is viable | Control Tower reduces burden |
| Decision Signal | Points Toward Control Tower | Points Away from Control Tower |
|---|---|---|
| “New organization” | ✓ | |
| “Existing complex structure” | ✓ | |
| “Quickly establish” | ✓ | |
| “Custom compliance framework” | ✓ | |
| “Standard security baseline” | ✓ | |
| “Non-standard OU requirements” | ✓ | |
| “Limited platform team” | ✓ | |
| “Existing automation pipelines” | ✓ |
Key Takeaways #
What You Must Remember for the Exam #
-
Control Tower is a governance accelerator, not a complete solution
- It provides baseline; customization addresses specific needs
- CfCT extends Control Tower for enterprise requirements
-
Landing Zone is the concept; Control Tower is one implementation
- Custom Landing Zones are valid alternatives
- Choice depends on existing structure and requirements
-
Guardrails = SCPs (preventive) + Config Rules (detective)
- Preventive guardrails block actions
- Detective guardrails report violations
- Both are necessary for comprehensive governance
-
Account Factory standardizes provisioning, not instant creation
- Takes 20-60 minutes per account
- Applies OU guardrails automatically
- Limited to Control Tower-managed OUs
-
Control Tower has opinions—that’s the point
- Opinions enable speed and consistency
- Opinions may conflict with existing structures
- Evaluate fit before adopting
-
SCPs remain the ultimate boundary
- Control Tower guardrails use SCPs
- Custom SCPs can supplement guardrails
- Most restrictive policy wins
-
Three mandatory accounts serve distinct purposes
- Management: Governance control plane
- Log Archive: Immutable audit storage
- Audit/Security: Security operations
Related Pillars & Scenarios #
Related Pillars #
- Multi-Account SCP Decision Logic — Deep dive into SCP design patterns
- IAM Identity Center & SSO Federation — Identity integration with Control Tower
- Security Hub & Compliance Monitoring — Detective controls and aggregation
- AWS Organizations Structure — OU design principles
Practice Scenarios #
- Scenario: Startup to Enterprise Governance — Control Tower adoption journey
- Scenario: Post-Acquisition Integration — Merging governance frameworks
- Scenario: Multi-Region Compliance — Control Tower with global requirements
Appendix: Quick Reference #
Control Tower Components Summary #
| Component | Purpose | Managed By |
|---|---|---|
| Landing Zone | Overall architecture pattern | Control Tower |
| Organizations | Account hierarchy | Control Tower + Admin |
| OUs | Logical account grouping | Control Tower + Admin |
| Guardrails | Preventive + detective controls | Control Tower |
| Account Factory | Standardized account provisioning | Control Tower |
| Log Archive Account | Centralized immutable logging | Control Tower |
| Audit Account | Security monitoring hub | Control Tower |
| CfCT | Customization framework | Admin (optional) |
Guardrail Quick Reference #
| Category | Count (approx.) | Default | Disable? | Mechanism |
|---|---|---|---|---|
| Mandatory | ~20 | Enabled | No | SCP + Config |
| Strongly Recommended | ~30 | Enabled | Yes | SCP + Config |
| Elective | ~200+ | Disabled | Yes (opt-in) | SCP + Config |
Account Factory Checklist #
| Requirement | Status |
|---|---|
| Unique email address | Required |
| Target OU in Control Tower | Required |
| IAM Identity Center configured | Required |
| Network baseline (optional) | Configurable |
| Provisioning time | 20-60 minutes |
| Governed regions | Inherited from Control Tower |