Sentinel Mock Data Authoring Prompt
Generate Sentinel mock data from real `terraform plan` JSON so policies can be tested offline with `sentinel test`, including both pass and intentional-fail fixtures.
- Target user
- Engineers writing and testing Terraform Sentinel policies
- Difficulty
- Advanced
- Tools
- Claude, ChatGPT
The prompt
You are a Sentinel expert who tests policies the way you test code: with `sentinel test`, against mock data captured from real Terraform plans, with explicit pass and fail fixtures. You know the mocks are generated from plan/config/state JSON (e.g. `tfplan/v2`, `tfconfig/v2`, `tfstate/v2`) and that a policy you can't test against representative mocks is a policy you don't trust. I will provide: - The Sentinel policy and the rule it enforces ([POLICY_RULE] — e.g. "all S3 buckets must have encryption", "no public ingress") - A sample `terraform plan` (or its JSON) representing a compliant change, and one representing a violation - The Sentinel import(s) the policy reads from (`tfplan/v2`, `tfresources`, etc.) Your job: 1. **Identify the imports under test** — list exactly which mock imports the policy reads and therefore which mock files you must produce. Don't mock imports the policy never touches. 2. **Generate the mock data** — show how to produce the mock files from a real plan (the generate-mock-data tooling / `-generate-config-out` style capture), and then hand-trim them to the minimal resources that exercise [POLICY_RULE]. Smaller, focused mocks beat dumping a whole plan. 3. **Author a passing fixture** — a `test/<policy>/pass.hcl` (or equivalent) that points at compliant mocks and asserts `main = true`. 4. **Author a failing fixture** — a separate case pointing at the violating mocks that asserts `main = false`, proving the policy actually rejects the bad input (a policy that never fails any test is worthless). 5. **Cover the edge cases** — empty plans, resources being destroyed, `null`/unknown values that show up as computed in the plan, and modules nested under `module_address`. Show how each appears in the mock and how the policy must handle it. Output as: (a) the list of imports/mock files needed, (b) the commands to generate mocks from a real plan, (c) the trimmed pass and fail mock data, (d) the test fixtures asserting `main = true`/`false`, (e) the edge-case mocks and the policy adjustments they reveal. Generate mocks from a sanitized plan — real plan JSON can contain account IDs, ARNs, and other identifiers; scrub them before committing mock data to a repo.
Why this prompt works
Most Sentinel content stops at writing the policy, leaving the hardest and most-skipped part — testing it — as an exercise for the reader. An untested policy is a liability twice over: it might wave through the very thing it was supposed to block, or it might false-positive and grind every plan to a halt. The prompt treats Sentinel policies like real code, demanding mock-data-driven tests via sentinel test, which is the only way to know a policy behaves before it sits in the apply path of production changes.
The technical core is the mock data itself. Sentinel mocks are generated from real Terraform plan, config, and state JSON exposed through imports like tfplan/v2, and the prompt makes the model identify which imports the policy actually reads so it mocks only those. Just as important, it pushes for trimmed, focused mocks rather than a dumped full plan, because a 4,000-line mock no one understands is as bad as no test at all. The edge cases it enumerates — destroyed resources, unknown/computed values, nested module addresses — are precisely the shapes that cause policies to misfire in the wild.
The fixture structure is what makes the test meaningful: one case asserting main = true against compliant mocks, and a separate case asserting main = false against a deliberate violation. A policy that only ever passes its tests proves nothing; the failing fixture is the part that proves it can actually reject bad input. The sanitization guardrail keeps real account IDs and ARNs out of committed mock data, and the overall pattern keeps this firmly AI-drafts-human-verifies: the model captures and trims the mocks and writes the fixtures, while the engineer confirms the policy genuinely blocks the violation it claims to.