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.
| Tier | Engineer |
| JTBD | ”Gate cost and posture mistakes at the pull request, without giving a vendor apply rights.” |
| Personas | Platform Engineer · SRE · Security/Compliance |
| Prerequisites | M5.6 (IaC + cost) |
| Time | 9 minutes |
| Bloom verb | Explain (Understand), Describe (Understand), Place (Apply) |
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 unavailable, that is a check that did not report, and you already have a policy for that.
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 deploy?" The check does not report. Your existing policy for a non-reporting check applies, whatever you have already decided that should be. We are not in the critical path in the sense that matters: we cannot hold your deploy hostage by being slow.
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(not in the critical path).
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. Check what your CI does today with a non-reporting required check: [ ] blocks [ ] passes [ ] no policy If "no policy", decide one 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 during a deploy. The accurate answer:
A. Deploys are blocked entirely until the ZopNight service recovers again fully
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: C. ZopNight is the Policy Decision Point that emits a verdict; the GitHub Required Check is the enforcement point. A tool that enforces would be in the critical path and could hold deploys hostage by being slow. The PDP/PEP split is what keeps a governance tool out of the deploy critical path. It also means the failure mode is one the team already has a policy for rather than a new one.
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.
Settle your CI’s policy for a non-reporting required check before you adopt the gate, 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
- T5.M5.6.L2: IaC drift detection
- T5.M5.6.L3: Pre-merge cost estimation
Glossary terms touched
Policy Decision Point · Required check · Managed vs orphan · Policy domain