You're consolidating cloud infrastructure for Ahmed Al-Rashidi, Director of Cloud Infrastructure at the Abu Dhabi Digital Authority, where twelve government entities have built independently across three different tooling regimes for four years.
The discipline skills: a tooling map that names what is managed by Terraform, what by CloudFormation, and what by console-only across twelve entities; a remote state backend with S3 and DynamoDB locking that you provision and verify end-to-end; sovereign-data policy-as-code written in Rego from the UAE regulatory text; and terraform state mv planned, dry-run, and executed against a unified module structure where the post-move plan must show no changes.
The AI-direction lesson is that the plan changes character. So far, a clean plan was the goal after writing new infrastructure -- here, a clean plan is the verification that a refactor preserved reality, and any diff is the alarm. AI generates terraform state mv commands fluently and confidently, but does not check that the source address exists or that the destination matches the module structure. AI writes Rego that compiles but matches the wrong field. The verification system you carry in from last time is what you turn against AI's most confident output, on the operation where being wrong destroys production.
Your Role
Ahmed is technically deep. He has done state surgery at small scale, he understands OPA, he has named the danger explicitly in his brief. What he has not done is this work at the scale of twelve entities with sovereign-data implications and three tooling regimes. You are the cloud engineer he has brought in to design and execute the consolidation. The register is formal-brief throughout: numbered scope confirmations, numbered questions, structured replies through official channels, 24-hour cadence. You direct Claude through the inventory work, the policy authoring, the backend provisioning, and the state-mv plan. You verify by running the system, not by trusting the output.
What's New
Last time at MediConnect you authored the encoded-standards CLAUDE.md, designed a multi-dimensional verification system, and configured your first delegated audit agent. You leave that engagement with working habits at the encoded-standards layer, working OPA discipline, and a verification architecture you can adapt.
This time the IaC terrain itself advances. State surgery enters the project -- terraform state mv is the most dangerous Terraform command, and the post-move plan showing no changes is the only correct outcome. Policy-as-code stops being HIPAA examples someone else wrote and becomes Rego you author from a regulatory excerpt, tested with positive and negative cases before you trust it. Remote state with locking stops being assumed and becomes a backend you provision yourself and verify with a deliberate concurrent-apply test. And the codebase is mixed -- some Terraform, some CloudFormation, some console-only -- the normal state of inherited infrastructure, not an edge case.
The hard part: AI is fast at the syntax of state operations and slow at the structural verification. The same fluency that makes Claude useful is what makes a typo in a destination address dangerous. Reading state before and after every move is the first line of defence; the verification system is the second.
Tools
- Terraform -- carrying forward, with the state subcommand family (
state list,state mv,state pull,state rm) entering as the project's danger surface. - AWS S3 + DynamoDB for remote state -- new substance: you provision and verify both yourself.
- OPA + conftest -- carrying forward; new substance is sovereign-data policy authored from the UAE regulatory excerpt.
- CLAUDE.md as encoded standards -- carrying forward in shape, extended with the state-operation freeze Convention.
- AWS CloudFormation CLI -- new, used read-only for the inventory; no CloudFormation authoring required.
- checkov, Infracost, AWS Console + CLI, Claude Code, Git/GitHub, AWS Budgets -- carrying forward. (AWS MCP server is available from P12 onwards and remains configured, but no Unit in P14 exercises it — the engagement's substance is local state surgery against declarative IaC; live-resource queries via MCP are not on the verification path. If MCP saves time on a specific resource lookup, you can use it.)
Materials
In the project zip:
- Ahmed's official brief (
first-contact.md) -- the formal multi-section document opening the engagement. - Representative state files (
state-files/) -- five Terraform.tfstatefiles, three CloudFormation template exports, and a console-resources inventory CSV covering the twelve entities. - Sovereign-data regulatory excerpt (
sovereign-data-excerpt.md) -- the relevant UAE Information Assurance Standards subsections, with plain-English translation alongside. - Module structure reference (
module-structure-reference.md) -- the pattern for per-entity, shared-service, and top-level modules. The boundaries are your design. - State-mv methodology reference (
state-mv-methodology.md) -- the canonical sequence and the failure modes to guard against. - Coordination-protocol template (
coordination-protocol-template.md) -- a near-empty skeleton you fill in for the moves you plan. - CLAUDE.md -- the project governance file with engagement-specific facts in place.
You produce the inventory, the conflict analysis, the module structure, the remote state backend, the sovereign-data policy library, the state-mv plan, the coordination protocol, and the executed migration.