Infrastructure-as-Code Review

Produce a structured infrastructure-as-code review that applies security, reliability, and operational quality standards to a specific body of IaC code. The output serves two purposes: an actionable review report for the code at hand (with findings by severity and specific remediation steps), and a reusable checklist the team can apply to every future IaC change. If the user provides actual code, analyze it and populate the findings table with real issues. If no code is provided, produce the checklist and a template findings report.

Required Inputs

Ask for these if not already provided:

• IaC tool — Terraform, CloudFormation, Pulumi, Ansible, or CDK
• Cloud provider — AWS, GCP, Azure, or multi-cloud
• What the code provisions — a brief description (e.g., "VPC, EKS cluster, and RDS instance for the payments service")
• Security policies or naming standards in use — any existing org standards to check against; if none, use sensible defaults
• The IaC code itself — paste or describe it; if not provided, produce the checklist template only and note findings require code

Output Format

IaC Review Report: [What Is Being Provisioned]

Reviewer: [Name / Claude] IaC Tool: [Terraform / CloudFormation / Pulumi / Ansible / CDK] Cloud Provider: [AWS / GCP / Azure] Code Location: [Repo path or PR link] Review Date: [Date] Overall Risk: [Critical / High / Medium / Low]

Executive Summary

Recommendation: [Approve / Approve with Required Changes / Block — one sentence rationale]

Findings

Critical Findings

CRIT-01: [Finding Title]

Current code:

# [paste the problematic snippet]
resource "aws_s3_bucket" "data" {
  bucket = "my-bucket"
  acl    = "public-read"   # PROBLEM: public read access
}

Remediation:

resource "aws_s3_bucket" "data" {
  bucket = "my-bucket"
}

resource "aws_s3_bucket_public_access_block" "data" {
  bucket                  = aws_s3_bucket.data.id
  block_public_acls       = true
  block_public_policy     = true
  ignore_public_acls      = true
  restrict_public_buckets = true
}

Why this matters: [One sentence linking the specific risk to business impact — data exposure, compliance violation, etc.]

CRIT-02: [Next Critical Finding — repeat structure]

High Findings

HIGH-01: [Finding Title]

Current code:

# [problematic snippet]

Remediation:

# [fixed snippet]

Medium Findings

MED-01: [Finding Title]

Remediation: [Prose or code snippet — choose whichever is clearer for this finding]

Low Findings

LOW-01: [Finding Title]

Reusable IaC Review Checklist

Use this checklist on every IaC pull request. Check every item; mark N/A only when the item genuinely does not apply to the resources being provisioned.

1. IAM and Access Control

• No wildcard actions ("*") in IAM policies — policies follow least-privilege
• No wildcard resource ("*") in IAM policies unless explicitly justified with a comment
• IAM roles use condition keys to restrict scope (e.g., aws:RequestedRegion, sts:ExternalId)
• No IAM access keys or credentials hardcoded or in plaintext variables
• EC2 / compute instances use instance profiles, not hardcoded credentials
• S3 bucket policies do not allow public access unless the bucket is explicitly a public asset bucket
• Cross-account trust policies name specific account IDs, not "*"
• Service accounts (GCP) / managed identities (Azure) follow naming conventions and have documented purpose

2. Secrets Management

• No secrets, passwords, tokens, or API keys in plaintext in any .tf, .yaml, or .json file
• No secrets in variable default values
• Secrets sourced from Secrets Manager / Parameter Store / Vault — not from environment variables passed at plan time
• sensitive = true is set on all output values and variables that contain secrets (Terraform)
• State backend is encrypted — no unencrypted state files contain sensitive data
• .gitignore or equivalent excludes *.tfvars, terraform.tfstate, and any file that may contain resolved secrets

3. Encryption at Rest

• Storage resources (S3, EBS, RDS, DynamoDB, GCS, Azure Blob) have encryption at rest enabled
• Customer-managed keys (CMK/KMS) are used where required by policy — not solely AWS/GCP/Azure managed keys
• KMS key rotation is enabled for all CMKs
• Database snapshots have encryption enabled
• Encryption is not disabled via encrypted = false or equivalent

4. Encryption in Transit

• Load balancers terminate TLS — HTTP-only listeners redirect to HTTPS or are absent
• Minimum TLS version is 1.2; TLS 1.0 and 1.1 are explicitly disabled
• RDS / database connections require SSL (require_ssl = true or equivalent parameter)
• Internal service-to-service calls use TLS where the network is not fully private
• S3 bucket policies include a Deny on non-TLS requests (aws:SecureTransport: false)

5. Network and Public Access

• Security groups / firewall rules do not permit 0.0.0.0/0 ingress except on ports 80/443 for public-facing services
• SSH (port 22) and RDP (port 3389) are not open to 0.0.0.0/0
• Databases are in private subnets — not directly internet-routable
• publicly_accessible = false on RDS instances unless explicitly required and documented
• VPC has flow logs enabled
• Network ACLs and security groups are layered (defense in depth)
• S3 bucket public access block is enabled at the account and bucket level

6. Logging, Monitoring, and Audit

• CloudTrail / Cloud Audit Logs / Azure Monitor is enabled across all regions
• S3 access logging is enabled on buckets containing sensitive or regulated data
• RDS enhanced monitoring or equivalent is enabled
• CloudWatch alarms or equivalent are defined for critical metrics (CPU, disk, error rate)
• Log retention periods are defined — logs not retained indefinitely or deleted within 7 days

7. Naming and Tagging Standards

• All resources follow the team's naming convention: [env]-[team]-[resource-type]-[identifier]
• Required tags are present on all taggable resources:
  • Environment (e.g., prod / staging / dev)
  • Team or Owner
  • Service or Application
  • CostCenter (if required by finance policy)
  • ManagedBy: terraform (or equivalent IaC tool tag)
• No resou