sandeepsilumula/universal-infra-portfolio

1. This repository is a Terraform-only, multi-cloud infrastructure layout. It is organized around three independent deployment roots: aws/, azure/, and gcp/.

2. The main architectural choice is the “Multi-Root Pattern”: each cloud has its own Terraform root module and provider configuration, so AWS, Azure, and GCP are deployed as separate execution domains rather than one combined dependency graph.

3. The root directories are the orchestration layer. Each of aws/main.tf, azure/main.tf, and gcp/main.tf is where cloud-specific resources are composed, while providers.tf and variables.tf define provider setup and input contract for that cloud’s stack.

4. The modules/ directory contains reusable lower-level infrastructure logic, split by cloud: modules/aws_network, modules/azure_network, and modules/gcp_network. These are the resource-building units consumed by the corresponding root.

5. The primary functional subsystem in the repo is networking. The module names indicate each cloud root is focused on building a network baseline rather than a full application stack.

6. Cross-cloud coupling is intentionally avoided. There is no shared module that spans providers, which matches the README’s claim of “absolute provider isolation” and prevents Terraform from attempting to authenticate against multiple clouds in one graph.

7. The dependency flow is simple: operator or CI enters one cloud root, Terraform loads that root’s provider and variables, then that root calls only the matching cloud module to create resources. There is no architectural path from AWS resources to Azure or GCP resources.

8. The repository appears designed for independent lifecycle management per cloud. This means each cloud stack can be initialized, planned, and applied separately, with failures or credentials in one provider not affecting the others.

9. The GitHub Actions workflow in .github/workflows/deploy.yml likely automates deployment. Given the repo structure, it probably targets one root at a time rather than deploying all clouds from one Terraform invocation.

10. The README describes interactive terminal prompts for environment selection (dev, staging, prod). That suggests environment selection is an input to the root-level Terraform execution, not a separate directory structure in the repo.

11. The key architectural boundary is therefore: root directories = execution and provider boundary; modules = resource implementation boundary; cloud provider = isolation boundary.

12. From an architecture-diagram perspective, the clearest model is three parallel stacks:

AWS root → AWS network module,

Azure root → Azure network module,

GCP root → GCP network module,

with CI/CD as an external trigger feeding those roots.