# Multi-Region Landing Zones Guide

**Comprehensive guide for multi-region landing zones in Phoenix for sovereign governments**

This document provides detailed guidance on implementing multi-region landing zones for international and multi-national sovereign governments using Phoenix cloud services.

---

## Executive Summary

Phoenix landing zones enable **sovereign cloud deployments per region/nation** for international and multi-national sovereign governments. Each landing zone provides complete regional autonomy while enabling coordinated governance across regions.

**Key Capabilities:**
- **Sovereign Cloud Per Region**: Complete regional control and data residency
- **Multi-National Support**: Support for international governments with multiple nations
- **Decentralized Governance**: Regional autonomy with coordinated governance
- **Cross-Border Sovereignty**: Enables sovereignty across distributed regions
- **Air-Gapped Support**: Support for air-gapped deployments per region

---

## I. Landing Zone Architecture

### Reference Architecture

A Phoenix landing zone is a **sovereign cloud deployment per region/nation** that provides:

1. **Complete Regional Control**: All infrastructure and data under regional control
2. **Data Residency**: Hard enforcement of data residency requirements
3. **Compliance**: Regional compliance profiles and audit capabilities
4. **Network Isolation**: Network boundaries with controlled cross-region connectivity
5. **Identity Federation**: Federated identity with regional control

### Landing Zone Components

```
Landing Zone
├── Control Plane (Regional)
│   ├── Commercial Plane
│   ├── Tenancy Plane
│   ├── Subscription Plane
│   ├── Environment Plane
│   └── Content & DevOps Plane
├── Infrastructure
│   ├── Compute (Proxmox/Kubernetes)
│   ├── Storage
│   ├── Networking
│   └── Security
├── Identity (Keycloak Realm)
├── Governance
│   ├── Policies
│   ├── Compliance
│   └── Audit
└── Connectivity
    ├── Cross-Region (if allowed)
    └── External (if allowed)
```

### Landing Zone Types

#### Type 1: Standard Sovereign Landing Zone

**Characteristics:**
- Complete regional control
- Data residency enforcement
- Cross-region connectivity (controlled)
- Federated identity
- Coordinated governance

**Use Cases:**
- Standard sovereign government deployments
- Multi-national government coordination
- Regional data residency requirements

#### Type 2: Air-Gapped Landing Zone

**Characteristics:**
- Complete network isolation
- No external connectivity
- No cross-region connectivity
- Local identity only
- Local governance only

**Use Cases:**
- Classified government systems
- Critical infrastructure
- National security systems

#### Type 3: Hybrid Landing Zone

**Characteristics:**
- Regional control with selective external connectivity
- Data residency with controlled data sharing
- Federated identity with regional control
- Coordinated governance with regional autonomy

**Use Cases:**
- Government with public-facing services
- Multi-national coordination with sovereignty
- Regulated industries with external requirements

---

## II. Multi-Region Deployment Patterns

### Pattern 1: Single Region Sovereign

**Architecture:**
- One landing zone per region
- Complete regional autonomy
- No cross-region connectivity required
- Independent governance

**Use Case**: Single-nation sovereign government

```
Region A
└── Landing Zone A
    ├── Tenant A
    ├── Subscription A
    └── Environment A (PROD)
```

**Characteristics:**
- Complete regional control
- Data residency in Region A only
- Independent identity and governance
- No cross-region dependencies

### Pattern 2: Multi-Region Sovereign

**Architecture:**
- Multiple landing zones (one per region)
- Cross-region connectivity (controlled)
- Federated identity
- Coordinated governance

**Use Case**: Multi-national sovereign government

```
Region A                    Region B                    Region C
└── Landing Zone A         └── Landing Zone B         └── Landing Zone C
    ├── Tenant A               ├── Tenant B               ├── Tenant C
    ├── Subscription A         ├── Subscription B         ├── Subscription C
    └── Environment A          └── Environment B          └── Environment C
        (PROD)                      (PROD)                      (PROD)
        
Cross-Region Connectivity (Controlled)
Federated Identity
Coordinated Governance
```

**Characteristics:**
- Regional autonomy with coordination
- Cross-region connectivity for coordination
- Federated identity across regions
- Coordinated governance policies

### Pattern 3: Air-Gapped Per Region

**Architecture:**
- Multiple landing zones (one per region)
- No cross-region connectivity
- Independent identity per region
- Independent governance per region

**Use Case**: Multi-national government with classified systems

```
Region A                    Region B                    Region C
└── Landing Zone A         └── Landing Zone B         └── Landing Zone C
    (Air-Gapped)              (Air-Gapped)              (Air-Gapped)
    ├── Tenant A               ├── Tenant B               ├── Tenant C
    ├── Subscription A         ├── Subscription B         ├── Subscription C
    └── Environment A          └── Environment B          └── Environment C
        (AIR-GAPPED)               (AIR-GAPPED)               (AIR-GAPPED)
        
No Cross-Region Connectivity
Independent Identity
Independent Governance
```

**Characteristics:**
- Complete isolation per region
- No cross-region connectivity
- Independent identity and governance
- Air-gapped deployment per region

### Pattern 4: Hub and Spoke

**Architecture:**
- Central landing zone (hub) for coordination
- Regional landing zones (spokes) for sovereignty
- Hub-to-spoke connectivity
- Limited spoke-to-spoke connectivity

**Use Case**: Multi-national government with central coordination

```
Hub Region
└── Landing Zone Hub (Coordination)
    ├── Governance API
    ├── Event Bus
    └── Audit Log

Spoke Region A          Spoke Region B          Spoke Region C
└── Landing Zone A     └── Landing Zone B     └── Landing Zone C
    ├── Tenant A           ├── Tenant B           ├── Tenant C
    └── Subscription A    └── Subscription B    └── Subscription C
    
Hub-to-Spoke Connectivity
Limited Spoke-to-Spoke Connectivity
Federated Identity via Hub
Coordinated Governance via Hub
```

**Characteristics:**
- Central coordination point
- Regional autonomy in spokes
- Hub-to-spoke connectivity
- Coordinated governance via hub

---

## III. Sovereign Cloud Per Region/Nation

### Regional Sovereignty

**Complete Regional Control:**
- All infrastructure under regional control
- All data under regional control
- Regional identity and governance
- Regional compliance and audit

**Data Residency:**
- Hard enforcement: Data cannot leave region
- Soft enforcement: Data preferred in region, warnings if outside
- Advisory: Recommendations for data placement

**Compliance:**
- Regional compliance profiles
- Regional audit capabilities
- Regional regulatory requirements

### Implementation

#### Step 1: Create Landing Zone

```graphql
mutation {
  createLandingZone(input: {
    name: "landing-zone-region-a"
    region: "region-a"
    sovereignCloud: true
    dataResidency: {
      requirement: REQUIRED
      enforcement: HARD
    }
    complianceProfile: {
      standards: [ISO_27001, SOC_2, FEDRAMP]
    }
  }) {
    id
    name
    region
    sovereignCloud
  }
}
```

#### Step 2: Configure Regional Control Plane

```graphql
mutation {
  configureControlPlane(landingZoneId: "landing-zone-id", input: {
    commercialPlane: {
      enabled: true
      regionalAutonomy: true
    }
    tenancyPlane: {
      enabled: true
      regionalIdentity: true
    }
    subscriptionPlane: {
      enabled: true
      regionalQuotas: true
    }
    environmentPlane: {
      enabled: true
      regionalIsolation: true
    }
    contentPlane: {
      enabled: true
      regionalContent: true
    }
  }) {
    id
    status
  }
}
```

#### Step 3: Configure Data Residency

```graphql
mutation {
  configureDataResidency(landingZoneId: "landing-zone-id", input: {
    requirement: REQUIRED
    enforcement: HARD
    allowedRegions: ["region-a"]
    prohibitedRegions: ["region-b", "region-c"]
  }) {
    id
    dataResidency
  }
}
```

---

## IV. Cross-Region Connectivity

### Connectivity Patterns

#### Pattern 1: Full Connectivity

**Characteristics:**
- All regions can communicate
- Full mesh connectivity
- Coordinated governance
- Federated identity

**Use Case**: Multi-national government with full coordination

#### Pattern 2: Hub and Spoke Connectivity

**Characteristics:**
- Hub connects to all spokes
- Spokes connect only to hub
- Limited spoke-to-spoke connectivity
- Coordinated governance via hub

**Use Case**: Multi-national government with central coordination

#### Pattern 3: Selective Connectivity

**Characteristics:**
- Selected regions can communicate
- Policy-driven connectivity
- Regional autonomy with selective coordination
- Federated identity for connected regions

**Use Case**: Multi-national government with selective coordination

#### Pattern 4: No Connectivity (Air-Gapped)

**Characteristics:**
- No cross-region connectivity
- Complete isolation per region
- Independent identity and governance
- Air-gapped deployment

**Use Case**: Classified systems, critical infrastructure

### Implementation

#### Configure Cross-Region Connectivity

```graphql
mutation {
  configureCrossRegionConnectivity(input: {
    fromLandingZone: "landing-zone-a"
    toLandingZone: "landing-zone-b"
    connectivityType: ENCRYPTED_TUNNEL
    allowedTraffic: {
      governance: true
      identity: true
      audit: false
      data: false
    }
    encryption: {
      algorithm: AES_256
      keyManagement: REGIONAL
    }
  }) {
    id
    status
  }
}
```

---

## V. Regional Data Residency

### Data Residency Requirements

#### Hard Enforcement

**Characteristics:**
- Data cannot leave region
- Enforcement at storage layer
- Enforcement at network layer
- Enforcement at application layer

**Implementation:**
- Storage policies prevent data replication outside region
- Network policies prevent data transfer outside region
- Application policies prevent data access from outside region

#### Soft Enforcement

**Characteristics:**
- Data preferred in region
- Warnings if data outside region
- Recommendations for data placement
- Monitoring and alerting

**Implementation:**
- Monitoring detects data outside region
- Alerts sent to administrators
- Recommendations for data placement
- Optional enforcement policies

#### Advisory

**Characteristics:**
- Recommendations for data placement
- No enforcement
- Monitoring and reporting
- Best practices guidance

**Implementation:**
- Monitoring and reporting
- Best practices documentation
- Recommendations for data placement
- No enforcement policies

### Implementation

#### Configure Data Residency

```graphql
mutation {
  configureDataResidency(landingZoneId: "landing-zone-id", input: {
    requirement: REQUIRED
    enforcement: HARD
    allowedRegions: ["region-a"]
    prohibitedRegions: ["region-b", "region-c"]
    monitoring: {
      enabled: true
      alerts: true
      reporting: true
    }
  }) {
    id
    dataResidency
  }
}
```

---

## VI. Multi-National Coordination

### Coordination Patterns

#### Pattern 1: Federated Governance

**Characteristics:**
- Governance policies federated across regions
- Regional autonomy with coordination
- Cross-region policy enforcement
- Coordinated audit

**Use Case**: Multi-national government with coordinated governance

#### Pattern 2: Independent Governance

**Characteristics:**
- Independent governance per region
- No cross-region policy enforcement
- Regional audit only
- Complete regional autonomy

**Use Case**: Multi-national government with regional autonomy

#### Pattern 3: Hybrid Governance

**Characteristics:**
- Some policies federated, some independent
- Selective cross-region policy enforcement
- Coordinated audit for federated policies
- Regional audit for independent policies

**Use Case**: Multi-national government with selective coordination

### Implementation

#### Configure Federated Governance

```graphql
mutation {
  configureFederatedGovernance(input: {
    landingZones: ["landing-zone-a", "landing-zone-b"]
    policies: {
      security: FEDERATED
      compliance: FEDERATED
      billing: INDEPENDENT
      identity: FEDERATED
    }
    coordination: {
      eventBus: true
      governanceAPI: true
      auditLog: true
    }
  }) {
    id
    status
  }
}
```

---

## VII. Federated Identity

### Identity Federation Patterns

#### Pattern 1: Full Federation

**Characteristics:**
- Identity federation across all regions
- SSO across regions
- Centralized identity management
- Regional identity control

**Use Case**: Multi-national government with coordinated identity

#### Pattern 2: Selective Federation

**Characteristics:**
- Identity federation for selected regions
- SSO for federated regions
- Independent identity for non-federated regions
- Regional identity control

**Use Case**: Multi-national government with selective identity coordination

#### Pattern 3: Independent Identity

**Characteristics:**
- Independent identity per region
- No cross-region SSO
- Regional identity management
- Complete regional identity control

**Use Case**: Multi-national government with regional identity autonomy

### Implementation

#### Configure Federated Identity

```graphql
mutation {
  configureFederatedIdentity(input: {
    landingZones: ["landing-zone-a", "landing-zone-b"]
    federationType: FULL
    ssoEnabled: true
    identityProvider: KEYCLOAK
    regionalControl: true
  }) {
    id
    status
  }
}
```

---

## VIII. Network Connectivity

### Network Patterns

#### Pattern 1: Encrypted Tunnels

**Characteristics:**
- Encrypted tunnels between regions
- VPN or dedicated connections
- End-to-end encryption
- Regional key management

**Use Case**: Secure cross-region connectivity

#### Pattern 2: Private Connections

**Characteristics:**
- Private network connections
- Dedicated circuits
- No internet transit
- Regional network control

**Use Case**: High-security cross-region connectivity

#### Pattern 3: Internet-Based

**Characteristics:**
- Internet-based connectivity
- Encrypted connections
- Public internet transit
- Regional network control

**Use Case**: Standard cross-region connectivity

### Implementation

#### Configure Network Connectivity

```graphql
mutation {
  configureNetworkConnectivity(input: {
    fromLandingZone: "landing-zone-a"
    toLandingZone: "landing-zone-b"
    connectionType: ENCRYPTED_TUNNEL
    encryption: {
      algorithm: AES_256
      keyManagement: REGIONAL
    }
    routing: {
      allowedNetworks: ["10.1.0.0/16", "10.2.0.0/16"]
      prohibitedNetworks: []
    }
  }) {
    id
    status
  }
}
```

---

## IX. Regional Compliance

### Compliance Per Landing Zone

**Regional Compliance Profiles:**
- ISO 27001, ISO 27017, ISO 27018
- SOC 2, SOC 3
- HIPAA, PCI-DSS
- GDPR, CCPA
- FedRAMP, ITAR
- Government-specific standards

**Regional Audit:**
- Regional audit logging
- Regional audit reporting
- Regional compliance monitoring
- Regional compliance validation

### Implementation

#### Configure Regional Compliance

```graphql
mutation {
  configureCompliance(landingZoneId: "landing-zone-id", input: {
    standards: [ISO_27001, SOC_2, FEDRAMP]
    certifications: ["cert-1", "cert-2"]
    auditRequirements: {
      logging: true
      reporting: true
      monitoring: true
      validation: true
    }
    regionalAudit: {
      enabled: true
      retention: "7years"
      reporting: true
    }
  }) {
    id
    complianceProfile
  }
}
```

---

## X. Use Cases

### Use Case 1: Multi-National Defense Contractor

**Scenario**: Defense contractor with classified and unclassified workloads across multiple nations.

**Landing Zone Structure:**
- Landing Zone per nation
- Classified workloads in AIR-GAPPED landing zones
- Unclassified workloads in REGULATED landing zones
- Coordinated governance for unclassified workloads
- Independent governance for classified workloads

**Implementation:**
```
Nation A                    Nation B                    Nation C
└── Landing Zone A         └── Landing Zone B         └── Landing Zone C
    ├── Classified             ├── Classified             ├── Classified
    │   (AIR-GAPPED)           │   (AIR-GAPPED)           │   (AIR-GAPPED)
    └── Unclassified           └── Unclassified           └── Unclassified
        (REGULATED)                (REGULATED)                (REGULATED)
        
Coordinated Governance (Unclassified Only)
Independent Governance (Classified)
```

### Use Case 2: International Healthcare Agency

**Scenario**: Healthcare agency operating across multiple countries with HIPAA requirements.

**Landing Zone Structure:**
- Landing Zone per country
- HIPAA-compliant landing zones
- Regional data residency (hard enforcement)
- Federated identity for coordination
- Coordinated governance for compliance

**Implementation:**
```
Country A                   Country B                   Country C
└── Landing Zone A         └── Landing Zone B         └── Landing Zone C
    ├── Tenant A               ├── Tenant B               ├── Tenant C
    ├── Subscription A        ├── Subscription B          ├── Subscription C
    └── Environment A          └── Environment B          └── Environment C
        (REGULATED - HIPAA)        (REGULATED - HIPAA)        (REGULATED - HIPAA)
        
Federated Identity
Coordinated Governance
Regional Data Residency (Hard Enforcement)
```

### Use Case 3: Cross-Border Financial Regulator

**Scenario**: Financial regulator coordinating across multiple nations.

**Landing Zone Structure:**
- Landing Zone per nation
- REGULATED landing zones
- Cross-region connectivity for coordination
- Federated identity
- Coordinated governance

**Implementation:**
```
Nation A                    Nation B                    Nation C
└── Landing Zone A         └── Landing Zone B         └── Landing Zone C
    ├── Tenant A               ├── Tenant B               ├── Tenant C
    ├── Subscription A        ├── Subscription B          ├── Subscription C
    └── Environment A          └── Environment B          └── Environment C
        (REGULATED)                (REGULATED)                (REGULATED)
        
Cross-Region Connectivity (Controlled)
Federated Identity
Coordinated Governance
```

### Use Case 4: Multi-Region Public Sector Agency

**Scenario**: Public sector agency with operations across multiple regions.

**Landing Zone Structure:**
- Landing Zone per region
- Standard landing zones
- Cross-region connectivity
- Federated identity
- Coordinated governance

**Implementation:**
```
Region A                    Region B                    Region C
└── Landing Zone A         └── Landing Zone B         └── Landing Zone C
    ├── Tenant A               ├── Tenant B               ├── Tenant C
    ├── Subscription A        ├── Subscription B          ├── Subscription C
    └── Environment A          └── Environment B          └── Environment C
        (PROD)                      (PROD)                      (PROD)
        
Cross-Region Connectivity
Federated Identity
Coordinated Governance
```

---

## XI. Landing Zone Templates

### Template 1: Standard Sovereign Landing Zone

**Configuration:**
```yaml
landingZone:
  name: "landing-zone-standard"
  region: "region-a"
  type: "SOVEREIGN"
  sovereignCloud: true
  dataResidency:
    requirement: REQUIRED
    enforcement: HARD
  compliance:
    standards: [ISO_27001, SOC_2]
  connectivity:
    crossRegion: true
    external: false
  identity:
    type: KEYCLOAK
    federation: true
  governance:
    type: COORDINATED
    autonomy: REGIONAL
```

### Template 2: Air-Gapped Landing Zone

**Configuration:**
```yaml
landingZone:
  name: "landing-zone-air-gapped"
  region: "region-a"
  type: "AIR_GAPPED"
  sovereignCloud: true
  dataResidency:
    requirement: REQUIRED
    enforcement: HARD
  compliance:
    standards: [ISO_27001, FEDRAMP, ITAR]
  connectivity:
    crossRegion: false
    external: false
  identity:
    type: KEYCLOAK
    federation: false
  governance:
    type: INDEPENDENT
    autonomy: COMPLETE
```

### Template 3: Hybrid Landing Zone

**Configuration:**
```yaml
landingZone:
  name: "landing-zone-hybrid"
  region: "region-a"
  type: "HYBRID"
  sovereignCloud: true
  dataResidency:
    requirement: PREFERRED
    enforcement: SOFT
  compliance:
    standards: [ISO_27001, SOC_2, HIPAA]
  connectivity:
    crossRegion: true
    external: true
  identity:
    type: KEYCLOAK
    federation: true
  governance:
    type: HYBRID
    autonomy: REGIONAL
```

---

## XII. Deployment Automation

### Automated Landing Zone Creation

**Terraform Example:**
```hcl
resource "phoenix_landing_zone" "region_a" {
  name           = "landing-zone-region-a"
  region         = "region-a"
  sovereign_cloud = true
  
  data_residency {
    requirement = "REQUIRED"
    enforcement = "HARD"
    allowed_regions = ["region-a"]
  }
  
  compliance {
    standards = ["ISO_27001", "SOC_2", "FEDRAMP"]
  }
  
  connectivity {
    cross_region = true
    external     = false
  }
  
  identity {
    type      = "KEYCLOAK"
    federation = true
  }
  
  governance {
    type    = "COORDINATED"
    autonomy = "REGIONAL"
  }
}
```

### CI/CD Pipeline for Landing Zone Deployment

```yaml
stages:
  - validate
  - plan
  - deploy
  - verify

validate:
  - terraform validate
  - terraform fmt -check

plan:
  - terraform plan -out=tfplan

deploy:
  - terraform apply tfplan
  - configure_control_plane
  - configure_data_residency
  - configure_compliance

verify:
  - verify_landing_zone
  - verify_connectivity
  - verify_compliance
```

---

## XIII. Integration with Existing Infrastructure

### Proxmox Integration

**Landing Zone → Proxmox Mapping:**
- Landing Zone → Proxmox Site
- Tenant → Proxmox Access Control
- Subscription → Proxmox Resource Pool
- Environment → Proxmox Resource Pool

**Implementation:**
```graphql
mutation {
  configureProxmoxIntegration(landingZoneId: "landing-zone-id", input: {
    proxmoxSite: "proxmox-site-region-a"
    resourcePools: {
      subscription: "subscription-id"
      environment: "environment-id"
    }
    accessControl: {
      tenant: "tenant-id"
      permissions: ["read", "write"]
    }
  }) {
    id
    status
  }
}
```

### Kubernetes Integration

**Landing Zone → Kubernetes Mapping:**
- Landing Zone → Kubernetes Cluster
- Tenant → Kubernetes RBAC Namespace
- Subscription → Kubernetes ResourceQuota
- Environment → Kubernetes Namespace

**Implementation:**
```graphql
mutation {
  configureKubernetesIntegration(landingZoneId: "landing-zone-id", input: {
    kubernetesCluster: "k8s-cluster-region-a"
    namespaces: {
      tenant: "tenant-id"
      environment: "environment-id"
    }
    resourceQuotas: {
      subscription: "subscription-id"
      quotas: {
        cpu: "100"
        memory: "512Gi"
      }
    }
  }) {
    id
    status
  }
}
```

### Cloudflare Integration

**Landing Zone → Cloudflare Mapping:**
- Landing Zone → Cloudflare Tunnel Endpoint
- Tenant → Cloudflare Access Policy
- Environment → Cloudflare Tunnel Configuration

**Implementation:**
```graphql
mutation {
  configureCloudflareIntegration(landingZoneId: "landing-zone-id", input: {
    tunnelEndpoint: "tunnel-region-a"
    accessPolicies: {
      tenant: "tenant-id"
      policies: ["policy-1", "policy-2"]
    }
    tunnelConfig: {
      environment: "environment-id"
      routes: ["route-1", "route-2"]
    }
  }) {
    id
    status
  }
}
```

---

## XIV. Best Practices

### Landing Zone Design

1. **Start with Standard Pattern**: Begin with standard sovereign landing zone, expand as needed
2. **Plan for Growth**: Design landing zones to scale with requirements
3. **Regional Autonomy**: Ensure regional autonomy while enabling coordination
4. **Data Residency**: Enforce data residency from the start
5. **Compliance First**: Design compliance into landing zones from the beginning

### Multi-Region Coordination

1. **Federated Governance**: Use federated governance for coordination
2. **Selective Connectivity**: Use selective connectivity based on requirements
3. **Regional Autonomy**: Maintain regional autonomy while coordinating
4. **Audit Coordination**: Coordinate audit across regions where needed

### Security

1. **Network Isolation**: Enforce network isolation per landing zone
2. **Data Isolation**: Enforce data isolation per landing zone
3. **Identity Federation**: Use federated identity with regional control
4. **Audit Logging**: Enable comprehensive audit logging

### Compliance

1. **Compliance Profiles**: Define compliance profiles per landing zone
2. **Audit Capabilities**: Enable audit capabilities from the start
3. **Regional Compliance**: Support regional compliance requirements
4. **Compliance Monitoring**: Monitor compliance continuously

---

## XV. Troubleshooting

### Common Issues

#### Issue 1: Cross-Region Connectivity Fails

**Symptoms**: Cannot connect between landing zones

**Diagnosis**:
- Check network connectivity configuration
- Verify firewall rules
- Check encryption configuration

**Resolution**:
- Verify network connectivity settings
- Update firewall rules
- Reconfigure encryption if needed

#### Issue 2: Data Residency Violation

**Symptoms**: Data detected outside allowed region

**Diagnosis**:
- Check data residency configuration
- Verify storage policies
- Check network policies

**Resolution**:
- Update data residency configuration
- Enforce storage policies
- Enforce network policies

#### Issue 3: Identity Federation Fails

**Symptoms**: Cannot authenticate across regions

**Diagnosis**:
- Check identity federation configuration
- Verify Keycloak realm configuration
- Check network connectivity

**Resolution**:
- Reconfigure identity federation
- Verify Keycloak realm settings
- Ensure network connectivity

---

## References

### Phoenix Operating Model Documentation

- **[Operating Model](./OPERATING_MODEL.md)** - Core operating model documentation
- **[Architecture Diagrams](./OPERATING_MODEL_DIAGRAMS.md)** - Visual diagrams of the operating model
- **[Cloud Provider Mapping](./CLOUD_PROVIDER_MAPPING.md)** - Azure/AWS mapping and competitive analysis
- **[MVP Control Plane](./MVP_CONTROL_PLANE.md)** - Minimum viable product specification
- **[Migration Guide](./MIGRATION_GUIDE.md)** - Migration from existing systems and cloud providers
- **[Product Specification](./PRODUCT_SPEC.md)** - Client-facing product specification

---

**Last Updated**: 2025-01-09  
**Version**: 1.0  
**Status**: Complete Multi-Region Landing Zones Guide