Outcome
By the end of this lesson, you will be able to explain the Policy Decision Point model, describe what ZopNight reads and what it never runs, and place enforcement where it belongs.
| Prerequisites | M3.6 (IaC + cost) |
| Time | 9 minutes |
1. Concept
This feature governs your own IaC, Terraform and OpenTofu. That is a different thing from everything else in this curriculum, which governs your cloud resources.
IT READS TWO THINGS
A PLAN terraform/tofu plan -> the PR gate: what is about to change
STATE terraform/tofu show -json -> the inventory scan: what is declaredThe Policy Decision Point model
ZOPNIGHT IS A PDP: IT EMITS A DECISION.
YOUR GITHUB REQUIRED CHECK IS THE PEP: IT ENFORCES.
ZopNight NEVER RUNS `apply`.That separation is the whole architecture, and it is worth being able to defend because it is the first thing a platform team will probe.
WHY IT MATTERS
A tool that enforces needs the ability to BLOCK, which means being in the critical path of every deploy. When it is slow, your deploys are slow. When it is down, your deploys are down.
A tool that DECIDES emits a verdict. Your existing branch protection decides what to do with it. If ZopNight is unreachable, the installed workflow fails the check, so a required check holds the merge (never a running deploy) until it recovers. To fail open, edit the gate step.
And a tool that never runs `apply` never holds credentials that can change your infrastructure.The last line is the one that gets this through a security review quickly. The integration reads a plan file. It cannot create, modify or destroy anything, because it has no path to.
Where it sits
HOSTED as the `iac` policy DOMAIN in the recommender,alongside the `recommendation` and `tagging` domains.
POLICIES live in Config, under that domain.
So this is not a new service and not a new policyengine: it is a third domain on machinery you alreadyhave.You have now seen that pattern repeatedly, and it predicts things: because iac is a policy domain like the others, it inherits the same storage, the same RBAC shape and the same catalog-driven authoring surface.
The two modes
PR GATE (plan) Runs on a pull request. Reads what the plan proposes. Emits a decision the required check consumes. This is where cost guardrails live (L3).
INVENTORY SCAN (state) Runs against declared state. Links declared resources to DISCOVERED inventory, producing a MANAGED versus ORPHAN split.The second mode is the one people underuse. It answers a question no other surface in the product answers:
MANAGED this resource exists in the cloud AND is declared in IaC. Changes to it will survive.
ORPHAN this resource exists in the cloud and is NOT declared in IaC. It was created by hand, or by a tool, or by IaC that has since been deleted.An orphan is where drift comes from, where untagged resources cluster, and where the next apply will not help you. Knowing your managed-versus-orphan ratio is a maturity signal in its own right.
It is agent-reachable
Policy CRUD, CI wiring and token management, validation-run reads and the policy and tagging catalogs are all exposed as MCP tools. So an agent can answer “which policies do we have and what did the last validation say” without you opening the dashboard.
The write half of that surface is governed by the same rule as everything else an assistant can reach: on an organisation with default settings it can be read and not written. T6.M6.1 covers where that rule comes from.
What you get in the app
A governance dashboard: policies, validations,repositories.
Plus GOVERNED OVERRIDE, which is audited (L4).Override being audited rather than absent is the right design: a policy engine with no override becomes a policy engine people route around, and an override that leaves no record is indistinguishable from the policy not existing.
2. Demo
A platform team’s security review of the integration:
Q: "Does this thing have credentials to our AWS account?" No. It reads a plan file and a state file. It never runs apply, and it holds no cloud credential for this purpose at all.
Q: "So how does it stop a bad change?" It does not. It emits a decision. Your GitHub Required Check stops the change, using the branch protection you already have. ZopNight is the PDP; your CI is the PEP.
Q: "What happens if ZopNight is down when we merge?" The governance job fails, so the required check reports failed and the merge waits until ZopNight recovers. If you would rather fail open, edit the gate step or make the check non-required. It gates merges, not deploys: it never touches a running deploy.
Q: "Is this a separate system we now have to run?" No. It is the `iac` domain in the existing policy engine, beside `recommendation` and `tagging`. Policies live in Config with the others.
Q: "Can someone bypass a policy?" Yes, through a governed override, and it is audited. We would rather have overrides we can see than a policy engine people route around by moving the change outside IaC.
OUTCOME: approved in one meeting. The two answers thatdid it were the first (no credentials) and the third(a clear failure mode they could choose to change).
WHAT THEY FOUND FIRST, FROM THE OTHER MODE Their first inventory scan reported 61% managed, 39% orphan.
They had assumed they were near-fully IaC-managed. The 39% was three years of console-created resources, test infrastructure that outlived its project, and one whole environment built during an incident and never codified.
That number, not the PR gate, was what justified the integration internally.3. Hands-on (6 min)
1. Run an inventory scan against one repository's state. managed ______% orphan ______% Was the orphan share what you expected? Y / N
2. Look at your largest orphan resources by cost. Where did they come from? [ ] console-created [ ] another tool [ ] IaC that was deleted [ ] unknown Largest one: ______________________________
3. Confirm the boundary in your own words: what could this integration do to your infrastructure if its credentials leaked? ______________________________________________
4. The installed gate fails the check if ZopNight is unreachable. Decide whether that is right for you: [ ] keep blocking [ ] fail open (edit the gate step) If fail open, make that change before adopting the gate.
5. Note who would hold governed-override rights: ______________________________________________4. Knowledge check
Q1
A platform team asks what would happen if ZopNight were unavailable when a pull request is checked. The accurate answer:
A. The installed workflow fails the check, so a required check blocks the merge until ZopNight recovers
B. Deploys proceed anyway, with all of the policies disabled for the whole of that duration
C. The check does not report, and the team’s existing policy for a non-reporting required check applies
D. The last known decision for that repository is reused until the service recovers
Show answer
Correct: A. The gate step exits with an error when the ZopNight call fails, so the required check reports failed and branch protection holds the merge. ZopNight is still only the Policy Decision Point: it never runs apply and never touches a deploy. To fail open instead, edit the gate step or make the check non-required.
Q2
What credentials does the IaC governance integration hold against your cloud?
A. Read-only credentials for the accounts it scans
B. None for this purpose
C. The same credentials as cost discovery
D. Write credentials, used only for governed overrides
Show answer
Correct: B. It reads a plan file and a show -json state file, and it never runs apply, so it has no path to create, modify or destroy infrastructure. This is usually the fastest answer in a security review of the feature: the integration cannot change your infrastructure because it has no mechanism to, not because it has been configured not to.
Q3
An inventory scan reports 61% managed and 39% orphan. “Orphan” means:
A. Resources that are declared in the IaC but which no longer exist anywhere in the cloud at all any more, having been deleted
B. Resources that have no owning team recorded against them anywhere in ZopNight or in the cloud tags either
C. Resources that exist in the cloud and are not declared in IaC: console-created, tool-created, or declared by IaC that has since been deleted
D. Resources whose Terraform state file has somehow become corrupted or completely unreadable at scan time
Show answer
Correct: C. Orphans are where drift originates, where untagged resources cluster, and where the next apply will not help. The managed-versus-orphan ratio is a maturity signal no other surface in the product produces, and it is frequently the finding that justifies adopting the integration at all.
5. Apply
Run an inventory scan before wiring the PR gate. The managed-versus-orphan split takes minutes to produce and is usually more persuasive internally than the gate itself.
Decide whether the gate should block or fail open when ZopNight is unreachable before you adopt it (the installed workflow blocks), because that is the behaviour that governs what happens on a bad day.
Related lessons
- L2: Builtin rules and custom Rego (next)
- L3: Cost guardrails in the pull request
- T3.M3.6.L2: IaC drift detection
- T3.M3.6.L3: Pre-merge cost estimation