AWS Control Tower & Account Factory
Recap: From Permission Ceilings to Automated Landing Zones
Day 2 established that an SCP is a permission ceiling rather than a grant: the default FullAWSAccess policy permits everything until you attach explicit Deny statements, and the effective permission for any call is the intersection of the identity policy and every SCP that applies to the account. That model is powerful but it is also entirely manual. Someone has to create each account, place it in the right OU, attach the right SCPs, and remember to exempt global services from a region-restriction SCP so that IAM, Route 53, CloudFront, and Support keep working. At ten accounts that is tedious. At two hundred accounts, across a dozen teams, with auditors asking who changed what and when, it is a governance failure waiting to happen.
Control Tower extends the SCP mechanics from Day 2 by automating the scaffolding those policies attach to. It provisions the accounts, creates the OUs, attaches the guardrails, and keeps the whole structure in a known-good state as accounts are added and removed. The SCPs you learned to write by hand are still the enforcement mechanism underneath; Control Tower is the factory that stamps out the structure they live in.
Foundations You'll Need Today
An AWS account is a hard boundary, not just a login
When you sign up for AWS, you get an account: a container that owns everything you create, and a boundary that nothing crosses by default. Resources in one account cannot see or talk to resources in another unless you deliberately connect them, and the bill, the access rules, and the audit trail all belong to that one account. That isolation is the point. It means a mistake in a development account cannot quietly reach into production, and it means you can hand a team its own account without handing them the keys to yours.
The catch is that isolation has a cost. If every team gets its own account, someone has to create those accounts, decide who can log into each one, and keep track of what exists where. That is the problem the rest of this section is about.
AWS Organizations and organizational units (OUs)
AWS Organizations is the service that lets you group many accounts under one umbrella. The umbrella itself is called the organization, and it has a single management account that owns the arrangement and pays the consolidated bill. Inside the organization you sort accounts into folders called organizational units, or OUs. An OU is not a technical container the way an account is; it is a grouping you define, usually by purpose or by team, so that you can apply rules to everything inside it at once.
The reason OUs matter is that rules attached to an OU flow down to every account in it, including accounts in OUs nested inside it. That inheritance is what makes a structure like "Security," "Infrastructure," "Workloads," and "Sandbox" useful: you write a rule once at the right level and it applies everywhere it should, without you having to remember each account individually.
Service control policies (SCPs)
An SCP is the rule you attach to an OU or an account to limit what anyone inside it is allowed to do. The important thing to understand is that an SCP never grants permission. It only takes permission away. Even if a user in an account has an IAM policy that says "you may delete this database," an SCP that forbids the delete action will still block it, because the effective permission is the intersection of what the identity policy allows and what every SCP above it permits.
By default an organization comes with a policy called FullAWSAccess attached everywhere, which permits everything and therefore changes nothing. SCPs only start doing work when you attach explicit Deny statements. This is why SCPs are described as a ceiling rather than a grant: they define the highest level of access anyone in that part of the organization can ever reach, and the actual permissions people hold sit somewhere at or below that ceiling.
AWS Config and the idea of a compliance rule
AWS Config is a service that watches the resources in your accounts and records what they look like and how they change over time. You give it rules — statements like "S3 buckets must not be publicly readable" — and Config evaluates each resource against those rules and reports whether it passes or fails. Crucially, Config observes; it does not block. If a bucket is made public, Config notices and records the fact, but the bucket is still public.
That distinction between observing and blocking is the whole reason Config and SCPs are used together. An SCP can stop an action from happening at all, but it cannot tell you that a resource is currently in a bad state. Config can tell you exactly that, but it cannot stop the change. A governance system needs both: something to prevent the worst actions, and something to detect and report everything else.
What a "landing zone" means
A landing zone is the pre-built foundation you drop new accounts into. Rather than creating an account and then remembering to wire up its logging, its access rules, its network, and its guardrails by hand, a landing zone is the assembled set of accounts, OUs, policies, and monitoring that already has all of that in place. The term comes from the idea that a new account should be able to "land" safely the moment it is created, with the organization's standards already applied.
Building a landing zone by hand is possible, and many organizations start that way. The trouble is that hand-built foundations drift: someone edits a policy directly, a new account gets created without the usual setup, and the structure slowly stops matching what anyone intended. With that grounding, here's why Control Tower exists and what problem it actually solves.
1. Why This Is on the Exam
SAP-C02 Domain 1 covers organizational complexity, and the exam consistently tests whether you can distinguish a landing zone that was assembled by hand from one that is managed by Control Tower. The distinction matters because the two have different failure characteristics, different upgrade paths, and different answers to the question "how do we onboard a new team next quarter?" A scenario that describes a company with forty AWS accounts, a compliance requirement to prove that no account can disable CloudTrail, and a mandate to onboard acquisitions within days is describing a problem that hand-built Organizations cannot solve at the required velocity.
The exam also tests the boundary between Control Tower and the tools that surround it. Candidates routinely confuse Control Tower with Organizations, with AWS Config, with Service Catalog, and with the Account Factory products. Each of those is a component of the landing zone rather than a substitute for it, and the exam will offer them as distractors in scenarios where the correct answer is the composed whole. Understanding which layer owns which responsibility is the difference between picking the right answer and picking the plausible one.
There is a third reason this day matters, and it is the one that trips up experienced architects. Control Tower is opinionated. It makes choices on your behalf — which accounts exist, which OUs they live in, which regions are governed, how drift is detected — and those choices constrain what you can do later. A scenario that asks you to add a custom OU structure, or to govern only two regions, or to bring an existing account under management, is testing whether you know where Control Tower's opinions end and your own configuration begins. The exam rewards candidates who can articulate those boundaries precisely.
Finally, the Account Factory for Terraform (AFT) material appears in scenarios about platform engineering teams. When a question describes a team that already manages infrastructure as code and wants account provisioning to flow through the same pipeline, AFT is usually the intended answer. Recognizing that signal — existing Terraform investment plus a desire for account vending — is worth several questions across the exam.
2. How Control Tower Actually Works
Control Tower is not a single service so much as an orchestration layer over several. When you enable it in a management account, it creates a landing zone: a set of accounts, OUs, SCPs, Config rules, and IAM roles that together form a governed baseline. The landing zone is built inside your existing AWS Organization, not beside it. Control Tower reads the Organization's structure, creates the OUs it needs, and enrolls accounts into them. If you already have OUs, Control Tower will work with them, but it will also create its own — the Security OU, for example, which holds the log-archive and audit accounts.
The three accounts Control Tower creates are worth naming precisely because exam questions hinge on their roles. The log-archive account receives CloudTrail logs and Config snapshots from every enrolled account, giving you a central, tamper-resistant record. The audit account holds cross-account IAM roles that security teams use to inspect other accounts without needing credentials in each one. The management account is the Organization's root account, and Control Tower runs from there. None of these three should host workloads; they exist to observe and govern the accounts that do.
Guardrails are the enforcement layer, and they come in two implementation flavors. Preventive guardrails are SCPs — the same mechanism from Day 2 — and they block actions outright. Detective guardrails are AWS Config rules, and they detect when a resource drifts out of compliance without preventing the action. A guardrail like "disallow public read access to S3 buckets" is detective: the bucket can be made public, but Config will flag it and the compliance dashboard will show the account as non-compliant. A guardrail like "disallow root user access keys" is preventive: the SCP blocks the API call. Knowing which guardrails are preventive and which are detective tells you what a scenario's compliance evidence will actually look like.
Drift detection is the mechanism that keeps the landing zone honest. Control Tower continuously compares the actual state of the OUs, SCPs, and accounts against the expected state. If someone edits an SCP outside Control Tower, or moves an account between OUs manually, the drift is detected and surfaced. Some drift can be repaired automatically; some requires you to re-register the OU or account. This is the operational cost of the automation: you gain a known-good baseline, but you also gain a system that will notice when you deviate from it.
Account Factory is the provisioning engine. When you create a new account through Control Tower, Account Factory uses a Service Catalog product to vend it, applying a baseline template that includes the account's OU placement, its guardrails, and any network configuration you have defined. The account is created, enrolled, and governed in one operation. AFT takes that same idea and moves the trigger into Terraform: instead of clicking through the console, you open a pull request against a repository, and a pipeline runs the account creation and customization. The account still lands in the same landing zone with the same guardrails; only the interface changes.
3. The Core Decision Boundary: Managed Landing Zone vs. Hand-Built Organizations
The fork that most Control Tower scenarios hinge on is whether the organization should adopt a managed landing zone at all. Control Tower is not free in operational terms: it imposes structure, it requires you to work within its OU model, and it adds a layer of tooling that your team must learn. The question is whether the governance guarantees it provides are worth that cost. For an organization with a handful of accounts and a single team, hand-built Organizations with a few well-written SCPs is often the simpler answer. For an organization with dozens of accounts, multiple teams, and an auditor asking for evidence, the manual approach becomes a liability.
The second fork is where customization lives. Control Tower gives you a baseline; almost every real deployment needs more than the baseline. The question is whether that additional configuration is applied through Control Tower's own extension points — customizations for accounts, custom guardrails, AFT — or bolted on outside the landing zone. Configuration applied outside the landing zone is invisible to drift detection and will eventually be flagged or overwritten. Configuration applied through the extension points is governed, versioned, and reproducible. The exam tends to reward the answer that keeps customization inside the managed boundary.
| Consideration | Hand-built Organizations | Control Tower landing zone |
|---|---|---|
| Setup effort | High per account; manual OU and SCP wiring | One-time enablement, then automated per account |
| Guardrail enforcement | Whatever SCPs you remember to attach | Mandatory guardrails always on; elective per OU |
| Compliance evidence | Assembled manually from Config and CloudTrail | Built-in dashboard and drift detection |
| Account provisioning | Manual or custom scripts | Account Factory (console) or AFT (pipeline) |
| Flexibility | Unlimited; you own every decision | Constrained by Control Tower's OU and region model |
| Ongoing maintenance | Grows linearly with account count | Centralized; drift detected automatically |
The practical rule is that Control Tower pays for itself once account count and compliance requirements cross a threshold that varies by organization but is usually somewhere in the low tens. Below that, the overhead of the landing zone can exceed the benefit. Above it, the manual approach's failure modes — missed SCPs, ungoverned accounts, no drift detection — become the dominant risk. Exam scenarios rarely give you an exact account count, so read the compliance and velocity signals instead: auditors, acquisitions, rapid team onboarding, and multi-team governance all point toward the managed landing zone.
4. Configuration Modes and Their Tradeoffs
Once you have decided to adopt Control Tower, the next set of choices determines how much of your organization it governs and how much customization you layer on top. The first choice is which regions are governed. Control Tower can govern all regions or a selected subset, and the choice has real consequences. Governing all regions gives you uniform guardrails everywhere but can be operationally heavy and may conflict with teams that legitimately need to work in regions you did not anticipate. Governing a subset reduces overhead but leaves ungoverned regions where the same guardrails do not apply — a gap that auditors will notice.
The second choice is how accounts are provisioned. The console-based Account Factory is the default: you fill in a form, and Control Tower vends the account. It is simple and requires no pipeline infrastructure, but it is a manual step, and manual steps do not scale to a platform team's workflow. AFT replaces the form with a Terraform module and a pipeline. The tradeoff is real: AFT requires you to stand up and maintain the pipeline, the repository structure, and the Terraform state, but it gives you version-controlled account definitions, peer review, and the ability to apply customizations as code. Teams already invested in Terraform find AFT's cost trivial; teams without that investment may find it a significant new surface to operate.
The third choice is how much customization to apply per account. Control Tower's baseline is deliberately minimal. Real accounts need VPCs, IAM roles, logging configuration, and often service-specific setup. AFT supports this through account customizations — Terraform that runs after the account is vended — and through a global customization that applies to every account. The tradeoff is between consistency and flexibility: a global customization guarantees every account gets the same baseline, while per-account customizations let teams diverge. Divergence is where drift and inconsistency creep in, so the exam tends to favor the answer that maximizes shared baseline and minimizes per-account special cases.
The fourth choice is whether to enroll existing accounts. Control Tower can bring accounts that already exist under management, but the process is not seamless. Existing accounts may have resources that violate guardrails, OUs that do not match Control Tower's model, or configurations that conflict with the baseline. Enrollment is possible but requires remediation first. A scenario that describes a large existing estate and asks how to bring it under governance is testing whether you know that enrollment is a migration project, not a toggle.
5. Sizing, Limits and Quotas
Control Tower's limits are mostly organizational rather than performance-related, and the exam tests them because they determine what a landing zone can and cannot do. The most commonly cited constraint is the number of accounts an organization can have, which is governed by AWS Organizations quotas rather than Control Tower itself; Control Tower inherits those limits. The practical implication is that very large enterprises may need to think about whether a single organization is the right unit, or whether multiple organizations with separate landing zones are warranted.
OU depth is another constraint worth knowing. Control Tower supports nested OUs, but the nesting depth is limited, and the guardrail model becomes harder to reason about as depth increases. A common design mistake is to create a deep OU hierarchy that mirrors the org chart; the guardrails then have to be attached at multiple levels, and the effective permission for any account becomes the intersection of many SCPs. Shallow, purpose-based OUs — Security, Infrastructure, Workloads, Sandbox — are easier to govern and easier to explain to auditors.
Guardrail counts are bounded by the number of controls Control Tower offers, which grows over time as AWS adds new ones. The relevant exam point is not the exact number but the distinction between mandatory, strongly recommended, and elective guardrails. Mandatory guardrails are always on and cannot be disabled; strongly recommended guardrails are on by default but can be turned off; elective guardrails are off by default and enabled per OU. A scenario that asks how to enforce a specific control will usually be answerable by identifying which category the control falls into.
| Limit / quota | What it constrains | Practical implication |
|---|---|---|
| Accounts per organization | Total account count | Very large estates may need multiple organizations |
| OU nesting depth | Hierarchy complexity | Prefer shallow, purpose-based OUs |
| Mandatory guardrails | Always-on controls | Cannot be disabled; design around them |
| Elective guardrails | Per-OU optional controls | Enable selectively to match compliance needs |
| Governed regions | Where guardrails apply | Ungoverned regions are a compliance gap |
| AFT pipeline concurrency | Account vending throughput | Bulk onboarding may need batching |
AFT has its own operational limits that matter in practice. The pipeline that vends accounts has a finite concurrency, so onboarding hundreds of accounts at once requires batching rather than a single large run. The Terraform state for account customizations is stored centrally, and that state becomes a critical dependency: if it is lost or corrupted, re-applying customizations becomes difficult. These are not exam trivia so much as operational realities that shape how a platform team plans a large onboarding.
6. Failure Modes and What They Look Like in Production
The most common failure mode is drift that nobody notices until an audit. Someone edits an SCP directly in the Organizations console, or moves an account between OUs to work around a guardrail, and the landing zone's expected state no longer matches reality. The symptom is a compliance dashboard that shows an OU or account as drifted, often weeks after the change. The first diagnostic move is to compare the current OU and SCP configuration against Control Tower's expected state and identify what changed; the repair is usually to re-register the OU or account, which re-applies the baseline.
A second failure mode is guardrail conflict. A team enables an elective guardrail that blocks an action their workload legitimately needs, and the workload starts failing in ways that are hard to trace because the error surfaces as an access denied rather than a guardrail message. The symptom is a sudden spike in access-denied errors in one account after a guardrail change. The first diagnostic move is to check the account's effective SCPs and Config rules against the failing API call, then either disable the elective guardrail or add a documented exception. This is why elective guardrails should be enabled deliberately rather than in bulk.
A third failure mode is the ungoverned account. An account is created outside Control Tower — perhaps by a team with Organizations permissions — and never enrolled. It has no guardrails, no centralized logging, and no drift detection. The symptom is an account that appears in the Organization but not in the Control Tower dashboard. The first diagnostic move is to reconcile the Organization's account list against Control Tower's enrolled accounts and enroll the stragglers. Preventing this in the first place usually means restricting who can create accounts directly in Organizations.
A fourth failure mode is AFT pipeline failure during account vending. The account may be created but the customizations fail to apply, leaving an account that exists but is not fully configured. The symptom is an account that appears in the dashboard but is missing expected resources. The first diagnostic move is to inspect the pipeline run logs and the Terraform state for that account, then re-run the customization. Because the account already exists, re-running is usually safe, but the state must be consistent or the re-run will fail in confusing ways.
7. The Operational and SRE Angle
From an SRE perspective, Control Tower is infrastructure that governs infrastructure, and it deserves the same monitoring discipline as any other critical system. The landing zone's health is measured by drift: how many OUs and accounts are in the expected state, and how quickly drift is detected and repaired. A useful SLO is something like "no account remains drifted for more than one business day," with the drift dashboard as the primary signal. Alarms should fire when drift is detected, not when it is repaired, so that the team has a chance to investigate the cause rather than just the symptom.
The second operational concern is the AFT pipeline itself. It is a deployment pipeline, and it should be monitored like one: success rate, duration, and failure reasons. A pipeline that fails silently leaves accounts half-configured, and the failure may not surface until the account's workload misbehaves. Alarms on pipeline failure, plus a runbook that describes how to inspect and re-run a failed customization, are the minimum. The runbook should also cover the case where the Terraform state is inconsistent, since that is the failure that most often requires manual intervention.
The third concern is the guardrail change process. Enabling or disabling an elective guardrail is a change to the organization's security posture, and it should go through the same review as any other production change. The operational pattern that works is to treat guardrail changes as code: define them in the AFT repository, review them in a pull request, and apply them through the pipeline. This gives you a record of who changed which guardrail and when, which is exactly what an auditor will ask for. It also means a guardrail change can be rolled back the same way any other code change can.
Finally, the landing zone has a recovery story that should be tested. If the management account is compromised or the landing zone is misconfigured, how do you restore governance? The answer usually involves the log-archive account, which holds the historical record, and the audit account, which holds the cross-account roles. A game day that simulates the loss of the management account's configuration is a reasonable exercise, and it will surface dependencies — like the AFT state bucket — that are easy to overlook until they are needed.
8. Edge Cases and Exam Gotchas
The first gotcha is the management account's special status. It is not subject to SCPs, which means guardrails do not constrain it. Control Tower runs from the management account, and the management account should not host workloads. A scenario that asks where to place a workload that must be exempt from guardrails is testing whether you know that the management account is the only place SCPs do not apply — and that using it for that purpose is an anti-pattern.
The second gotcha is the difference between preventive and detective guardrails. A scenario that asks how to prevent an action will be answered by a preventive guardrail (an SCP); a scenario that asks how to detect and report an action will be answered by a detective guardrail (a Config rule). Confusing the two leads to answers that detect when the question asked to prevent, or vice versa. The exam uses this distinction frequently because it maps cleanly onto the difference between blocking and observing.
The third gotcha is the relationship between Control Tower and Organizations. Control Tower does not replace Organizations; it builds on top of it. The Organization still exists, still has its own quotas, and still has its own management account. A scenario that asks how to centrally manage billing across accounts is an Organizations question, not a Control Tower question, even though both are involved in the landing zone.
The fourth gotcha is the enrollment of existing accounts. Control Tower can enroll accounts that already exist, but the process requires the account to meet certain prerequisites and may require remediation. A scenario that describes a large existing estate and asks for the fastest path to governance is testing whether you know that enrollment is not instantaneous and that a phased approach is usually required.
The fifth gotcha is the AFT versus Account Factory distinction. Account Factory is the console-based provisioning mechanism built into Control Tower; AFT is the Terraform-based extension. A scenario that mentions an existing Terraform investment is pointing at AFT; a scenario that mentions a team without infrastructure-as-code maturity is pointing at the console-based Account Factory. The two are not interchangeable, and the exam expects you to pick based on the team's existing tooling.
9. Control Tower vs. the Services It Gets Confused With
Control Tower sits at the center of a cluster of services that each do part of the job, and the exam will offer them as alternatives. Organizations is the foundation: it creates accounts and OUs and provides the SCP mechanism. Control Tower uses Organizations but adds the landing zone, guardrails, and drift detection. A scenario that asks how to consolidate billing is an Organizations question; a scenario that asks how to enforce a baseline across accounts is a Control Tower question.
AWS Config is the detection engine underneath detective guardrails. Control Tower manages Config rules on your behalf, but Config itself is a general-purpose resource compliance service that can be used independently. A scenario that asks how to detect non-compliant resources in a single account is a Config question; a scenario that asks how to enforce compliance across an organization is a Control Tower question. The distinction is scope: Config observes, Control Tower governs.
Service Catalog is the mechanism Account Factory uses to vend accounts. It is a general-purpose catalog for approved products, and Control Tower uses it as an implementation detail. A scenario that asks how to offer a curated set of approved infrastructure to developers is a Service Catalog question; a scenario that asks how to provision governed accounts is a Control Tower question. The exam rarely asks about Service Catalog directly in this context, but it may appear as a distractor.
| Service | Primary job | Pick it when… |
|---|---|---|
| AWS Organizations | Account and OU management, SCPs, consolidated billing | You need the foundation, not the governance layer |
| Control Tower | Automated landing zone, guardrails, drift detection | You need a governed multi-account baseline at scale |
| AWS Config | Resource compliance detection | You need to detect non-compliance, not prevent it |
| Service Catalog | Curated product catalog | You need to offer approved infrastructure to teams |
| Account Factory (console) | Manual account vending | Your team has no IaC pipeline and needs accounts now |
| AFT | Pipeline-driven account vending and customization | Your team already manages infrastructure as Terraform |
The rule of thumb that resolves most scenarios is to ask what layer the question is operating at. If it is about the existence of accounts and OUs, it is Organizations. If it is about the governance of those accounts, it is Control Tower. If it is about detecting a specific resource's compliance, it is Config. If it is about how accounts are provisioned, it is Account Factory or AFT depending on the team's tooling. Naming the layer before choosing the service is the habit that makes these questions tractable.
Hands-on Lab: Layering AFT Customizations on a Control Tower Baseline (45 min)
This lab walks through how Account Factory for Terraform layers custom account customizations on top of Control Tower's baseline guardrails. You will not need a live AWS account to follow the reasoning, but if you have a sandbox organization, the steps map directly onto the AFT setup process. The goal is to understand the boundary between what Control Tower provides and what AFT adds, because that boundary is where most exam scenarios live.
Step 1 — Establish the baseline. Start by listing what Control Tower provides before AFT is involved: the landing zone, the Security OU with log-archive and audit accounts, the mandatory guardrails, and the Account Factory product in Service Catalog. Write these down as the "baseline layer." Everything AFT does sits on top of this layer and must not conflict with it. If a customization you plan would violate a mandatory guardrail, it cannot be applied — the guardrail wins.
Step 2 — Identify the customization surface. AFT exposes two customization points: account customizations, which run per account after it is vended, and global customizations, which run for every account. Map your requirements onto these two surfaces. A VPC that every account needs is a global customization. A service-specific IAM role that only the data platform accounts need is an account customization. The mapping exercise is the point: it forces you to decide what is truly universal versus what is team-specific.
Step 3 — Write the customization as Terraform. For each customization, write the Terraform that creates the resources. The key constraint is that the Terraform runs with the permissions AFT has in the target account, which are themselves bounded by the account's guardrails. If your Terraform tries to create a resource that a guardrail blocks, the apply will fail. This is the mechanism by which guardrails constrain customization: they do not prevent you from writing the Terraform, they prevent it from succeeding.
Step 4 — Wire the pipeline. AFT's pipeline is triggered by changes to the account request repository. When a new account request is merged, the pipeline vends the account through Account Factory, then runs the global customization, then runs the account-specific customization. Trace this sequence and note where failures can occur: account vending can fail, the global customization can fail, and the account customization can fail. Each failure leaves the account in a different state, and the runbook should describe how to recover from each.
Step 5 — Test the guardrail interaction. Deliberately write a customization that attempts an action a guardrail blocks — for example, creating an S3 bucket with public access when a guardrail forbids it. Run the pipeline and observe the failure. The failure should surface as an access-denied error in the Terraform apply, and the account should be left in a partially configured state. This exercise teaches you what guardrail conflicts look like in practice, which is the failure mode most likely to appear in a real deployment.
Step 6 — Document the boundary. Finally, write a short document that states, for your organization, which configuration lives in Control Tower and which lives in AFT. The rule is that anything that must be enforced across all accounts belongs in Control Tower guardrails; anything that configures resources within an account belongs in AFT. Configuration that lives outside both — applied manually or by a separate tool — is ungoverned and will eventually drift. The document is the artifact that keeps the boundary explicit as the organization grows.
Scenario Question Drills (20 min)
Q1. A company has 60 AWS accounts and an auditor has asked for evidence that no account can disable CloudTrail logging. Which approach provides that evidence most directly?
Q2. What is the key difference between a mandatory and an elective Control Tower guardrail?
Q3. A platform team already manages all infrastructure as Terraform and wants new AWS accounts to be provisioned through their existing pull-request workflow. What should they use?
Q4. Which accounts does Control Tower create as part of the landing zone, and what is the log-archive account's role?
Q5. A team enables an elective guardrail that blocks an action their workload legitimately needs, and the workload starts failing with access-denied errors. What is the first diagnostic move?
Q6. An account appears in the AWS Organization but not in the Control Tower dashboard. What does this indicate?
Q7. Which statement about the management account in a Control Tower landing zone is correct?
Q8. A scenario asks how to detect — not prevent — that an S3 bucket in an enrolled account has been made public. Which guardrail type applies?
Q9. A company wants to bring 200 existing AWS accounts under Control Tower governance. What is the most accurate characterization of this effort?
Q10. Which service provides the underlying account and OU structure that Control Tower builds on?
Q11. An AFT pipeline run creates an account but the account customization fails. What state is the account in, and what is the recovery step?
Q12. Which of the following is the best SLO for a Control Tower landing zone?
Q13. A team wants to apply a VPC configuration to every account that Control Tower vends. Where should this configuration live?
Q14. Which statement best describes the relationship between Control Tower and AWS Config?
Q15. A company governs only two AWS regions in Control Tower, but a team launches resources in a third region. What is the governance consequence?
Peek into Tomorrow
Control Tower solves the problem of provisioning and governing accounts, but it leaves a question unanswered: once those accounts exist, how do the humans who work in them actually get access? The landing zone creates the structure, and the guardrails constrain what can be done inside it, but neither of those things gives an engineer a way to log in. The default answer — an IAM user in each account — is exactly the anti-pattern that multi-account governance is supposed to eliminate. It multiplies credentials, it makes offboarding a manual scavenger hunt, and it gives you no central place to revoke access when someone leaves.
Tomorrow's topic addresses that gap directly. IAM Identity Center replaces per-account IAM users with permission sets mapped to SAML federation from an external identity provider, auto-provisioning an IAM role into each assigned account. The open question today's material leaves is how those permission sets interact with the guardrails you just learned to configure: a permission set grants access, but the SCP still caps it, and the two have to be designed together. The interesting part is what happens when a permission set and a guardrail disagree — and which one wins.
Sources
- AWS Control Tower User Guide — What Is AWS Control Tower?
- AWS Control Tower User Guide — How AWS Control Tower Works
- AWS Control Tower User Guide — Controls (Guardrails)
- AWS Control Tower User Guide — Account Factory
- AWS Control Tower User Guide — Account Factory for Terraform (AFT)
- AWS Control Tower User Guide — Detect and Resolve Drift
- AWS Organizations User Guide — What Is AWS Organizations?
- AWS Config Developer Guide — What Is AWS Config?
- AWS Well-Architected Framework — Security Pillar