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 and Infographic
A validator that finds a critical safety violation and lets execution continue anyway is like a safety inspector who stamps 'approved' on a faulty bridge. Answer B is correct: halt, reject with a structured error, revise the plan, re-validate. The validator's job is to prevent dangerous plans from executing — not to rubber-stamp them. Skipping the step, adding monitoring after the fact, and asking the user all either partially execute a dangerous plan or put the decision on the wrong party.
Full explanation below image
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 B 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 → validate → revise → validate → execute) is the safety-critical architecture for destructive operations.
Why A is wrong: Skipping step 7 and continuing creates a plan fragment — steps 1-6 and 8-12 — that was designed as a unit. Step 7 (table drop/recreate) is likely a dependency for steps 8-12. Executing those steps without the table operation may cause them to fail, leaving the deployment in a partial state. More fundamentally, 'skip the dangerous step' is not a safety mechanism — it's ad-hoc plan mutation at runtime, which is its own risk.
Why C is wrong: Inserting monitoring after step 7 executes the dangerous step anyway — it simply adds observability to the data loss event as it happens. 'Catch data loss early' is not remediation; by the time the monitor reports data loss, the data is already gone. This option confuses detection with prevention. The validation gate exists to prevent execution of the unsafe step, not to make its consequences more visible.
Why D 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 — 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.'