Policy-as-Code Architecture: OPA + Terraform IaC Governance (2026)

Q: Why is Terraform validation and code review not enough to keep infrastructure compliant?

Terraform validation checks syntax and provider-schema conformance; it does not check whether the resource is configured to your organisation’s security and operational standards. A `terraform plan` that emits a fully valid AWS resource graph can simultaneously produce an S3 bucket without bucket-key encryption, a security group with port 3389 open to the internet, an IAM role with a wildcard trust principal, and a Lambda function with an unrestricted execution role — the syntax is right, the provider accepts the apply, and the audit fails six months later. Code review is the secondary defence and it is structurally weak for three reasons. The reviewer has finite attention and reviews dozens of pull requests a week; the misconfiguration is one diff hunk in a hundred-file PR and the review either rubber-stamps it (because the diff "looks reasonable") or rejects it for unrelated reasons. The reviewer’s knowledge of organisational standards is implicit and unevenly distributed across the team; what one reviewer flags as a violation another reviewer accepts because the standard was never written down or the writer of the standard left the company. The reviewer does not scale: as the organisation goes from ten engineers to a hundred, the centralised review bottleneck either becomes a deployment-velocity drag or gets short-circuited by exception culture. Policy-as-code fixes all three. The policy is a written specification, not folklore. The pipeline evaluates it deterministically on every change, not occasionally when a reviewer notices. The enforcement scales with traffic, not with reviewer headcount. The structured output of the policy evaluation is also better remediation guidance than a review comment: it names the resource, the rule, the violation, and the fix, in a format the developer can act on without negotiating with the reviewer.

Q: How should I structure the policy repository, and why does the pattern-based directory layout matter?

The repository is structured around the five control patterns rather than around cloud services, because new services are pattern instances and the structure has to make that obvious to authors. The top-level `patterns/` directory has one subdirectory per pattern (baseline, tagging, networking, logging, encryption, iam). Within each pattern directory, rule files are grouped by resource type or by control family, and every rule file has a corresponding test file in the parallel `tests/` directory and corresponding positive and negative fixtures in `fixtures/valid/` and `fixtures/invalid/`. The `shared/` directory holds common Rego predicates (is_production_account, has_tag, resource_creating) so individual rules stay small and consistent. The `exceptions/` directory holds the exception file with TTL and audit metadata, and the rule evaluation consults it before emitting a deny. The repository is packaged as an OPA bundle and published to an OCI registry (ECR, ACR, GCR, Harbor) with semantic versioning; each team’s pipeline pins to a specific version range and pulls the bundle at evaluation time. The pattern-based layout pays back in three places. New rule authoring is faster because the author finds the pattern, copies an existing instance, modifies the resource type and parameters, adds tests and fixtures, and ships the PR — the cognitive load is "instantiate this pattern" not "design a new control". Code review is easier because the reviewer can compare the new rule against the pattern’s other instances and immediately see whether the shape is right. Documentation is implicit because the directory structure communicates the framework to new team members without a separate explainer document. The flat-rule-pile alternative produces a repository that grows linearly with cloud-service coverage, becomes incoherent above 50 rules, and is hard to teach to new authors.

Q: How do I handle exceptions without the exception process becoming a permanent loophole?

No policy library can anticipate every legitimate edge case; the exception process is the pressure-relief valve and its quality decides whether the policy library is operationally viable. The exception file lives in the policy repository and the OPA rule evaluation consults it before emitting a deny; the file is structured YAML or JSON with one entry per exception. Each entry carries the resource address (or address pattern that can match a small set of related resources), the rule package being exempted, the business justification (free text but reviewed), the approver identity, the approval date, the expiry date (TTL — typically 30 to 90 days for tactical exceptions and 6 to 12 months for architectural ones requiring code refactor), and the remediation plan that explains what changes before the expiry date. The lifecycle is: a developer hits a deny and judges it a false positive or a legitimate edge case, opens a pull request to the policy repo adding an exception entry with all metadata fields populated, codeowners review the justification and approve or reject, on approval the exception merges and the developer’s Terraform PR can proceed. Expired exceptions automatically lapse and the rule re-fires on the next pipeline run; the developer either re-applies for an extension (which requires re-justification) or completes the remediation. The audit trail is the git history of the exception file: who approved what, when, with what justification, with what TTL. The metrics that prevent the loophole are exception count per team (an outlier flags a process problem or a rule that needs refinement), exception TTL distribution (a long-tail of repeatedly-extended exceptions flags a rule the platform team needs to revisit), expired-exception remediation rate (zero indicates the exception process is functioning as a permanent loophole), and rule-violation rate by pattern (a steady high rate flags a rule that needs tuning or a developer-education gap).

Q: How does the drift bridge to AWS Config, Azure Policy, and GCP SCC actually work?

Policy-as-code in CI/CD prevents misconfigured IaC from being applied. It does not detect drift after apply: the resource that was compliant when applied becomes non-compliant when an engineer clicks in the console, a third-party automation modifies it, or an incident-response remediation deviates from declared state. The drift bridge integrates the IaC governance pipeline with cloud-native posture services so the same rules that gate the CI/CD pipeline also flag drift in running infrastructure. The 2026 production architecture is OPA-via-Custom-Lambda for AWS Config (the Config service invokes a Lambda that calls OPA with the configuration item as input and emits a compliance status), OPA-equivalent Azure Policy custom definitions (Azure Policy supports a JSON DSL that covers most of what OPA does for the configuration-evaluation subset of the use case), and GCP custom modules in Security Command Center. The architectural goal is one rule definition that runs in two places: the IaC pipeline (preventive) and the cloud-native posture service (detective). The honest position is that maintaining the rule library in two execution environments is harder than running OPA in one place, and the production-grade trade-off is to express rules in Rego, generate the Config / Azure Policy / SCC artefacts from the Rego source as part of the bundle build pipeline, and treat the auto-generated artefacts as derived rather than hand-maintained. Rules that fail in the detective layer feed back as platform-team remediation tickets in Jira or PagerDuty, or for severe violations as automated remediation via AWS Systems Manager Automation, Azure Automation Runbooks, or GCP Cloud Functions; the auto-remediation path is high-trust and high-blast-radius, so the rules that trigger it are a small subset (typically the Pattern 3 exposure restrictions where the right answer is "close the port immediately and notify the owner").