Context: AWS production environment. Terraform 1.7+, AWS provider 5.x.
Our team uses the S3 backend for state, tags all resources with
Project, Environment, Owner, and CostCenter tags, and follows
CIS AWS Foundations Benchmark v3.0.

Role: Senior Cloud Infrastructure Engineer.

Instruction: Write a Terraform module for an S3 bucket that will store
application logs from an ECS Fargate service. Output the module in a
single main.tf with variables.tf and outputs.tf.

Specifications:
- Bucket versioning enabled
- Server-side encryption with AWS KMS (customer-managed key)
- Block all public access
- Lifecycle policy: transition to Glacier after 90 days, expire after 365 days
- Bucket policy restricting access to a specific IAM role ARN (variable)
- Access logging to a separate logging bucket (variable)
- Object lock disabled (logs are not immutable for this use case)

Pattern: Follow HashiCorp's module structure. Use variable validation
blocks. Include a README-style comment block at the top of main.tf.

The difference in output quality is stark. The CRISP prompt produces a module that a senior engineer would approve in code review. The weak prompt produces a starting point that requires 30 minutes of modification and security hardening.

Technique 1: Chain-of-Thought for Architecture Design

When asking an LLM to help with architectural decisions, explicitly request step-by-step reasoning. This forces the model to work through trade-offs rather than jumping to a recommendation.

I need to design a data pipeline that:
- Ingests 50,000 events/second from IoT sensors
- Transforms and enriches events with device metadata
- Stores processed events for 12 months of time-series queries
- Must run on AWS, budget: $8,000/month

Walk through your reasoning step by step:
1. Evaluate ingestion options (Kinesis vs MSK vs SQS)
2. Evaluate processing options (Lambda vs ECS vs Kinesis Analytics)
3. Evaluate storage options (Timestream vs DynamoDB vs InfluxDB on EC2)
4. Estimate monthly costs for your recommended architecture
5. Identify the single biggest risk and a mitigation strategy

The step-by-step structure prevents the model from recommending an architecture without considering cost, or recommending managed services when the budget does not support them.

Technique 2: Few-Shot Examples for Code Generation

When you need code that follows specific conventions, provide one or two examples of your team's style rather than describing the style in prose.

Generate a Terraform resource for an AWS Application Load Balancer
following the exact style of this example:

---
# Example: Our team's RDS module pattern
resource "aws_db_instance" "main" {
  identifier     = "${var.project}-${var.environment}-db"
  engine         = "postgres"
  engine_version = "16.2"
  instance_class = var.db_instance_class

  # Storage
  allocated_storage     = var.db_allocated_storage
  max_allocated_storage = var.db_max_allocated_storage
  storage_encrypted     = true
  kms_key_id           = var.kms_key_arn

  # Network
  db_subnet_group_name   = aws_db_subnet_group.main.name
  vpc_security_group_ids = [aws_security_group.db.id]

  # Tags
  tags = merge(var.common_tags, {
    Name        = "${var.project}-${var.environment}-db"
    Component   = "database"
    Terraform   = "true"
  })
}
---

Now generate the ALB resource following this same pattern:
naming convention, comment grouping, tag structure, and variable usage.
The ALB should be internal, in private subnets, with access logging
to an S3 bucket.

Few-shot examples are dramatically more effective than descriptions like "use consistent naming" or "follow best practices." The model mimics the specific patterns it sees.

Technique 3: Constraint Prompting for Security Reviews

When using LLMs for security analysis, provide explicit constraints to prevent the model from glossing over issues or giving superficial advice.

Review this IAM policy for security issues. Be adversarial — assume
an attacker has compromised the credentials of the principal using
this policy.

Constraints for your review:
- Flag any action that could lead to privilege escalation
- Flag any resource scope broader than necessary
- Flag any missing conditions (MFA, source IP, time-based)
- Flag any actions that allow data exfiltration
- For each finding, rate severity (CRITICAL/HIGH/MEDIUM/LOW)
  and provide the specific remediation

Policy:
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:*",
        "ec2:*",
        "iam:PassRole",
        "lambda:*",
        "sts:AssumeRole"
      ],
      "Resource": "*"
    }
  ]
}

The "be adversarial" instruction combined with specific review criteria produces findings that match what a human security reviewer would catch. Without these constraints, the model tends toward gentle suggestions rather than direct security findings.

Technique 4: Iterative Refinement for Incident Response

During production incidents, use LLMs as a troubleshooting partner through iterative conversation rather than single-shot prompts.

Round 1: Describe the symptoms

Production incident in progress. ECS Fargate service "payment-api"
in us-east-1 is returning HTTP 503 errors to 30% of requests.
Started 12 minutes ago. No recent deployments (last deploy was 6 hours ago).

CloudWatch metrics show:
- CPU: 45% average across 8 tasks
- Memory: 72% average
- ALB HealthyHostCount dropped from 8 to 5
- ALB TargetResponseTime p99 jumped from 200ms to 8,400ms

What are the top 3 most likely root causes? For each, give me
the specific AWS CLI command or CloudWatch query to confirm or rule it out.

Round 2: Feed back diagnostic results

Ran your diagnostics. Results:
1. ECS task stopped events show: "Essential container in task exited"
   with exit code 137 (OOM killed) for 3 tasks in the last 15 min
2. Container memory utilization was 98% before the OOM kills
3. No dependency (RDS, ElastiCache) issues detected

The service has been running at this task count and memory configuration
for 3 months without OOM. What changed? Give me commands to check for:
- Memory leak indicators
- Recent traffic pattern changes
- Container image differences (even without a deployment)

This iterative pattern mirrors how experienced SREs troubleshoot: form hypotheses, test them, narrow the scope, and iterate until the root cause is identified.

Technique 5: Template Generation with Validation Rules

When generating templates (CloudFormation, Kubernetes manifests, Ansible playbooks), include validation rules in your prompt so you can verify the output.

Generate a Kubernetes NetworkPolicy that:
1. Applies to pods with label app=payment-service in namespace production
2. Allows ingress only from pods with label app=api-gateway on port 8443
3. Allows ingress from monitoring namespace (label: purpose=monitoring) on port 9090
4. Allows egress to pods with label app=postgres on port 5432
5. Allows egress to kube-dns on port 53 (UDP and TCP)
6. Denies all other ingress and egress

After generating the NetworkPolicy, list these validation checks
I should perform:
- What happens if a pod in the "default" namespace tries to reach
  payment-service on port 8443?
- What happens if payment-service tries to reach an external API?
- What happens if monitoring tries to reach payment-service on port 8443
  (not 9090)?

The validation checklist at the end forces the model to verify its own output against the requirements, catching errors before you apply the manifest.

Technique 6: Runbook Generation

LLMs excel at generating structured runbooks from informal knowledge. Provide the scenario and expected structure:

Create an on-call runbook for this scenario:
"RDS PostgreSQL replica lag exceeds 30 seconds"

Structure:
1. ALERT CONTEXT (what triggers this, severity, SLA impact)
2. IMMEDIATE ASSESSMENT (3-5 diagnostic commands to run first)
3. COMMON CAUSES (ranked by frequency, with resolution for each)
4. ESCALATION CRITERIA (when to page the database team)
5. POST-INCIDENT (what to document, follow-up actions)

Environment: AWS RDS PostgreSQL 16, Multi-AZ, 2 read replicas,
db.r6g.2xlarge, 1TB storage, serving a Python Django application
with 2,000 req/sec read traffic across replicas.

Write for a mid-level engineer who has on-call access to AWS console
and CLI but is not a DBA.

Building AI-Assisted Cloud Workflows

The techniques above work in isolation, but the real productivity gains come from building workflows that chain multiple AI interactions:

1. Architecture Review Pipeline: Describe requirements, get architecture options with trade-offs, select an approach, generate IaC, review for security, generate tests
2. Incident Response Workflow: Describe symptoms, get diagnostic commands, feed results back, get root cause analysis, generate the postmortem template
3. Documentation Pipeline: Provide code, get architecture diagrams (as text), generate API docs, create runbooks, write ADRs (Architecture Decision Records)

AI agents — LLMs with tool access that can execute commands, read files, and iterate autonomously — represent the next step. Instead of copy-pasting CLI output back into a chat, an agent reads CloudWatch metrics, queries the API, and synthesizes findings directly.

Citadel Cloud Management's AI & ML courses cover prompt engineering, AI agent development, and LLM integration patterns specifically for cloud infrastructure contexts. The AI & ML Resources collection includes prompt template libraries, agent configuration examples, and RAG pipeline architectures for infrastructure knowledge bases.

Anti-Patterns to Avoid

Trusting output without verification. LLMs hallucinate. Terraform resources get invented, AWS service names get mangled, and IAM permissions get fabricated. Always validate generated IaC with terraform validate, terraform plan, and security scanning before applying.

Over-relying on single-shot prompts. Complex tasks benefit from multi-turn conversations. Break large requests into phases: design, implement, review, test.

Ignoring context window limits. Dumping an entire Terraform state file into a prompt overwhelms the model. Provide relevant excerpts, not entire files.

Using AI as a replacement for understanding. Prompt engineering accelerates engineers who understand cloud infrastructure. It does not replace the foundational knowledge needed to evaluate whether generated code is correct, secure, and cost-effective.

Developing Prompt Engineering Skills

Prompt engineering for cloud engineers is a skill that compounds with practice. Start by using the CRISP framework for your next three Terraform modules, then experiment with chain-of-thought prompts for architecture decisions, and build up to iterative incident response workflows.

The Cloud Toolkits collection at Citadel Cloud Management includes prompt template libraries organized by cloud engineering task type — infrastructure generation, security review, cost optimization, and incident response.

Ready to integrate AI into your cloud engineering workflow? Explore Citadel's AI and cloud courses for structured learning paths that combine prompt engineering with hands-on infrastructure skills. Browse the full resource catalog for production-ready templates and toolkits.