A deployment agent produces a 12-step deployment plan. A validator tool reviews the plan and identifies that step 7 will drop and recreate a production database table without a preceding backup step. What is the correct agent behavior at this validation point?
Select an answer to reveal the explanation.
Short Explanation
If a validator finds a step that can drop a production table without a backup, you halt execution, reject that step with a structured error, and send the plan back for revision before re-validating. You don't let a dangerous plan run just because the rest of the steps look fine.
Full Explanation
The validate-then-execute pipeline is only valuable if validation can actually halt execution. A validator that finds a critical violation and allows the plan to proceed, in any form, fails at its primary purpose.
Why the halt-and-revise behavior is correct: The correct response to a validator finding a critical safety issue is a structured halt-and-revise cycle. The validator emits a structured error identifying the violation specifically: step number, issue type, missing prerequisite backup step, and risk classification. The agent halts; it does not execute any subsequent steps. The plan is returned to the planning phase with the validator's error as input, so the agent can produce a revised plan that includes a backup step before the table recreation. The revised plan then enters the validation pipeline again before any execution occurs. This loop, plan to validate to revise to validate to execute, is the safety-critical architecture for destructive operations.
Why skipping the problematic step and continuing is wrong: Skipping the table drop and recreate step and continuing creates a plan fragment, steps 1 through 6 and 8 through 12, that was designed as a unit. The dropped step is likely a dependency for later steps. Executing those later steps without the table operation may cause them to fail, leaving the deployment in a partial state. More fundamentally, skipping the dangerous step is not a safety mechanism; it is ad-hoc plan mutation at runtime, which is its own risk.
Why executing the plan and adding real-time monitoring after the dangerous step is wrong: Inserting monitoring after the table drop and recreate step executes the dangerous step anyway; it simply adds observability to the data loss event as it happens. Catching data loss early is not remediation; by the time the monitor reports data loss, the data is already gone. That approach confuses detection with prevention. The validation gate exists to prevent execution of the unsafe step, not to make its consequences more visible.
Why asking the user whether to proceed with the unsafe step or abandon the deployment is wrong: Asking the user to decide whether to proceed with a step the validator has flagged as unsafe puts the risk decision on a human who may not have the context to evaluate it safely under deployment pressure. The validation gate should either produce a safe plan or halt; it should not surface an unsafe plan and ask for human approval to bypass the safety check. That approval pattern erodes the value of automated validation over time as users habituate to clicking proceed anyway.