6.1 - Centralized account management (Organizations, Control Tower, SCPs)
AWS Certified Security Specialty objective 6.1 covers running many accounts as one governed estate. Service Control Policies cap what member accounts may do and never grant anything, so an identity policy must still allow the action, an explicit Deny in any policy on the account's path wins, and inheritance intersects: if the root allows only S3 and EC2 while a child organizational unit allows only S3 and DynamoDB, accounts under it keep S3 alone. An allow-list design only works once FullAWSAccess is detached, an Allow with NotAction quietly leaves everything else permitted, SCPs do not restrict service-linked roles, a new cap applies as soon as the account moves organizational unit, and an SCP never constrains the management account, which is why an action denied org-wide still succeeded there. AWS Control Tower layers preventive controls that block a call against detective controls that report drift, provisions accounts through Account Factory into the right organizational unit, and reports drift when someone moves an account by hand. You enable trusted access and register a delegated administrator so security services run outside the management account, an organization trail cannot be stopped by a member, and aws:PrincipalOrgID or aws:PrincipalOrgPaths scopes resource policies without listing account IDs. Expect governance scenarios.
An SCP denied it org-wide but the call still succeeded = it ran in the management account, where SCPs do not apply. Allow-list of three services = detach FullAWSAccess first, otherwise nothing is restricted. Trust every current and future account of the org in a policy = condition on aws:PrincipalOrgID.
Practice questions
1. A company wants a preconfigured multi account environment with a centralized log archive account, an audit account and a set of default controls. Which service delivers this out of the box?
- AWS Systems Manager, which centralizes patching and inventory across every registered instance of the fleet
- AWS Control Tower (correct answer)
- Amazon Inspector
- AWS Resource Access Manager
Control Tower builds a landing zone on top of Organizations: it creates the log archive and audit accounts, applies baseline controls and enrolls new accounts through Account Factory. Systems Manager manages instances, not account structure. Inspector scans workloads for vulnerabilities. Resource Access Manager shares individual resources between accounts and creates nothing.
2. A security team attaches an SCP to the organization root that denies all actions outside two approved regions. Some engineers still launch resources in a third region. Which explanation is technically correct?
- SCPs need up to twenty four hours to propagate to member accounts, so the policy is not active yet and the launches will start failing on their own once replication finishes
- SCPs only filter console traffic and never apply to API or CLI calls
- An SCP attached to the root is advisory and must be duplicated on every organizational unit to take effect
- They are working in the management account, which SCPs never restrict (correct answer)
The management account is never affected by SCPs, even by one attached to the root, which is exactly why sensitive workloads must not live there. SCPs take effect within moments, they apply to every call path including API and CLI, and a policy attached to the root already covers all OUs below by inheritance.
3. A security team wants to run GuardDuty and Security Hub for the whole organization without operating from the management account. What is the recommended arrangement?
- Register a dedicated security account as delegated administrator for each service (correct answer)
- Give every security engineer an IAM role in the management account with AdministratorAccess so that they can operate the services from there directly
- Enable the services separately in each member account and read the consoles one by one
- Share the organization root credentials with the security team leads
Delegated administration moves the operational console of a service into a member account while the management account keeps only organization governance. Working from the management account concentrates blast radius on the account no SCP can restrict, per account enablement loses the aggregated view, and sharing root credentials is never acceptable.
4. An organization must apply stricter controls to accounts hosting regulated workloads than to sandbox accounts. What is the cleanest structure?
- A single organizational unit containing everything, with per resource tags carrying the compliance level and a nightly script that reconciles them
- One AWS account per workload with no organizational unit at all
- Separate organizational units, each with its own SCPs (correct answer)
- One SCP per IAM user, attached directly to the user
Grouping accounts into OUs by control requirement lets one SCP cover a whole class of accounts and lets new accounts inherit the right ceiling on the day they are created. Tags are not an enforcement boundary, accounts without OUs cannot inherit anything, and SCPs attach to roots, OUs and accounts only, never to a user or a role.
5. A team wants an allow list strategy where accounts in an OU may use only three services. What must be done besides attaching the allow list SCP?
- Enable the allow list feature flag in the Organizations settings page for the whole organization
- Attach an identity policy in every account granting the three services, since the SCP will not grant them
- Detach the FullAWSAccess policy from that OU and from the accounts inside it (correct answer)
- Recreate the accounts, because an account cannot switch from deny list to allow list
Every OU and account carries FullAWSAccess by default; effective SCP permissions are the intersection down the tree, so as long as that wide open policy stays attached the narrow allow list is diluted at that level. There is no allow list toggle in Organizations, and while identity policies are indeed still required, the question asks what makes the allow list itself take effect. Accounts never need recreation to change strategy.
6. Before a service such as Config or CloudTrail can act across every account of an organization, what must be done in Organizations?
- Nothing, any service reaches every member account as soon as the organization exists
- Enable trusted access for that service (correct answer)
- Create a shared IAM user replicated in every member account so that the service can authenticate on each of them in turn
- Move every member account under the same organizational unit
Trusted access authorizes a service to create the service linked roles it needs in member accounts and to operate organization wide. Access is never implicit, replicating IAM users is the opposite of the intended design and creates long lived credentials, and OU placement changes policy inheritance but grants no service any organizational reach.