Infrastructure as Code for Data AI Prompt

Implement Infrastructure as Code (IaC) for this cloud data platform.

Cloud provider: {{provider}}
IaC tool: {{iac_tool}} (Terraform, Pulumi, CDK, Bicep)
Components to provision: {{components}}
Team: {{team}}

1. Why IaC for data infrastructure:
   - Reproducible: dev, staging, and prod environments are identical
   - Version-controlled: infrastructure changes are reviewed like code
   - Self-documenting: the Terraform / Pulumi code IS the documentation
   - Auditable: every change is in git history with the author

2. Terraform for cloud data resources:

   S3 bucket with lifecycle and logging:
   resource "aws_s3_bucket" "data_lake" {
     bucket = "${var.env}-data-lake-${var.account_id}"
     tags   = { Environment = var.env, Team = "data-engineering" }
   }

   Snowflake warehouse:
   resource "snowflake_warehouse" "analytics" {
     name           = "ANALYTICS_WH"
     warehouse_size = "SMALL"
     auto_suspend   = 60
     auto_resume    = true
   }

3. Module structure:
   modules/
     data_lake/         # S3 bucket + lifecycle + IAM
     snowflake_env/     # databases, warehouses, roles
     airflow_mwaa/      # MWAA environment + networking
     monitoring/        # CloudWatch dashboards + alarms

   environments/
     dev/main.tf        # calls modules with dev variables
     prod/main.tf       # calls modules with prod variables

4. State management:
   - Remote state: store in S3 + DynamoDB (AWS) or GCS (GCP) with locking
   - State locking: prevents concurrent runs from corrupting state
   - Separate state per environment: dev and prod should never share state

5. CI/CD for IaC:
   PR: terraform plan → post plan output as PR comment
   Merge to main: terraform apply (with approval gate for prod)
   Tool: Atlantis (open-source) or Terraform Cloud for automated plan/apply

Return: Terraform module structure, resource examples, state management configuration, and CI/CD pipeline for IaC.