Temporary project sandboxes for a summer internship portal are still running months after the project ended and continue to accrue cloud charges. What lifecycle action is needed?
Select an answer to reveal the explanation.
Short Explanation
Leaving the rental car running in the lot after the trip still burns gas. When the project is over, shut the sandboxes down so the meter stops.
Full Explanation
Resource lifecycle includes timely teardown of temporary and unused environments to control cost and reduce attack surface. Temporary project sandboxes for a summer internship portal that still run months after the project ends should be torn down promptly so the city stops accruing cloud charges and unused entry points. Idle sandboxes are both a budget leak and an ungoverned risk.
Increasing sandbox sizes so idle projects consume more reserved capacity worsens waste. Converting every sandbox into an unmonitored production dependency elevates risk. Disabling billing tags so idle spend is harder to attribute hides the problem from FinOps and department owners.
Exam caveat: lifecycle policies, TTL labels, and scheduled reaping are valid ways to enforce teardown; exams emphasize identifying unused resources and deleting them, not merely powering them off without a plan for disks and IPs.
Operational check: tag sandboxes with owner and expiry, report aged non-prod resources monthly, notify owners, delete compute/storage/network remnants after approval, and confirm billing and inventory no longer list the internship stack. Feed lessons into a standard temporary-environment TTL for future civic projects.