← Headcount: TechnologyCONTENT HISTORY
WHAT CHANGED
Update to Headcount: Technology
Snapshot Oct 24, 2026 · 13:55 UTC · version 1.0.1
Collection source: downloaded plugin package.
First saved snapshot
No earlier snapshot is available to establish a change.
Save Headcount: Technology and check future changes in Following.
Up to 10 plugins free · no card required.
Compare saved observations
Download comparison JSONFull technical diff · 0 changed fields
Full snapshot data
{
"description": "Designs and runs cloud infrastructure — environments, infrastructure as code, networking and isolation, scaling, and cost. Use this to design a cloud environment, control infrastructure spend, set up environment separation, plan for scale or region failure, or review infrastructure someone configured by hand.",
"included_files": [
{
"relative_path": "references/sources.md",
"size_in_bytes": 1796
}
],
"name": "cloud-infrastructure",
"skill_md_contents": "---\nname: cloud-infrastructure\ndescription: Designs and runs cloud infrastructure — environments, infrastructure as code, networking and isolation, scaling, and cost. Use this to design a cloud environment, control infrastructure spend, set up environment separation, plan for scale or region failure, or review infrastructure someone configured by hand.\n---\n\n# Cloud infrastructure\n\nCloud replaces capital cost with an operating cost that scales with carelessness. The discipline is\nmostly about making the environment reproducible and the spend visible.\n\n## Everything reproducible from code\n\nInfrastructure created by hand cannot be reviewed, reproduced, or recovered. Define it as code,\nreview it like code, and apply it through a pipeline rather than from a laptop.\n\nThe test: could you rebuild the environment from an empty account, and do you know that because you\nhave done it? Untested reproducibility is a belief.\n\nConsole access for humans should be read-only in production by default. Write access exists for\nemergencies, is time-bound, and is logged — see `security:access-and-identity` for the policy this\nimplements.\n\n## Environments that mean something\n\nSeparate environments by blast radius, not by name. Separate accounts or subscriptions give a hard\nboundary; separate namespaces in one account give a soft one that a misconfigured permission\ncrosses.\n\nProduction data does not belong in lower environments. Where realistic data is needed, mask or\nsynthesize it — a copied production database is a breach waiting for a misconfigured bucket, and it\nis one of the most common ways personal data escapes.\n\n## Networking and isolation\n\nDefault deny, then open what is needed. Public exposure should be a deliberate, reviewable act rather\nthan the residue of a default.\n\nKeep the trust boundary explicit and few: what is reachable from the internet, what is reachable\nbetween services, what reaches data stores. Most cloud incidents are not exotic — they are a storage\nbucket, a database, or a management interface that was reachable and should not have been.\n\n## Scaling and failure\n\nScale horizontally where you can and know your actual limits — the database connection ceiling, the\nthird-party rate limit, the single-threaded component nobody remembers. Autoscaling in front of a\nhard downstream limit converts a slow system into an outage.\n\nDesign for the failure of a single instance and a single zone as routine. Region failure is a\nbusiness continuity decision with a real price attached, made with\n`operations:business-continuity-and-resilience` rather than assumed by engineering.\n\n## Cost\n\nCost is an architectural property. Attribute spend by team and workload from the start; without\ntagging, cost becomes an unattributable aggregate that only ever gets addressed in a panic.\n\nThe usual large wins are unglamorous: idle non-production resources, over-provisioned instances,\nstorage nobody deleted, and cross-zone data transfer nobody accounted for.\n\n## Sources\n\n`references/sources.md` in this skill lists the outside authorities that settle the questions\nhere — what each one is authoritative for, and what you may do with it. Check them before\nanswering on anything they cover, and cite what you used. Most are free to read and not free\nto reproduce; the use note on each is binding.\n\n## Tooling\n\nPlatforms: AWS, Google Cloud, Microsoft Azure, and similar; managed application platforms —\nFly.io, Render, Vercel, Railway — remove most of this work and are the right answer more often than\nengineering pride admits.\n\nOrchestration where you need it: Kubernetes with a managed control plane, or a container service\nlike ECS. Kubernetes is a platform team's worth of work; adopt it when you have the team.\n\nInfrastructure as code and secrets: Terraform, OpenTofu, Pulumi, and similar, with secrets in a\nmanaged store rather than in the state file. `it-operations:cloud-administration` covers the\ncorporate cloud estate, which is a different problem with overlapping tools.\n\n## Never\n\n- Make a production change by hand that is not reflected in code.\n- Put production data in a lower environment unmasked.\n- Autoscale a tier in front of a hard downstream limit.\n- Run without cost attribution until the bill forces it.\n"
}SHA-256 of public snapshot: b38a5617ccfe384b2d6b32799612fd901bcbdade29b18874231c295b4f81a1cd