An infrastructure provisioning agent has successfully completed steps 1 through 5 of a 10-step plan (creating a VPC, subnets, security groups, IAM roles, and an RDS instance) when step 6 fails with an AWS service quota exceeded error. The remaining steps depend on resources that step 6 would have created. What is the correct error-handling behavior for the agent?
Select an answer to reveal the explanation.
Short Explanation
Leaving half-built cloud infrastructure lying around is like walking off a construction site with the walls up but no roof — it's costly, creates security exposure, and confuses everyone who comes after. You need to roll back completed steps in reverse order, document what was created, what failed, and why, then escalate to a human operator. Clean state plus clear error reporting beats a mystery pile of orphaned cloud resources every time.
Full Explanation
Responsible agent error handling requires three things: undoing completed work when the overall goal cannot be achieved, preserving a clear record of what happened, and escalating to human judgment for non-recoverable errors. Service quota exceeded errors are not transient, like network timeouts, so they require human action such as a quota increase request to AWS; retrying is not an appropriate autonomous response. The rollback-and-escalate choice is correct because it follows the three-phase error pattern: rollback, document, escalate. Rolling back in reverse order, step 5 then 4 then 3 then 2 then 1, respects resource dependencies, because you cannot delete the VPC while subnets exist inside it. The structured error artifact gives the operator full context: exactly which resources were created, with their identifiers, which step failed, the exact error message, and the reason rollback was performed. This allows the operator to fix the underlying issue, such as requesting a quota increase, and re-run the agent cleanly. The retry-with-exponential-backoff choice is wrong because AWS service quota errors do not self-resolve. A quota exceeded condition persists until either a quota increase is approved or resources consuming the quota are deleted. Retrying indefinitely wastes agent execution time and incurs costs without making progress. The skip-step-6-and-continue choice is dangerous. Skipping step 6 and continuing means downstream resources will likely fail to create, since they depend on step 6 outputs, or worse, they may create but be non-functional, leaving the environment in an inconsistent state that is harder to clean up than starting fresh. The terminate-immediately-and-leave-infrastructure choice is the worst choice: abandoning partially provisioned infrastructure creates orphaned resources that incur ongoing costs, may expose security vulnerabilities, such as open security groups and IAM roles with no attached policies, and create confusion for the team. The operator is handed a mess with no documentation of what was done.