This is the depth companion to The 10x enterprise architect isn't the one who prompts fastest. That piece argued the job has moved from producing to validating. This one delivers the concrete method: what the validation loop actually looks like, run on a real AI-generated config.
The generation run I described in that piece was real, and this is what it produced. I asked Claude — grounded in the live Terraform Registry via the Terraform MCP Server — for a three-region AWS landing zone: VPCs, transit gateway, security groups, IAM roles, S3 state bucket, deployment pipeline. It came back in 90 seconds. Clean module structure, sensible naming, roughly two days of work for a capable mid-weight engineer.
Three things were wrong. None of them would have been caught by terraform validate.
That gap is the job. Here is what I actually do with it.
What came back — and what passed validation
The AI's output was a well-formed Terraform project. terraform validate returned zero errors. A quick read looked fine. But run against our landing-zone principles:
Finding 1 — IAM too permissive. The pipeline role had "Action": "s3:*" with "Resource": "*" on the state bucket policy. Syntactically valid. Explicitly banned by our baseline: No IAM policy may grant wildcard actions on any resource without written justification. Correct scope: s3:GetObject, s3:PutObject, s3:DeleteObject, on the specific bucket ARN.
Finding 2 — Encryption absent. The S3 state bucket had no aws_s3_bucket_server_side_encryption_configuration block. Not a syntax error. It was never generated. Our baseline (and NIS2 Article 21(2)(h), which requires policies on the use of cryptography and, where appropriate, encryption) requires KMS or AES-256 on any bucket holding infrastructure state. One missing resource block; one compliance gap.
Finding 3 — Log retention too short. VPC Flow Logs lifecycle set to 30 days. Our standard is 12 months minimum. No EU instrument hands you that number: DORA's RTS on ICT risk management (Delegated Regulation 2024/1774, Article 12) requires you to set a retention period and justify it against your own risk assessment. That is the whole point. The AI generated a reasonable-looking default. It is wrong for our context, and only we know that.
All three pass terraform validate. All three fail against our principles.
How the validation actually works
This is not intuition. Every finding maps to a written principle. The checklist I run through for any AI-generated landing zone:
- IAM scope — every policy, every role. Wildcard actions trigger a mandatory justification before approval.
- Encryption at rest — every storage resource, every region. Absent encryption blocks approval.
- Logging and retention — VPC Flow Logs, CloudTrail, S3 access logs. Retention must meet the internal standard and be defensible against the applicable regime: DORA's RTS requires you to set and justify the period; GDPR caps how long you may keep any personal data those logs contain.
- Network blast radius — CIDR blocks checked against the IP address management register. An overlapping subnet that passes
validatecreates a routing conflict atapplyor, worse, silently corrupts topology. - Cost guardrails — right-sized compute, no accidental on-demand in reserved workloads, no orphaned resources.
The AI generates against your prompt. You validate against your principles. These are different inputs — only you have both.
The output: a decision record, not a Slack message
The validation is half the work. The output is the other half. Not "I found some issues" in a thread somewhere — a decision record:
ADR-2026-047 — Landing zone v2.3 initial generation (AI-assisted)
Status: Approved with modifications
Generated by: Claude + Terraform MCP Server
Reviewed against: Landing Zone Principles v4.1
Modifications required before merge:
— IAM: scope s3:* → s3:GetObject/PutObject/DeleteObject on specific ARN (LZ-IAM-03)
— Encryption: add server_side_encryption_configuration block, KMS key ref (LZ-SEC-07)
— Log retention: update lifecycle to 365 days (LZ-LOG-02, per DORA RTS 2024/1774 Art. 12 risk-based retention)
Justified exceptions: none
Principles updated: none required — standard applies as written
That document guides the dev team that applies the modifications. It also guides the AI on the next generation cycle: the same principles, encoded as policy-as-code rules (Checkov, OPA, Sentinel), become the guardrails the machine runs inside next time. That encoding step is its own discipline — the policy-as-code gate covers where it lives in the pipeline.
This is what leading the AI means in practice. Not fixing the config yourself — authoring the guardrails that make every future generation better.
The Automate / Augment / Reserve split
For deciding where AI fits across your infrastructure work, I use three buckets:
- Automate — AI runs it, architect verifies the output against principles. Initial IaC generation, documentation, runbooks, cost reports. High-velocity; validation is the human step.
- Augment — AI drafts, architect decides. Design options, security analysis, failure-domain modelling. AI narrows the solution space; architect owns the call.
- Reserve — human only. Trade-off decisions (cost vs. resilience vs. compliance), justified exceptions to principles, escalated incident response, stakeholder sign-off on risk.
This is the frame. What to let AI automate takes it one domain at a time, with the boundary cases most teams get wrong.
The one question
The pillar piece teased it. Here it is:
For every artifact the AI hands you: what breaks, and who pays?
Not "is this correct?" — the AI already gave you plausible. "What breaks" forces you to trace failure domains. "Who pays" forces you to think about blast radius: the team, the budget, the compliance posture, the customer.
If you can't answer both, you don't know enough to approve it yet. That pressure-test takes about five minutes on a mid-size config. Those five minutes are the line between amplified and replaced.
If you want the series as it lands, subscribe below.
If you can't beat them, lead them.
Sources & further reading
- Directive (EU) 2022/2555 — NIS2 Directive — European Parliament and Council, December 2022. Article 21(1) sets the "appropriate and proportionate technical, operational and organisational measures" obligation; Article 21(2)(h) is the cryptography and encryption item specifically.
- Commission Delegated Regulation (EU) 2024/1774 — DORA RTS on ICT risk management — European Commission, June 2024. Article 12 ("Logging") is the actual EU logging instrument: it requires you to establish the retention period against your own risk assessment rather than setting a number for you.
terraform validate— HashiCorp. Worth reading for what it explicitly does not check: it validates configuration syntax and internal consistency, not whether the result is safe or compliant.- Checkov — Bridgecrew (Palo Alto Networks). Static analysis for IaC; the fastest way to encode findings like the three above as repeatable rules.
- Open Policy Agent — CNCF. General-purpose policy engine when your guardrails need to span more than Terraform.
- HashiCorp Sentinel — HashiCorp / IBM. Policy-as-code inside HCP Terraform and Terraform Enterprise, where the gate sits in the run pipeline rather than in CI.