Security Foundations and Governance

Picture a fleet of accounts that all have to obey the same security rules. The instinct to log into each one and set things by hand is the trap this domain exists to kill: it does not scale and it drifts. Instead, AWS Organizations is the control plane, the single place that groups accounts into organizational units (OUs) under one management account and pushes rules down by inheritance. The mental model for this whole domain is a three-stage lifecycle: you GOVERN (set the org-wide guardrails and landing zone), you DEPLOY (ship identical, gated configuration to every account), and you VERIFY (continuously check that reality still matches the rules). The classic exam trap is reaching for an account-by-account answer, or confusing a guardrail with a grant. An organization policy such as a service control policy (SCP) or resource control policy (RCP) is a ceiling: it caps what the accounts below may do and never grants anything itself, so access still has to be granted separately by IAM. Keep that ceiling-versus-grant distinction and the lifecycle straight and most of this 14% domain answers itself.

Read this domain as a roter Faden through its three subtopics in that order. First, Multi-Account Governance is the GOVERN step: it sets the org-wide guardrails and the landing zone, covering Organizations, the SCP / RCP / declarative-policy family, AWS Control Tower, delegated administrators, and centralized root access. Reach for it whenever the question is about capping or shaping what whole accounts may do. Second, Secure Deployment is the DEPLOY step: it pushes consistent, gated configuration everywhere, covering infrastructure as code (IaC) with CloudFormation, policy-as-code gates (CloudFormation Guard, cfn-lint, Hooks), fan-out with CloudFormation StackSets and AWS Firewall Manager, secret handling via dynamic references, and sharing through AWS Resource Access Manager (RAM) and AWS Service Catalog. Reach for it whenever the question is how to get the same secure setup into many accounts without click-ops. Third, Compliance Evaluation is the VERIFY step: it continuously checks reality against the rules, covering AWS Config, AWS Security Hub, auto-remediation, and the evidence services (AWS Audit Manager, AWS Artifact, the Well-Architected Tool). Reach for it whenever the question is whether resources actually comply and how you prove it to an auditor.

The guiding instinct the exam rewards across this domain is to push control upward and outward so it cannot be skipped. A guardrail attached at the OU root beats a setting you have to repeat per account, because inheritance covers accounts that do not exist yet. A server-side gate such as a CloudFormation Hook beats a CI-only check, because a console operator cannot route around it. A delegated administrator running GuardDuty, Security Hub, and AWS Config beats operating from the management account, because guardrails never restrain the management account, so you keep it empty and locked down. The same instinct says share one resource through RAM rather than copy it, and pair every detection with remediation rather than leaving a known misconfiguration in place.