Auditing and Owning Inherited Infrastructure

You're taking ownership of the AWS environment that runs 15 digital services for the Municipality of Rosario, Argentina — built and operated by a contractor who has now left.

What you're practicing: auditing an environment you did not build and have no spec for. Reconstructing what AWS actually contains when the inherited Terraform state is broken and terraform plan errors out before anything can run. Reconciling that state and bringing resources back under IaC with a classification you decide — import, replace, or decommission. Repairing inherited pipelines, rationalizing monitoring that fires alerts nobody can explain, writing the operational runbooks that were never written, doing forensic cost attribution on an already-running and inconsistently-tagged bill, and transferring complete ownership so a five-person team can run the environment without you.

What you're learning about the loop: every project so far let you direct AI to build, and you could ask the client why something was the way it was. Here there is no one to ask — the contractor is gone and the documentation is partial and unreliable. AI reads the inherited Terraform and reports the environment as the code describes it, not as AWS actually is. It does not flag that the state references deleted resources, it generates import HCL that does not match the live configuration, and it writes runbooks that miss the knowledge that was never written down anywhere. The work is directing AI to reconstruct reality from evidence and verifying every claim against the live environment, not against the code or the docs. When you're the inheritor, the documents are witnesses, not sources of truth.

Your Role

After this project you can take a complete environment someone else built and left, reconstruct what is actually running, bring it back under control without breaking a live system, capture undocumented operational knowledge, explain an unexplained bill to a non-technical stakeholder, and hand the whole thing to a team that can run it independently.

Martín is not an expert client and is honest that he is overwhelmed. He understands systems management but not AWS. He cannot tell you what is wrong because he does not know — the brief states symptoms, not causes. You run the discovery, decide what each finding means, and own the remediation. This is independent work. Almost nothing is provided, and what is provided is partly wrong on purpose.

What's New

Last time, at Harmoni Insurance in Malaysia, you designed a complete AI practice infrastructure for a 15-engineer team from a blank repository — project memory, scoped connectivity, skills, hooks, and a portable layer — and verified your own work by stakes at the summit.

This time the scale reverses. Every project up to now had you building. This one hands you a system already built, already running, already serving 1.2 million residents, with broken state, drifted monitoring, undocumented operations, and an unexplained bill. You inherit instead of build. You have done every one of these things before — which is exactly why you can now audit them.

The hard part: the inherited Terraform looks authoritative and it is partly fiction. Trusting it is the natural move and the wrong one almost everywhere. The skill is reconstructing the truth before you change anything, and the most valuable thing you deliver is not the fixed code — it is the documentation you wish you had been handed.

Tools

• Claude Code — directs the audit, the import methodology, the pipeline and monitoring fixes, the runbook drafting, and the cost analysis.
• Terraform — the inherited broken code and state: terraform plan, terraform state inspection, terraform import, terraform destroy.
• AWS CLI — resource inventory, the tag audit, cross-account ARN inspection, and the orphan scan at teardown.
• AWS Budgets — the budget guardrail, provisioned first, before you run any inherited code.
• Git / GitHub — the handover repo and its commit history are the spine of the ownership transfer.

These are all tools you have used before. Nothing here introduces a new one — the difficulty is the environment, not the toolkit.

Materials

In the project zip:

• Official brief (official-brief.md) — the engagement-opening artifact. Formal and official. It states symptoms, not causes; what is actually wrong surfaces only in discovery.
• Inherited repository (inherited-repo/) — a Terraform repo whose state references deleted resources and missing workspaces, so terraform plan errors out, plus a harness that stands up the pre-provisioned resources representing the 15 citizen services in your sandbox.
• Contractor handover docs (contractor-handover/) — partial, out of date, and not to be trusted as a source of truth.

There is no CLAUDE.md, no import methodology, no runbook, no cost-report template, and no answer key. You author your own. The budget-alarm-first habit, the orphan-scan teardown, and the repo-handoff habit carry forward unchanged.