Parks leadership needs a new AWS account for a recreation-registration project. How should the account be created so it stays inside the municipal landing-zone governance model?
Select an answer to reveal the explanation.
Short Explanation
New city projects still go through the badge office, not a side door with a spare key under the mat. Use the landing-zone account-vending pipeline so baselines, SCPs, and logging attach on day one — skip orphan console accounts.
Full Explanation
Parks leadership needing a new AWS account for recreation registration should vend that account through the landing-zone Account Factory or Control Tower pipeline rather than creating an unmanaged console orphan. Factory-vended accounts inherit OU placement, SCPs, logging baselines, and security tooling automatically so the recreation project starts inside municipal governance. Bolting controls onto an orphaned account later is slower, riskier, and frequently incomplete when project deadlines loom.
Having an intern create a personal AWS account with a Gmail login and later inviting it without baselines produces an orphan that misses organization CloudTrail, SCPs, and Identity Center standards. Cloning an old sandbox by sharing root credentials over chat spreads root secrets and configuration debt into a supposed new project account. Opening a new account outside Organizations so SCPs and logging never apply deliberately escapes the landing zone the city invested in.
Exam caveat: Account Factory and Control Tower account vending is the governed creation path on SAP-C02; ad hoc personal accounts are distractors. Operational check: request the parks account via Account Factory into the correct OU, confirm Identity Center access, organization trail delivery, and SCP attachment before any recreation workloads launch.