Exercise 3: Why a Budget Alone Isn't Sufficient Protection — Possible Solution ==================================================================== Chapter 9 established a real, critical distinction: AWS Budgets is a notification tool, not an enforcement tool. Crossing a real spending threshold sends an alert -- it never automatically stops, restricts, or shuts down the resources actually causing the spend. The teammate's claim -- that the Budget alone is sufficient to PREVENT unexpected overspending -- is incomplete because "prevent" implies stopping the spend from happening, which a Budget genuinely cannot do on its own. It can only make a human aware that spend has crossed a threshold, after the fact. A concrete real scenario where this would fail to hold: Chapter 2's own compromised-credential warning, applied to this capstone's own IAM role from Step 2. If that role's own credentials were somehow compromised (or a genuinely different, over-permissioned credential elsewhere in the account was), an attacker using them to launch unauthorized EC2 instances would drive real spend upward. The Budget alert would eventually fire once the threshold was crossed -- but the unauthorized instances would keep running and keep accumulating real charges until a person actually saw the alert and manually intervened, exactly as Chapter 9's own Exercise 2 scenario walked through. ANSWER: The claim is incomplete because a Budget only alerts after spend has already started accumulating -- it never automatically stops the underlying cause. A concrete scenario where it fails to prevent real overspending: a compromised credential (Chapter 2) being used to launch unauthorized resources, which would keep running and racking up charges for as long as it takes a human to notice and respond to the Budget alert, not stopping automatically the moment the threshold is crossed. WHY THIS WORKS AS AN ANSWER ------------------------------ This correctly identifies the specific gap in the teammate's claim (alerting vs. preventing) using Chapter 9's own explicit distinction, and grounds the answer in a real, concrete scenario drawn from an earlier chapter (Chapter 2's credential-compromise theme) rather than a generic, hypothetical example -- tying the capstone's own closing security warning directly back to specific, real material covered earlier in the course.