Sota Cloud Infrastructure

SOTA Cloud Infrastructure

Purpose

This skill encodes the 2026 state of the art for cloud infrastructure architecture: organizational structure, identity, networking, compute selection, data placement, cost, and resilience. Every rule exists to prevent a real failure class — blast-radius spread, credential theft, public data exposure, egress bill shock, unmeetable RTOs, or a Kubernetes cluster nobody needed.

Boundaries with sibling skills — reference, do not duplicate:

• sota-devsecops owns CI/CD pipelines, IaC scanning, Terraform state security, GitOps.
• sota-sandboxing owns container/runtime hardening (seccomp, rootless, distroless).
• sota-observability owns monitoring, alerting, SLOs, tracing.
• sota-databases owns database engine selection, schema, and query design.
• sota-secrets-management owns secret storage and rotation mechanics.

This skill owns: what accounts/networks/identities/compute/storage exist, how they connect, what they cost, and how they survive failure.

BUILD mode

Use when designing or extending cloud infrastructure (architecture docs, Terraform modules, landing zones, network plans, DR plans).

1. Establish context before proposing anything: provider(s), org maturity (single account vs landing zone), environment count, data sensitivity, RTO/RPO targets, monthly spend ballpark, team size. A 3-person startup and a regulated enterprise get different answers from the same rules.
2. Read the matching rules files from the index below BEFORE writing config. Compute selection (rules/04) comes before networking details; account structure (rules/01) comes before everything.
3. Default to the boring, managed, restrictive option: managed services over self-hosted, private over public, multi-AZ over single-AZ, deny-by-default IAM and network policy. Every loosening gets a written justification in a comment.
4. Every resource you design must carry: owner tag, environment tag, cost-allocation tag, and a deletion/lifecycle story. Untagged infrastructure is unaccountable infrastructure.
5. State the cost and the failure mode of what you propose. "Three NAT gateways at per-hour + per-GB rates" and "this is single-region; region loss means restore from backup" belong in the design, not in the postmortem.
6. Produce infrastructure as code (Terraform/OpenTofu/Pulumi fragments), never console-click instructions, except for one-time org bootstrap steps which must be documented as such.

AUDIT mode

Use when reviewing existing cloud environments, Terraform repos, or architecture docs.

Process: inventory what exists (accounts/projects, networks, identities, compute, storage, DNS); walk the Audit checklist at the end of each relevant rules file; report findings in the format below. Confirm exploitability/reality before reporting — read the actual policy JSON or Terraform, don't infer from resource names.

Severity conventions

Severity is judged by reachability (anonymous > authenticated external > tenant > insider) × impact (data/identity compromise > availability > cost). Cost-only findings cap at High (sustained material burn) and are usually Medium.

Finding format

[SEVERITY] <short title>
Where: <account/project> / <resource or Terraform address> / <file:line if IaC>
Evidence: <the exact policy statement / CIDR / config proving it>
Impact: <who can do what, or what fails and how>
Fix: <specific change — policy JSON / Terraform diff / architecture move>

Group repeated instances of the same finding (e.g., 40 buckets without lifecycle rules) into one finding with a count and a listing.

Rules index

Cross-cutting tasks read multiple files: a "review our AWS account" audit touches all seven; "should we use Kubernetes" is rules/04 + rules/06.

Top 10 non-negotiables

1. Blast-radius isolation by account/project, not by tag. Prod, non-prod, security tooling, and logging live in separate accounts/projects under an org with guardrails (SCPs / org policy constraints / Azure Policy). A tag is not a security boundary; an account is.
2. No long-lived credentials for humans. Humans authenticate through SSO/identity federation (IAM Identity Center, Google Cloud Identity, Entra ID) with MFA and assume short-lived roles. Zero IAM users with passwords or access keys for people.
3. Workload identity everywhere. Workloads get roles/service accounts via the platform (instance profiles, IRSA/EKS Pod Identity, GKE Workload Identity, Azure managed identities) or OIDC federation (CI). A static cloud key in an env var or secret store is a finding, not a pattern.
4. Public access blocked at the org edge. Account-/org-level public-access blocks on object storage, org policy forbidding public IPs and public buckets by default; exceptions are explicit, listed, and reviewed.
5. Three-tier network, deny-by-default. Public subnets hold only entry points (LBs, NAT); apps in private subnets; data in isolated subnets with no internet path. Managed services reached via private endpoints, not the public internet. No 0.0.0.0/0 ingress except 80/443 on edge load balancers.
6. Simplest compute that meets requirements. Serverless/managed containers before Kubernetes; Kubernetes only with a written justification (scale, ecosystem need, team to run it). Every K8s workload ships with resource requests/limits, a PDB, and topology spread.
7. Encryption with intentional keys. Everything encrypted at rest (table stakes); customer-managed keys (CMK) for sensitive data with key policy ≠ data policy, so a single principal can't both read and exfiltrate.
8. Backups that survive account compromise. Critical data backed up cross-account (and cross-region per DR tier) with immutability/locking. A backup the producing account's admin can delete is not a backup against ransomware.
9. Cost is an architecture review gate. Allocation tags enforced, per-team visibility, anomaly alerts on; infra PRs state expected cost delta. Egress, NAT processing, and idle resources are checked in design, not discovered on the bill.
10. DR is declared and tested. Every system has an assigned RTO/RPO tier and a matching architecture (backup-restore → pilot light → warm standby → active-active). Multi-AZ is the default; multi-region is a justified exception. Untested DR plans are assumed broken — game days at least annually for tier-1.

Operating notes

• Principles first, provider examples second. When the user's provider is known, give that provider's mechanism; otherwise name all three (AWS / GCP / Azure).
• Verify provider limits, instance types, and prices against current docs before committing them to designs — they change faster than any skill text.
• When this skill and a compliance framework conflict (CIS, SOC 2 mapping), state both and let the operator choose; do not silently relax.