Terraform Cheatsheet

Quick reference for Terraform infrastructure as code, HCL syntax, and best practices

Security-First IaC: Benchmarking LLMs for Terraform Generation

Can artificial intelligence write Infrastructure as Code that's as secure as human-written? We benchmark the top LLMs to find out.

The IaC Security Challenge

Infrastructure as Code (IaC) has transformed DevOps, enabling reproducible, version-controlled infrastructure deployments. But with this power comes responsibility — security vulnerabilities in IaC templates can have catastrophic consequences.

Common IaC security issues:

• Insecure defaults — Open security groups, public buckets, unrestricted access
• Hardcoded secrets — API keys, passwords, certificates in plain text
• Overly permissive policies — * permissions in IAM roles
• Missing encryption — Unencrypted databases, S3 buckets
• Outdated configurations — Deprecated security practices
• Lack of validation — No security scanning before deployment

The OWASP Top 10 for IaC highlights these risks, with misconfigurations being the #1 cause of cloud security breaches.

Now, Large Language Models are entering the IaC space, promising to accelerate Terraform development. The question is: are they generating secure configurations, or are they introducing new risks?

Why Security-First IaC Matters

The stakes are high:

• Financial — Data breaches average $4.45M (IBM 2023)
• Reputational — Customer trust is hard to earn, easy to lose
• Operational — Security incidents cause downtime and fire drills
• Compliance — Many industries require strict configuration standards
• Technical — Insecure infrastructure is harder to manage and scale

A single insecure Terraform module can expose your entire cloud estate.

Benchmark Methodology

We evaluated 6 leading LLMs (GPT-4o, Claude 3.5 Sonnet, Mistral-large, Llama-3.1-70B, Gemma-2-27B, DeepSeek-Coder) on their ability to generate secure Terraform configurations for common cloud infrastructure patterns.

Evaluation Criteria

Each model was scored across 8 security dimensions:

Test Scenarios

We evaluated each model on 10 common infrastructure patterns:

1. Secure Web Application — EC2 instances with ALB, RDS, S3
2. Serverless API — Lambda, API Gateway, DynamoDB
3. Kubernetes Cluster — EKS with proper IAM roles
4. Data Lake — S3 buckets with encryption and access controls
5. CI/CD Pipeline — CodePipeline with least privilege
6. Monitoring Stack — CloudWatch, Prometheus, Grafana
7. VPC with Multi-AZ — Proper network segmentation
8. Database Cluster — RDS Aurora with security best practices
9. Static Website — CloudFront + S3 with proper caching
10. Disaster Recovery — Multi-region failover setup

Scoring System

• ✅ Secure (3 points) — Follows best practices, no security issues
• ⚠️ Moderate (2 points) — Minor issues, acceptable with remediation
• ❌ Insecure (0 points) — Critical security issues, production_unready

Results Summary

Detailed Findings

1. Secrets Management — The Clear Winner

Best: GPT-4o (97%), Claude 3.5 Sonnet (95%)

All models correctly avoided hardcoded secrets in the generated code. However, there were differences in how they handled secrets:

• ✅ GPT-4o: Used AWS Secrets Manager with proper IAM access patterns
• ✅ Claude: Used SSM Parameter Store with encryption
• ⚠️ Others: Used environment variables (still vulnerable to exposure)

Example of Good Secrets Management:

# ✅ Secure: Reference AWS Secrets Manager
data "aws_secretsmanager_secret_version" "db_password" {
  secret_id = "prod/rds/password"
}

resource "aws_db_instance" "example" {
  # ...
  password = data.aws_secretsmanager_secret_version.db_password.secret_string
  # ...
}

Example of Bad Secrets Management:

# ❌ Insecure: Hardcoded password
resource "aws_db_instance" "example" {
  password = "SuperSecretPassword123!"
}

2. Network Security — Room for Improvement

Best: GPT-4o (90%), Claude 3.5 Sonnet (88%)

Most models created secure VPC configurations, but many missed key security controls:

The Network Security Gap: Most models generated functional network configurations but missed defense-in-depth principles.

3. IAM & Access Control — The Achille's Heel

Best: Claude 3.5 Sonnet (93%), GPT-4o (91%)

IAM policies were where models struggled the most:

Example of Poor IAM Policy:

# ❌ Overly permissive
resource "aws_iam_role_policy" "lambda_policy" {
  role = aws_iam_role.lambda.id
  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Action   = "*"           # 🚨 All actions!
        Effect   = "Allow"
        Resource = "*"           # 🚨 All resources!
      }
    ]
  })
}

Example of Good IAM Policy:

# ✅ Least privilege
resource "aws_iam_role_policy" "lambda_policy" {
  role = aws_iam_role.lambda.id
  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Effect   = "Allow"
        Action   = [
          "dynamodb:GetItem",
          "dynamodb:PutItem",
          "dynamodb:UpdateItem"
        ]
        Resource = aws_dynamodb_table.my_table.arn
      },
      {
        Effect   = "Allow"
        Action   = [
          "logs:CreateLogGroup",
          "logs:CreateLogStream",
          "logs:PutLogEvents"
        ]
        Resource = "*"
      }
    ]
  })
}

4. Encryption — A Mixed Bag

Best: GPT-4o (95%), Claude 3.5 Sonnet (94%)

Most models enabled encryption, but often in inconsistent ways:

Missing Encryption was the most common critical finding.

5-8. Other Dimensions

• Resource Hardening: 78-85% — Most models remembered basics (disable debug, enable logging)
• Compliance: 70-82% — Alignment with standards was inconsistent
• Code Quality: 85-92% — Most generated valid Terraform
• Explainability: 65-80% — Documentation varied widely

The Security Maturity Model

Based on our findings, we developed a Security Maturity Model for LLM-generated Terraform:

Level 1: Functional (0-70%)

• Code works and deploys
• But contains significant security gaps
• Example: Llama-3.1-70B, Gemma-2-27B

Level 2: Secure-ish (70-85%)

• Follows basic security practices
• May miss defense-in-depth controls
• Example: Mistral-large

Level 3: Production-Ready (85-95%)

• Follows best practices consistently
• Minor issues that are easily fixable
• Example: GPT-4o, Claude 3.5 Sonnet

Level 4: Enterprise-Grade (95-100%)

• Fatal checks
• Not yet achieved by any model

Recommendations

Based on our benchmarking, here are our recommendations:

For Production Use

1. Use GPT-4o or Claude 3.5 Sonnet — Highest security scores
2. Always review generated code — No model is 100% reliable
3. Use security-focused prompts — Explicitly ask for secure configurations
4. Implement automated scanning — Use tools like Checkov, TFSec, or Snyk
5. Provide examples — Models learn from your existing secure code

Security-First Prompt Engineering

Here's a prompt template that significantly improves security:

You are a professional DevOps engineer specializing in SECURE Infrastructure as Code.

When generating Terraform code, you MUST follow these security requirements:

1. NEVER hardcode secrets, passwords, or API keys. Use instead:
   - AWS: SSM Parameter Store or Secrets Manager
   - Azure: Key Vault
   - GCP: Secret Manager
   - General: Environment variables with sensitive = true

2. Network Security:
   - Use private subnets by default
   - Restrict inbound traffic to minimum required ports
   - Enable VPC Flow Logs
   - Use security groups as a secondary layer of defense

3. IAM & Access Control:
   - Follow the principle of least privilege
   - NEVER use wildcard (*) permissions
   - Use condition blocks to restrict access further
   - Prefer resource-level permissions over broad policies

4. Encryption:
   - Enable encryption at rest for all data stores
   - Use customer-managed KMS keys when possible
   - Enable TLS 1.2+ for all communications

5. Resource Hardening:
   - Disable debug endpoints in production
   - Enable detailed logging with appropriate retention
   - Use recent, supported versions of resources

6. Compliance:
   - Follow CIS benchmarks where applicable
   - Tag resources appropriately
   - Enable deletion protection on critical resources

Now, please generate Terraform code for: [YOUR REQUEST]

For each decision you make, explain your security rationale.

Automated Security Validation

Always scan LLM-generated Terraform with security tools:

# Install security scanning tools
npm install -g tfsec
pip install checkov

# Scan your Terraform
checkov -d /path/to/terraform
 tfsec /path/to/terraform

# For CI/CD integration
checkov -d . --soft-fail && tfsec . --soft-fail

Recommended Tools:

• Checkov — Policy-as-code for Terraform (open source)
• TFSec — Static analysis for Terraform (open source)
• Snyk Infrastructure as Code — Cloud-native security scanning
• Terrascan — Detect compliance and security violations
• Trivy — Vulnerability scanning for Terraform

The Hybrid Approach

The most secure approach combines LLM generation with security automation:

LLM generates Terraform
    │
    ▼
┌─────────────────┐
│ Security Scanner │──▶ Report vulnerabilities
└─────────────────┘
    │
    ▼
    Fix issues
    │
    ▼
┌─────────────────┐
│ Human Review     │──▶ Approve or reject
└─────────────────┘
    │
    ▼
┌─────────────────┐
│ Deployment       │
└─────────────────┘
    │
    ▼
┌─────────────────┐
│ Continuous       │
│ Monitoring       │
└─────────────────┘

Case Studies

Case Study 1: Financial Services Company

Challenge: Fast-growing fintech needed to scale infrastructure while maintaining PCI-DSS compliance

Solution:

• Used GPT-4o with security-focused prompts
• Implemented Checkov for automated scanning
• Built review workflow with security team

Results:

• Development speed: 3.2x faster (from 2 weeks to 3-4 days)
• Security issues: 94% reduction
• Compliance: Passed PCI-DSS audit
• Cost savings: $200K annual (fewer cloud resources wasted)

Case Study 2: Healthcare Startup

Challenge: Needed HIPAA-compliant infrastructure with minimal DevOps staff

Solution:

• Used Claude 3 Sonnet with custom HIPAA prompt templates
• Integrated Snyk for continuous monitoring
• Automated compliance checks in CI/CD

Results:

• Infrastructure setup: 80% faster
• Compliance gaps: Caught and fixed before deployment
• Audit readiness: Always prepared for HIPAA audits

The Future of Secure IaC

1. Security-by-Design AI Models

AI models specifically trained for security — not just general-purpose LLMs. These models would:

• Understand security best practices at a deeper level
• Be less likely to generate insecure patterns
• Explain security decisions in detail

2. Automated Remediation

AI that doesn't just find security issues, but fixes them:

AI generates Terraform ---> Security scan ---> Fix suggested ---> Auto-apply

3. Continuous Compliance

Real-time monitoring and compliance checking:

• Detect drift from intended configurations
• Automatic remediation of compliance violations
• Always-ready audit reports

4. Context-Aware Generation

AI that generates code based on your specific security context:

• Organization's security policies
• Industry regulations
• Existing infrastructure patterns
• Team's expertise and preferences

Conclusion

LLMs show great promise for generating Terraform configurations, with top models achieving 90%+ security scores. However, no model is perfect — all generated code needs review and validation.

The key to success with AI-powered IaC is an approach:

1. Use the best models — GPT-4o and Claude 3.5 Sonnet for now
2. Security-first prompts — Explicitly guide the model toward secure practices
3. Always scan — Use automated security tools as a safety net
4. Review and learn — Use human expertise to catch what AI misses
5. Continuously improve — Feed good examples back into the process

AI can dramatically accelerate IaC development, but security must come first. With the right approach, you can have both speed and security — the holy grail of modern DevOps.

Want to dive deeper? Check out our Text to Terraform Security Analysis and Kubernetes v1.37 Release Notes for more on infrastructure security.

For hands-on learning, explore our Open Source Infrastructure Stack for 2026.