devopsLlama

Terraform Configuration Prompt (LLaMA / Ollama)

Terraform configurations without modules and variable abstraction become unmanageable at scale. This prompt enforces variable-driven configurations, proper tagging, and module structure from the start, preventing the "spaghetti Terraform" that accumulates when infrastructure grows incrementally without architectural planning. This variant is formatted for LLaMA / Ollama: Optimised for LLaMA 3, Mistral, and Ollama local models. Uses [INST] / <<SYS>> instruction format.

Prompt Template
[INST] <<SYS>>
You are a helpful, accurate, and detailed AI assistant. Follow the instructions carefully.
<</SYS>>

You are a senior DevOps engineer specialising in Terraform and infrastructure as code.

Write a Terraform configuration for the following infrastructure:

Cloud provider: {{provider}}
Resources to create: {{resources}}
Environment: {{environment}}
Region: {{region}}
State backend: {{state_backend}}
Additional requirements: {{additional_requirements}}

The configuration must follow these best practices:
- Use variables for all environment-specific values
- Use locals for computed values and repeated expressions
- Add tags/labels to all resources with environment, project, and managed-by tags
- Use data sources to reference existing resources rather than hardcoding IDs
- Add descriptions to all variables and outputs
- Structure as reusable modules where appropriate

Provide:
1. Main configuration files (main.tf, variables.tf, outputs.tf)
2. terraform.tfvars.example with all required variables
3. README snippet explaining the module's purpose and usage [/INST]

Variables

{{provider}}Cloud provider: AWS, GCP, Azure, or multi-cloud
{{resources}}Resources to create, e.g., "VPC with public/private subnets, ECS cluster, RDS PostgreSQL, S3 bucket"
{{environment}}Target environment: dev, staging, production
{{region}}Cloud region, e.g., "us-east-1", "eu-west-2"
{{state_backend}}Terraform state storage: "S3 with DynamoDB locking", "GCS", "local", "Terraform Cloud"
{{additional_requirements}}Extra requirements, or "None"

Example

Input
provider: AWS
resources: ECS Fargate cluster, Application Load Balancer, RDS PostgreSQL, VPC
environment: production
region: us-east-1
state_backend: S3 with DynamoDB locking
additional_requirements: Use existing VPC, encrypt RDS at rest
Output
# main.tf
terraform {
  required_providers {
    aws = { source = "hashicorp/aws", version = "~> 5.0" }
  }
  backend "s3" {
    bucket         = var.state_bucket
    key            = "production/terraform.tfstate"
    region         = var.region
    dynamodb_table = var.lock_table
    encrypt        = true
  }
}

resource "aws_ecs_cluster" "main" {
  name = "${var.project}-${var.environment}"
  tags = local.common_tags
}

Related Tools

FAQ

How do I manage Terraform state for multiple environments?
Use separate state files per environment (separate S3 keys or workspaces). Terraform workspaces are simpler but mix state in one backend. Separate directories per environment (environments/dev, environments/prod) is more explicit and safer.
How do I import existing resources into Terraform state?
Use `terraform import resource_type.name resource_id` to bring existing infrastructure under Terraform management. Write the resource configuration first, then import. Alternatively, use the experimental `terraform import` block in Terraform 1.5+.
What is the difference between count and for_each?
Use `count` for simple replication of identical resources. Use `for_each` with a map when resources have meaningful keys (prevents Terraform from destroying and recreating resources when the order changes in a list).

Related Prompts