A municipality’s sandbox accounts for students and vendors regularly overspend. Leadership wants notifications and the option to apply spend controls when budgets are exceeded. Which design best fits org cost governance?
Select an answer to reveal the explanation.
Short Explanation
Sandboxes are where curiosity meets the credit card. Budgets with actions yell early and can slam the brakes—notify first, then optionally clamp the account—without shutting down every lab by default.
Full Explanation
Sandbox accounts used by students and vendors are frequent sources of surprise spend in a municipality because experimentation is encouraged while financial guardrails are often weak. AWS Budgets addresses that governance gap by alerting on actual or forecasted thresholds and, with budget actions, optionally applying IAM or SCP-oriented controls when limits are crossed—notify first, then tighten if leadership requires enforcement. That pattern preserves useful lab accounts while giving FinOps and account owners a clear response path. Deleting every sandbox after each login is operationally destructive, breaks continuity for coursework and vendor proofs, and still fails to teach spend hygiene. Ignoring sandbox spend because environments are non-production is false: those accounts appear on the consolidated invoice like any other. Moving all sandboxes into the management account concentrates risk, violates account-vending best practice, and does not prevent Budgets from being the right control plane—it makes blast radius worse. Exam caveat: budget actions need deliberate IAM/SCP design so enforcement cannot lock out break-glass roles needed to remediate the overspend. Operational check: create a sandbox budget with a low notify threshold and a higher action threshold in a pilot OU, trigger a test alert, and verify the notification channel and optional policy attachment behave as documented.