Multi-Region Resilience Architecture Audit Prompt

This prompt is for cloud architects, SREs, and platform engineers who need a structured, evidence-based audit of a multi-region architecture design before it is approved or implemented. It is not a replacement for chaos engineering or live failover testing. Use this prompt when you have a design document, architecture diagram, or configuration spec and need to identify gaps in failover triggers, consistency trade-offs, capacity planning, and DNS/routing cutover. The prompt forces the model to act as a skeptical reviewer, not a design cheerleader, and requires specific inputs about regions, data stores, and routing to produce a useful audit.

The ideal user brings a concrete design artifact—a written proposal, a Terraform plan, a cloud architecture diagram, or a configuration specification—that describes at least two regions, the data replication strategy, and the intended failover mechanism. The prompt is most effective when the design is detailed enough to be critiqued. Vague inputs produce vague audits. The model will interrogate assumptions about regional capacity, consistency models, and cutover procedures, so the input must contain enough detail for the model to find real gaps rather than inventing hypothetical ones.

Do not use this prompt for single-region deployments, pure network topology reviews, or real-time incident response. It is a design-time review tool, not an operational runbook. Avoid using it when the architecture is still in the brainstorming phase without concrete decisions about data stores, replication, or routing. The prompt assumes a multi-region design exists and needs hardening. If you need a prompt for evaluating a single region's resilience patterns, use the Circuit Breaker Design Review or Retry Policy Configuration Analysis prompts instead. For live incident diagnosis, use the Operational Incident and Runbook Prompts pillar.

This prompt template is designed to be pasted directly into your AI workspace. It instructs the model to act as a principal cloud architect conducting a structured audit of a multi-region deployment. The template uses square-bracket placeholders for all variable inputs, such as your architecture description, specific risk tolerances, and the desired output format. Before using it, ensure you have gathered your architecture diagrams, service dependency maps, and any existing disaster recovery documentation. This prompt is most effective when the provided context is detailed and specific; vague inputs will produce a generic, less actionable audit.

textCopy
You are a principal cloud architect specializing in multi-region resilience for high-availability systems. Your task is to conduct a rigorous, structured audit of the provided system architecture. You must identify single points of failure, evaluate data consistency trade-offs, and assess the robustness of failover mechanisms. Your analysis must be evidence-based, referencing only the provided context.

**INPUT ARCHITECTURE:**
[ARCHITECTURE_DESCRIPTION]

**AUDIT PARAMETERS:**
- Recovery Time Objective (RTO): [RTO_IN_SECONDS]
- Recovery Point Objective (RPO): [RPO_IN_SECONDS]
- Primary Consistency Model: [CONSISTENCY_MODEL]
- Regions Involved: [REGION_LIST]
- Key User Flows: [CRITICAL_USER_FLOWS]

**OUTPUT SCHEMA:**
You must produce a JSON object conforming to the following structure. Do not include any text outside the JSON block.
{
  "audit_summary": {
    "overall_risk_level": "low|medium|high|critical",
    "primary_concerns": ["string"]
  },
  "failover_analysis": {
    "trigger_mechanism_review": "string",
    "dns_routing_cutover_assessment": "string",
    "estimated_switchover_time_seconds": number
  },
  "data_replication_audit": {
    "consistency_conflicts": ["string"],
    "split_brain_risk": "low|medium|high",
    "data_loss_scenarios": ["string"]
  },
  "capacity_assessment": {
    "target_region_sufficiency": "string",
    "bottleneck_resources": ["string"]
  },
  "test_scenarios": [
    {
      "scenario_name": "string",
      "description": "string",
      "expected_behavior": "string",
      "potential_failure_mode": "string"
    }
  ],
  "critical_recommendations": ["string"]
}

**CONSTRAINTS:**
- Base all findings strictly on the provided [ARCHITECTURE_DESCRIPTION]. Do not invent components.
- If information is missing to assess a field, explicitly state 'Insufficient data provided' as the value.
- Prioritize findings that threaten the defined RTO and RPO.
- Include at least three distinct test scenarios for split-brain conditions and partial region degradation.

To adapt this template, replace each square-bracket placeholder with your specific details. For [ARCHITECTURE_DESCRIPTION], paste a comprehensive text description of your system, including services, data stores, and their regional deployment. For [RTO_IN_SECONDS] and [RPO_IN_SECONDS], use numeric values to drive a quantitative assessment. The [CONSISTENCY_MODEL] should be a term like 'strong', 'eventual', or 'read-after-write'. After running the prompt, validate the output JSON against the defined schema. For high-risk systems, the generated audit should be reviewed by a human architect before any remediation actions are planned. Do not use this prompt for simple single-region deployments, as the output will be largely irrelevant.

This prompt is designed to operate as a gated step within a broader architecture review pipeline, not as a standalone chatbot interaction. The implementation harness must enforce structured input collection, validate the model's output against a defined schema, and route findings to the appropriate review queue. Because the prompt audits critical infrastructure decisions—failover triggers, data consistency trade-offs, and split-brain scenarios—the harness must treat the model's output as an advisory draft that requires human approval before being accepted into any architecture decision record (ADR) or runbook.

Wire the prompt by first assembling the required inputs: the architecture document or diagram description, the target regions, the data store types and their replication modes, and the routing or DNS cutover design. These map to the [ARCHITECTURE_DOC], [REGIONS], [DATA_STORES], and [ROUTING_DESIGN] placeholders. The application layer should validate that each input field is non-empty and conforms to expected formats before calling the model. After the model returns its audit, validate the output against a strict JSON schema that requires fields such as failover_triggers, consistency_gaps, capacity_risks, split_brain_scenarios, and partial_degradation_tests. Reject and retry any response that fails schema validation, up to a maximum of two retries with a backoff of 2 seconds. Log every attempt, including the raw prompt, the model response, and the validation result, to an audit trail for later review.

For high-risk deployments, integrate a human review step after successful validation. Route the structured audit to a review queue where a cloud architect or SRE can approve, reject, or amend each finding. The harness should support a feedback loop: if a reviewer amends a finding, store the amendment alongside the model's original output to improve future prompt iterations. Do not automatically apply any remediation steps based on the model's output. The prompt identifies risks; it does not execute failover reconfiguration. Avoid wiring this prompt directly into CI/CD pipelines that deploy infrastructure changes without a manual approval gate.