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 and Infographic
Leaving half-built cloud infrastructure lying around is like walking off a construction site with the walls up but no roof — it costs money, creates security exposure, and confuses everyone who comes after. Option B is correct: the agent must roll back completed steps in reverse order, document everything it did and why it stopped, then hand the situation to a human. Clean state plus a clear error report beats a mystery pile of orphaned cloud resources every time.
Full explanation below image
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. A service quota exceeded error is not transient (like a network timeout) — it requires human action such as a quota increase request to AWS, so retrying is not an appropriate autonomous response.
Option B 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 — 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 IDs), which step failed, the exact error message, and the reason rollback was performed. This allows the operator to fix the underlying issue (request a quota increase) and re-run the agent cleanly.
Option A 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.
Option C 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.
Option D is the worst option: abandoning partially provisioned infrastructure creates orphaned resources that incur ongoing costs, may expose security vulnerabilities (open security groups, 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.