An infrastructure agent generates a Terraform plan before applying changes. The security team wants to automatically validate that no planned action will open inbound traffic from 0.0.0.0/0 on any port before the plan is executed. What is the prerequisite that makes this automated safety check possible?
Select an answer to reveal the explanation.
Short Explanation
You can't automate a policy check on a PDF — you need structured data. Answer A is correct: machine-parseable JSON plan output is the prerequisite that makes automated policy validation possible. Tools like Open Policy Agent, Conftest, or custom scripts can traverse a JSON plan and evaluate every resource action against rules. Human review, post-execution scanning, and permission restriction are either slower, too late, or too restrictive to be the right answer here.
Full Explanation
Automated policy gates between plan and execution are a core security pattern in infrastructure-as-code workflows. The pattern depends entirely on the plan being in a machine-readable, structured format — not just human-readable text.
Why A is correct: Terraform's native terraform plan -out=plan.tfplan and terraform show -json plan.tfplan produce structured JSON that contains every planned resource action: resource type, resource name, action type (create/update/delete), before/after attribute values. A policy tool can traverse this JSON, find all aws_security_group_rule or aws_vpc_security_group_ingress_rule resources with action 'create' or 'update', and check whether any cidr_ipv4 value is 0.0.0.0/0. This is the foundation of the Conftest/OPA ecosystem. Without structured output, automated parsing is fragile regex over human text — brittle and unreliable.
Why B is wrong: Human review of the Terraform plan output is a valid control, but the question asks what enables automated validation. Human review doesn't scale — it introduces variable latency, is error-prone at volume, and cannot run inside a CI/CD pipeline as a blocking gate without human scheduling. For a security check as specific and repeatable as 'no 0.0.0.0/0 rules', automation is clearly superior.
Why C is wrong: Post-execution scanning is a compensating control, not a preventive one. By the time a scanner detects the 0.0.0.0/0 security group rule, the infrastructure is already deployed and the network is already open. Rollback is possible but introduces additional risk — a partially applied Terraform configuration may leave infrastructure in an inconsistent state. Shift-left security means catching violations before execution, not after.
Why D is wrong: Restricting the agent to read-only Terraform permissions would prevent it from making any infrastructure changes at all, which defeats its purpose. The goal is to allow legitimate infrastructure changes while preventing specifically non-compliant ones. Blanket capability removal is not a substitute for targeted policy enforcement against a specific class of violation.