Infrastructure as a Prompt: Kubernetes and Terraform Tricks That Won't Break Production

Terraform plans and Kubernetes manifests look deceptively simple — until a typo in a resource limit takes down a node, or an overly permissive IAM policy opens a backdoor. In 2026, AI assistants can generate, review, and debug infrastructure code faster than ever, but only if you ask the right questions. This collection is not about magic; it's about prompts that force the model to think like a senior SRE: check constraints, explain trade-offs, and never assume defaults.

I've tested these prompts across real clusters (EKS, GKE) and Terraform workspaces with hundreds of resources. Each one includes a concrete example and a note on when to use it. Remember: AI is a co-pilot, not an auto-pilot. Always run terraform plan and kubectl diff before applying anything to production. The goal is to reduce toil, not to skip review.

Below are 10 battle-tested prompts for Kubernetes and Terraform. They cover manifest generation, debugging CrashLoopBackOff, HPA tuning, security review, and cost-aware IaC. Use them as starting points and adapt to your environment.

1. Generate a production-ready Kubernetes Deployment with resource limits and probes

When to use: You need a baseline manifest for a stateless service that follows best practices: resource requests/limits, liveness and readiness probes, security context, and anti-affinity.

Prompt:

Generate a Kubernetes Deployment manifest for a Node.js API (image: myregistry/api:1.2.3) with 3 replicas. Requirements:
- CPU request 100m, limit 500m; memory request 128Mi, limit 256Mi.
- Liveness probe: HTTP GET /healthz on port 3000, initialDelay 10s, period 5s.
- Readiness probe: HTTP GET /ready on port 3000, initialDelay 5s.
- Security context: runAsNonRoot, readOnlyRootFilesystem, drop all capabilities.
- Pod anti-affinity to spread replicas across nodes.
- Add annotations for Prometheus scraping.
Explain each choice briefly.

Example output (abridged):

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api
spec:
  replicas: 3
  selector:
    matchLabels:
      app: api
  template:
    metadata:
      labels:
        app: api
      annotations:
        prometheus.io/scrape: "true"
        prometheus.io/port: "3000"
    spec:
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchLabels:
                app: api
            topologyKey: kubernetes.io/hostname
      containers:
      - name: api
        image: myregistry/api:1.2.3
        resources:
          requests:
            cpu: "100m"
            memory: "128Mi"
          limits:
            cpu: "500m"
            memory: "256Mi"
        livenessProbe:
          httpGet:
            path: /healthz
            port: 3000
          initialDelaySeconds: 10
          periodSeconds: 5
        readinessProbe:
          httpGet:
            path: /ready
            port: 3000
          initialDelaySeconds: 5
        securityContext:
          runAsNonRoot: true
          readOnlyRootFilesystem: true
          capabilities:
            drop: ["ALL"]

Why it works: The model doesn't just dump a template; it justifies each field, so you learn and can spot missing pieces (e.g., no runAsUser — you might add it).

2. Debug CrashLoopBackOff from logs and events

When to use: A pod is stuck in CrashLoopBackOff and you have kubectl describe and logs but no clear cause.

Prompt:

My pod is in CrashLoopBackOff. Here are the last 50 lines of logs and the output of `kubectl describe pod`. Identify the most likely root cause and suggest a fix. Logs:
<logs>
Events:
<events>

Example: A Python worker fails with ModuleNotFoundError: No module named 'psycopg2'. The model might suggest adding the dependency to the image or using an initContainer. It could also notice a missing ConfigMap mount from the events.

Why it works: It forces the model to cross-reference logs and events, mimicking a human debugging session.

3. Write a Terraform module for an S3 bucket with encryption and logging

When to use: You need a reusable, secure S3 bucket module for multiple environments.

Prompt:

Create a Terraform module (variables.tf, main.tf, outputs.tf) for an S3 bucket with:
- Server-side encryption (AES256).
- Versioning enabled.
- Access logging to a separate bucket.
- Block public access.
- Lifecycle rule to transition to Glacier after 30 days.
- Tags: Environment, Project.
Provide a usage example.

Example output (main.tf excerpt):

resource "aws_s3_bucket" "this" {
  bucket = var.bucket_name
  tags   = var.tags
}

resource "aws_s3_bucket_server_side_encryption_configuration" "this" {
  bucket = aws_s3_bucket.this.id
  rule {
    apply_server_side_encryption_by_default {
      sse_algorithm = "AES256"
    }
  }
}

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

Why it works: It follows current AWS provider best practices (separate resources for encryption and public access block) and reminds you to enable logging.

4. Review a Terraform plan for security and cost pitfalls

When to use: You have a terraform plan output and want a second pair of eyes before applying.

Prompt:

Analyze this Terraform plan. Highlight any security risks (open ports, public buckets, overly permissive IAM) and cost anomalies (unexpected instance types, large volumes). Suggest concrete changes.
Plan:
<plan output>

Example: The model might flag aws_security_group with ingress from 0.0.0.0/0 on port 22 and recommend restricting to a bastion CIDR. It could also notice an m5.24xlarge instance that seems overkill for a dev environment.

Why it works: It turns a dry plan into an actionable security review.

5. Tune Horizontal Pod Autoscaler (HPA) with custom metrics

When to use: Your HPA scales on CPU but you need to scale on request rate or queue length.

Prompt:

Write an HPA manifest that scales a Deployment between 2 and 10 replicas based on a custom metric `http_requests_per_second` from Prometheus. Target value: 100 rps per pod. Include the necessary annotations and a brief explanation of how the metric is fetched.

Example output:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: api-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: api
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Pods
    pods:
      metric:
        name: http_requests_per_second
      target:
        type: AverageValue
        averageValue: 100

Why it works: It uses autoscaling/v2 and explains that you need a Prometheus adapter.

6. Generate a Kubernetes NetworkPolicy to restrict traffic

When to use: You want to isolate a namespace or allow only specific ingress/egress.

Prompt:

Create a NetworkPolicy that allows ingress to pods with label `app=api` only from pods with label `app=frontend` on port 3000, and denies all other ingress. Also allow egress to DNS (port 53) and to a PostgreSQL pod with label `app=db` on port 5432.

Example output:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: api-policy
spec:
  podSelector:
    matchLabels:
      app: api
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend
    ports:
    - protocol: TCP
      port: 3000
  egress:
  - to:
    - podSelector:
        matchLabels:
          app: db
    ports:
    - protocol: TCP
      port: 5432
  - ports:
    - protocol: UDP
      port: 53

Why it works: It correctly uses podSelector and separates ingress/egress rules.

7. Convert docker-compose to Kubernetes manifests

When to use: You have a docker-compose.yml and want to migrate to Kubernetes.

Prompt:

Convert this docker-compose.yml to Kubernetes manifests (Deployment, Service, ConfigMap, Secret). Preserve environment variables and volume mounts. Use best practices for resource limits and probes.

Example: The model outputs a Deployment with envFrom ConfigMap and Secret, and a ClusterIP Service. It also suggests adding liveness probes if missing.

Why it works: It saves hours of manual translation and highlights missing pieces.

8. Write a Terraform configuration for a GKE cluster with node auto-provisioning

When to use: You need a managed Kubernetes cluster with autoscaling.

Prompt:

Create Terraform code for a GKE cluster in us-central1 with:
- Node auto-provisioning enabled.
- Private nodes (no public IPs).
- Workload Identity enabled.
- Master authorized networks restricted to a specific CIDR.
- Release channel: stable.
Provide the necessary google_container_cluster resource.

Example output (excerpt):

resource "google_container_cluster" "primary" {
  name     = "gke-cluster"
  location = "us-central1"
  release_channel {
    channel = "STABLE"
  }
  private_cluster_config {
    enable_private_nodes    = true
    enable_private_endpoint = false
    master_ipv4_cidr_block  = "172.16.0.0/28"
  }
  master_authorized_networks_config {
    cidr_blocks {
      cidr_block   = "203.0.113.0/24"
      display_name = "office"
    }
  }
  workload_identity_config {
    workload_pool = "${var.project_id}.svc.id.goog"
  }
  cluster_autoscaling {
    enabled = true
    auto_provisioning_defaults {
      service_account = google_service_account.gke_sa.email
    }
  }
}

Why it works: It includes security best practices like private nodes and Workload Identity.

9. Generate a Kubernetes CronJob with concurrency policy and backoff limit

When to use: You need a scheduled job (e.g., nightly backup) with safe defaults.

Prompt:

Create a CronJob that runs every day at 2 AM, runs a Python script from image myregistry/backup:latest, and:
- Sets concurrencyPolicy to Forbid.
- Sets backoffLimit to 2.
- Adds a 1-hour activeDeadlineSeconds.
- Mounts a PersistentVolumeClaim named backup-pvc at /backup.

Example output:

apiVersion: batch/v1
kind: CronJob
metadata:
  name: backup
spec:
  schedule: "0 2 * * *"
  concurrencyPolicy: Forbid
  jobTemplate:
    spec:
      backoffLimit: 2
      activeDeadlineSeconds: 3600
      template:
        spec:
          containers:
          - name: backup
            image: myregistry/backup:latest
            volumeMounts:
            - name: backup-storage
              mountPath: /backup
          volumes:
          - name: backup-storage
            persistentVolumeClaim:
              claimName: backup-pvc
          restartPolicy: OnFailure

Why it works: It correctly sets concurrencyPolicy and activeDeadlineSeconds to avoid overlapping jobs.

10. Explain a Terraform state error and suggest recovery steps

When to use: terraform apply fails with a state lock or drift error.

Prompt:

I got this error: "Error: Error acquiring the state lock". Explain the likely causes and give step-by-step recovery commands without losing state.

Example: The model explains that another process may hold the lock, and suggests checking terraform force-unlock <lock-id> after verifying no other apply is running. It also warns about state corruption.

Why it works: It provides a safe path to resolution, reducing panic.

These prompts are not a replacement for understanding Kubernetes and Terraform internals. They are accelerators. Always validate outputs with kubectl diff, terraform plan, and your team's code review. For deeper learning, check the official Kubernetes documentation (kubernetes.io/docs) and Terraform Registry (registry.terraform.io). Used wisely, AI can turn infrastructure text into reliable, secure, and cost-effective production systems.

Start with one prompt today — pick the one that solves your current pain. Then iterate: refine the prompt, add constraints, and share your improved versions with your team. The best prompt is the one that saves you from a 3 AM incident.