Implement Guardrails with Terraform and Policy-as-Code

This exercise turns Lesson 32's design document into working infrastructure as code. You will express the account guardrails, IAM boundaries, and network baseline as Terraform, and encode the non-negotiable rules as policy-as-code so they are enforced automatically rather than relying on every squad remembering them. This is the same shift from design to durable, self-enforcing control you practised with SCPs, organisation policies, and Kubernetes admission control throughout the course.

The Exercise

Step 1 — Encode the Guardrails as Organisation Policy

Start with the non-negotiable rules from the design: no public storage anywhere in the organisation, mandatory logging that cannot be disabled, and a restriction to PayNest's approved region for data residency. Express these as an SCP or organisation policy applied at the root, so they bind every current and future account automatically, exactly mirroring the AWS SCP and GCP organisation policy patterns from Modules 2 and 3.

# Step 1 -- root-level guardrails (bind to EVERY account automatically).

# SCP: deny public S3 access org-wide (no account can override this)
{
  "Effect": "Deny",
  "Action": ["s3:PutBucketPublicAccessBlock", "s3:PutBucketPolicy"],
  "Resource": "*",
  "Condition": {"Bool": {"s3:PublicAccessBlockConfiguration": "false"}}
}

# SCP: deny disabling CloudTrail anywhere in the org
{
  "Effect": "Deny",
  "Action": ["cloudtrail:StopLogging", "cloudtrail:DeleteTrail"],
  "Resource": "*"
}

# SCP: restrict all resource creation to the approved region
{
  "Effect": "Deny",
  "NotAction": ["iam:*", "organizations:*", "route53:*"],
  "Resource": "*",
  "Condition": {"StringNotEquals": {"aws:RequestedRegion": "ap-south-1"}}
}

Step 2 — Implement Per-Squad IAM in Terraform

Translate the IAM table from Lesson 32 into Terraform, giving each squad's engineers a role scoped to their own account only, and each application a dedicated service role scoped to its exact task, following the least-privilege pattern from Module 2. Write this as a reusable module so onboarding a fourth squad later means calling the module with new parameters, not writing new IAM logic from scratch — directly serving the squad-independence goal without creating per-squad maintenance burden for the single security engineer.

# Step 2 -- a reusable Terraform module for per-squad IAM.

module "squad_iam" {
  source      = "./modules/squad-role"
  squad_name  = "payments"
  account_id  = var.payments_dev_account_id
  permissions = ["s3:GetObject", "s3:PutObject", "dynamodb:*"]
  # scoped to THIS squad's resources only -- module enforces the pattern
}

module "squad_iam_merchant" {
  source      = "./modules/squad-role"
  squad_name  = "merchant"
  account_id  = var.merchant_dev_account_id
  permissions = ["s3:GetObject", "sqs:SendMessage"]
}

# Adding a 4th squad later = one more module call, not new IAM logic.
# This is what makes the design maintainable by one part-time engineer.

Step 3 — Gate the Pipeline with Checkov

Wire Checkov into the CI pipeline that deploys this Terraform, exactly as practised in Module 5's exercise, so any future change to these guardrails or squad modules is scanned before it can deploy. This closes the loop between design, implementation, and durability: even a future engineer unfamiliar with this capstone's reasoning cannot accidentally merge a misconfiguration past this gate, because the pipeline itself enforces the standard.

# Step 3 -- CI gate on the capstone's own infrastructure repo.

stages:
  - name: iac-security-scan
    run: checkov -d ./infrastructure --compact --soft-fail=false
  - name: terraform-plan
    run: terraform plan
  - name: terraform-apply
    run: terraform apply
    when: manual_approval_after_plan

# Any future PR that reintroduces a public bucket, an open port, or a
# wildcard policy is blocked here -- automatically, permanently.

Deliverable for This Lesson

Produce the Terraform implementing the root-level guardrails, the reusable per-squad IAM module, and the CI pipeline configuration gating future changes with Checkov — the working code realisation of Lesson 32's design. This becomes the second artefact in your final portfolio, and it should be ready as the foundation for the monitoring and alerting layer you will add in the next lesson.

• Implementation turns a design document into durable, self-enforcing infrastructure, closing the gap between an intention on paper and a rule that actually holds.
• Non-negotiable rules — no public storage, mandatory logging, region restriction — belong as root-level SCPs or organisation policies binding every account automatically.
• Writing per-squad IAM as a reusable Terraform module lets onboarding a new squad mean calling the module, not writing new logic — directly serving maintainability.
• Gating the pipeline with Checkov ensures future changes are scanned automatically, so the standard survives staff turnover rather than depending on memory.
• Commenting code with the business goal or requirement it satisfies turns infrastructure into its own documentation, reducing the ongoing maintenance burden.
• Roll new guardrails out in audit or monitoring mode before enforcing, since deploying strict policy blind against a real running environment can break production immediately.