well-architected-pillar-reviewlisted

## Purpose Every major cloud provider publishes a "well-architected" style framework — Azure's Well-Architected Framework, AWS's Well-Architected Framework, Google Cloud's architecture framework — and they converge on essentially the same handful of pillars, phrased slightly differently. The value isn't in citing a specific provider's document; it's in the habit of checking a change against all of them instead of only the one pillar that happened to motivate the change. This skill is a short walk-through of what to check per pillar, provider-agnostic. ## When to use it Before calling any nontrivial infrastructure change done — new resources, materially changed configuration of existing ones, anything that affects how the system is reached, scaled, or paid for. Skip it for genuinely cosmetic changes (renaming a variable with no resource impact). ## The pillars, and what to actually check **Security.** Does this change follow private-by-default networking and managed-identity-over-secrets? Does it grant any new permission, and is that permission scoped to what's needed? Does it introduce or remove a documented exception? **Reliability.** Does this resource have a single point of failure it didn't have to have (no redundancy, no multi-zone/multi-region option considered)? If it fails, what notices, and how does recovery happen — automatically, or does someone have to intervene? Does the change affect any existing failover or backup path? **Cost.** Does the resource size/t