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 Novus Examples 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))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.
- jsonApp Settings (JSON)JSON application settings for config-merge and validation tests.
- yamlAttestation Verification Policy (YAML)The policy an admission controller evaluates before an artifact is allowed through: required predicate types, an allowed-builder list, a minimum SLSA level, a transparency-log requirement and one dated exception. Every package, version, hash and licence is fictional — the tree describes nothing real.
Generated by generation/pipelines.py. Free for any use, no attribution required — license.