AI Prompts Library

You are a cloud infrastructure expert who reviews Infrastructure as Code (IaC) for security, reliability, and best practices. Review the provided IaC code.

**IaC Code to Review:**
[PASTE TERRAFORM, CLOUDFORMATION, PULUMI, OR CDK CODE HERE]

**IaC Tool:** [Terraform / CloudFormation / Pulumi / CDK / Ansible]
**Cloud Provider:** [AWS / GCP / Azure / Multi-cloud]
**Environment:** [Development / Staging / Production]
**Compliance Requirements:** [SOC 2 / HIPAA / PCI-DSS / None specific]

**Review Checklist:**

1. **Security Review:**
   - [ ] No hardcoded secrets, API keys, or passwords
   - [ ] S3 buckets/storage not publicly accessible
   - [ ] Security groups/firewall rules follow least privilege
   - [ ] Encryption enabled for all data stores
   - [ ] IAM roles have minimal required permissions
   - [ ] VPC/network configuration is secure
   - [ ] Logging and monitoring enabled on all resources
   - [ ] WAF/DDoS protection configured
   - [ ] Database instances not publicly accessible
   - [ ] KMS keys used for sensitive data encryption

2. **Reliability Review:**
   - [ ] Multi-AZ or multi-region deployment for critical services
   - [ ] Auto-scaling configured with appropriate min/max
   - [ ] Health checks defined for all services
   - [ ] Backup and disaster recovery configured
   - [ ] Connection draining and graceful shutdown
   - [ ] Circuit breakers for external dependencies

3. **Cost Optimization:**
   - [ ] Right-sized instances (not over-provisioned)
   - [ ] Reserved instances or savings plans for steady-state workloads
   - [ ] Lifecycle policies for storage (transition to cheaper tiers)
   - [ ] Unused resources identified
   - [ ] Cost allocation tags on all resources

4. **Code Quality:**
   - [ ] Modules used for reusable components
   - [ ] Variables have descriptions and validation rules
   - [ ] Outputs defined for cross-module references
   - [ ] State management properly configured (remote backend, locking)
   - [ ] Naming conventions consistent
   - [ ] Resource tagging strategy implemented

5. **Operational Readiness:**
   - [ ] CloudWatch/monitoring alarms configured
   - [ ] SNS/PagerDuty notifications for critical alerts
   - [ ] Runbook documentation for manual operations
   - [ ] Terraform plan reviewed before apply

**Output**: Findings report with severity, location, explanation, and remediation code for each issue.

You are an observability engineer designing a comprehensive monitoring and alerting system. Create a monitoring setup plan for the described application.

**Application:** [APP_NAME and DESCRIPTION]
**Architecture:** [Monolith / Microservices / Serverless / Hybrid]
**Infrastructure:** [AWS / GCP / Azure / On-premise]
**Current Monitoring Tools:** [Datadog / Grafana / CloudWatch / Prometheus / New Relic / None]
**SLA Requirements:** [e.g., 99.9% uptime, <200ms p95 latency]
**On-call Team Size:** [NUMBER]

**Generate a Monitoring Plan:**

1. **The Four Golden Signals:**
   For each service/component:
   - **Latency**: What to measure, threshold values (p50, p95, p99)
   - **Traffic**: Request rate, throughput metrics
   - **Errors**: Error rate, error types, 5xx vs 4xx
   - **Saturation**: CPU, memory, disk, connection pool utilization

2. **Infrastructure Metrics:**
   - Server/container health (CPU, memory, disk, network)
   - Database metrics (connections, query time, replication lag, deadlocks)
   - Cache metrics (hit rate, memory usage, evictions)
   - Queue metrics (depth, processing rate, age of oldest message)
   - Load balancer metrics (healthy hosts, response time, error rate)

3. **Application Metrics (custom):**
   - Business metrics (signups, purchases, key user actions)
   - Feature usage metrics
   - Background job metrics (success rate, duration, queue depth)
   - Third-party API metrics (latency, error rate, availability)

4. **Alert Configuration:**
   For each alert:
   - Alert name and description
   - Condition (threshold, anomaly, or rate of change)
   - Severity (P1-P4)
   - Notification channel (PagerDuty, Slack, email)
   - Runbook link
   - Auto-resolution criteria
   - Alert fatigue prevention (grouping, deduplication, silence windows)

5. **Dashboard Design:**
   - Executive dashboard (top-level health)
   - Service dashboard (per-service detail)
   - On-call dashboard (active alerts, recent incidents)
   - Capacity planning dashboard (trend lines)
   - For each dashboard: Layout, key widgets, refresh interval

6. **SLO/SLI Framework:**
   - Define SLIs for each critical user journey
   - Set SLO targets with error budget
   - Burn rate alerting configuration
   - Error budget policy (what happens when budget is exhausted)

7. **Logging Strategy:**
   - Structured logging format
   - Log levels and when to use each
   - Correlation IDs for distributed tracing
   - Log retention and archival policy

**Output**: Complete monitoring specification document with alert definitions, dashboard wireframes, and SLO framework.

You are a disaster recovery specialist. Create a comprehensive DR plan for the described system.

**System:** [SYSTEM_NAME and DESCRIPTION]
**Business Criticality:** [Mission-critical / Business-critical / Important / Non-essential]
**Current Infrastructure:** [DESCRIBE: cloud provider, regions, key services]
**RPO Requirement:** [Recovery Point Objective - maximum acceptable data loss, e.g., 1 hour]
**RTO Requirement:** [Recovery Time Objective - maximum acceptable downtime, e.g., 4 hours]
**Compliance:** [ANY_REQUIREMENTS]

**Generate a Disaster Recovery Plan:**

1. **Risk Assessment:**
   - Identify potential disaster scenarios:
     - Cloud provider region outage
     - Data corruption or deletion
     - Ransomware or security breach
     - Database failure
     - DNS failure
     - Third-party service outage
     - Natural disaster affecting data center
   - For each: Likelihood, Impact, Current mitigation status

2. **DR Strategy:**
   - Active-Active / Active-Passive / Pilot Light / Backup & Restore
   - Justify the chosen strategy based on RPO/RTO and cost
   - Architecture diagram description for the DR setup
   - Data replication strategy (synchronous, asynchronous, frequency)

3. **Backup Strategy:**
   - What is backed up (databases, file storage, configurations, secrets)
   - Backup frequency and retention schedule
   - Backup storage location (cross-region, cross-account)
   - Backup encryption and access controls
   - Backup verification and restore testing schedule

4. **Recovery Procedures:**
   For each disaster scenario:
   - Step-by-step recovery procedure with exact commands
   - Estimated recovery time for each step
   - Decision tree for choosing recovery path
   - Validation checks after recovery
   - Data integrity verification

5. **Failover Process:**
   - Automated failover triggers and conditions
   - Manual failover procedure with approval chain
   - DNS failover strategy (TTL settings, health checks)
   - Database failover procedure
   - Application state recovery
   - Client-side retry and reconnection behavior

6. **Communication Plan:**
   - Internal notification chain
   - Customer communication templates
   - Status page updates
   - Regulatory notification requirements

7. **Testing Schedule:**
   - Quarterly DR drill procedure
   - Annual full failover test
   - Tabletop exercise format
   - Post-test review template
   - Chaos engineering experiments to validate resilience

8. **Documentation:**
   - Contact list (on-call, vendors, management)
   - Access credentials location (break-glass procedures)
   - Architecture diagrams and dependency maps
   - Vendor support contract details

**Output**: Complete DR plan document with procedures, diagrams, and testing schedules.