Terraform Plan JSON
A Terraform plan JSON document with create, update and delete changes, after_unknown markers, sensitivity annotations, and a configuration section. This is the artifact policy engines read before anything runs, which is why it sits with pipeline definitions rather than with run reports.
{
"format_version": "1.2",
"terraform_version": "1.9.5",
"planned_values": {
"root_module": {
"resources": [
{
"address": "examplecloud_network.main",
"mode": "managed",
"type": "examplecloud_network",
"name": "main",
"provider_name": "registry.example.invalid/example-org/examplecloud",
"schema_version": 1,
"values": {
"name": "novus-staging-net",
"cidr_block": "10.20.0.0/16",
"tags": {
"environment": "staging",
"managed_by": "terraform"
}
},
"sensitive_values": {
"tags": {}
}
},
{
"address": "examplecloud_subnet.app[\"app-a\"]",
"mode": "managed",
"type": "examplecloud_subnet",
"name": "app",
"index": "app-a",
"provider_name": "registry.example.invalid/example-org/examplecloud",
"schema_version": 1,
"values": {
"name": "app-a",
"cidr_block": "10.20.1.0/24",
"zone": "a",
"public": false
},
"sensitive_values": {}
}
]
}
},
"resource_changes": [
{
"address": "examplecloud_network.main",
"mode": "managed",
"type": "examplecloud_network",
"name": "main",Specifications
- Format Version
- 1.2
- Terraform Version
- 1.9.5
- Resource Changes
- 4
- Action Kinds
- create, update, delete
- Has Unknown Values
- true
- Output Changes
- 1
- Errored
- false
- Boundary
- proposed change, not a run record
Testing contract
Reference control- Scenario
- Run a policy check over Terraform plan JSON and classify the proposed actions
- Expected result
- Four resource changes are found (two creates, one update and one delete), and the delete of examplecloud_bucket.legacy is surfaced as the destructive action
What is a .json file?
JSON (JavaScript Object Notation) is a lightweight, text-based data-interchange format representing objects, arrays, strings, numbers, booleans, and null. It is language-independent, human-readable, and the dominant format for web APIs and configuration. It requires a single well-formed root value.
How to use this file
Use an example JSON file to test parsers and serializers, schema validation, Unicode and number-precision handling, and API request or response processing.
How to use this file for testing
“Terraform Plan JSON” is a deterministic Testaroo fixture for Schema validation, JSON parsing, Config testing. JSON Schema documents describing a data shape, for testing validators and schema-aware tooling.
Documented properties for this file: JSON · 4,378 bytes. Compare results against paired or grouped companions on this page when present (clean↔damaged, searchable↔scanned, or format twins) so scores stay reproducible across runs.
Download the file once, keep the path stable in CI or local scripts, and treat the spec table as the contract: dimensions, seeds, field lists, and roles are intentional. Corrupt or invalid samples are labelled as such, expect parsers to fail loudly rather than silently accept them.
Pipeline and infrastructure fixtures are inert configuration: steps reference fictional images and scripts, and nothing here executes. Run your linter, schema validator, migrator, or policy engine against them, and expect the deprecated-syntax and intentionally invalid variants to be rejected.
Code examples
import json
with open("terraform-plan.json") as f:
data = json.load(f)
print(type(data), len(data))Generated by generation/pipelines.py. Free for any use, no attribution required, license.
Related files
- jsonHelm values.schema.jsonThe values.schema.json that validates the paired Helm values files: a 2020-12 JSON Schema with $defs, $ref, enums, quantity patterns, and additionalProperties: false on nested objects. Validates the defaults and rejects a values file with an unknown image key.

- yamlKubernetes CustomResourceDefinition with OpenAPI SchemaA CustomResourceDefinition carrying a deep structural OpenAPI v3 schema with a regex pattern, an enum, a default, and array minItems. Useful both as a CRD fixture and as a nested JSON-Schema-in-YAML validation target.

- jsonin-toto Layout (Supply-Chain Policy)The policy half of in-toto: a layout declaring which steps must run, which keys may sign them, and the MATCH/CREATE/DISALLOW artifact rules that bind each step's products to the next step's materials. Signatures, key ids and certificates here are SAMPLE placeholders: the base64 decodes to the words 'SAMPLE SIGNATURE', so verification must fail. Nothing here is cryptographically valid and no key material is real.

- ymlGitHub Actions Over-Permissive Token (Policy Target)A schema-valid workflow that should still be rejected on review: permissions: write-all at the workflow level plus three unused write scopes on the job. Nothing here is an exploit; it is the least-privilege finding a policy engine is supposed to raise.

- jsonAlder Table Bistro: Cost of goods sold documentCost of goods sold document for Alder Table Bistro. The same statement as JSON, listing all 24 purchase ids it consumed so the total can be checked against the shared purchases table by id. Totals: opening 1736.91, purchases 2834.82, closing 2996.92, cost of goods sold 1574.81 CAD.

- jsonAlder Table Bistro: Digital menuDigital menu for Alder Table Bistro. One document holding the whole front of house: 3 printed sections with 4 dishes, 8 drink lines, the set menu, the specials and the 14 entry allergen key. Every dish carries its plate cost and the paths of the two costing files it was read from, so the join back to plate-costs.csv can be checked without guessing.
