Infra Course: a personal Azure course built from our own cloud

TL;DR

When I stepped up as CTO of Footprint Technologies, I had to take over our Azure cloud, and I didn’t really understand it. I asked Claude to build me a course about our own infrastructure. It read the live system and our Terraform, checked everything against the official docs, and then tested me on what we actually run.

The first exam gave me 75%. But only 7 of the 28 answers were correct and marked as “sure”. The rest was mostly guessing.

The walkthrough video and the screenshots come from a sanitized copy of the course. Resource names, IDs, domains and network ranges are fake, and no audit findings are shown.

What is this?

It’s a private course that runs on my laptop. It has seven modules, one for each part of our cloud: foundations, Terraform, networking, compute, data and secrets, identity, and edge/CI. Every module explains the concept first, then shows how we have it set up, and then makes me practice it. On the side there’s a chat that knows which page I’m reading, so I can ask whatever the page didn’t explain well.

Why did I build it?

When I stepped up as CTO there were some holes in my experience that I needed to fill. Coming from the deep tech and product part of the company, the Azure architecture was something I wasn’t prepared to handle. A part of me was still unsure if I should be the one managing it.

“Maybe we can hire someone to help us with this,” I thought. After a chat with our former CTO, that thought vanished. “You are the CTO now, this responsibility comes with the job title, I’m afraid,” he said.

Well, if I wanted to really understand it, I’d better start from the basics. So I set myself a target: I should be able to rebuild our architecture step by step, understanding the most important details of each part.

What I tried first

At some point I opened Claude Code and started building my own.

How did I build it?

Architecture

Fig. 1 · Solid = the build path. Dashed = the feedback loop.

Claude Code reads from three sources and writes everything it verifies into one file, the fact base. The exam and every module are written from that file. The course is plain HTML served by a small Python server, which saves my progress in SQLite. Before writing each new batch of modules, Claude reads that database and focuses on what I got wrong or guessed.

The ground truth

Before any course content existed, I wanted a source of information I could rely on. These were the steps:

1. I asked Claude to fetch the current state of our system. I set up the az CLI with an Entra role that can only read and list, and Claude wrote what it found into Markdown files (and JSON when needed).
2. I asked it to read all of our Terraform files and compare them with what it had just found. Anything that exists in Azure but not in the code, or runs a different version than the code says, is drift.
3. I asked it to organize everything into topics: Entra roles and permissions, networking, compute, data, and so on. Those topics became the modules.
4. I didn’t want Claude to just write the theory from its memory, so for each module I asked it to fetch the official Microsoft Learn and Terraform registry pages. I wanted to be as close to the source as possible. The course ends up linking to them around 20 times.

After that I had the data split into modules, the theory behind each one, and the current state of our cloud next to it.

Features

• A baseline exam with 28 multiple-choice questions. For each answer I also had to say whether I was Sure, Not sure or Guessing. I wanted the course to focus on my weak spots and my guesses, not only on the wrong answers. The (embarrassing) results of this exam are what the rest of the course is built on.
• Every module has five parts. Theory: what this is in Azure and how it works. Our estate: what we actually have, with the real names and how the pieces connect. Improvements: are we missing something according to best practices, and is there Terraform drift? Then Exercises and a Lab.
• Games to practice: flashcards with spaced repetition, multiple-choice questions, matching each service to its role, and putting the steps of a process in the right order.
• Labs where I run read-only az commands myself, so I get used to debugging things quickly from my laptop.
• A checkpoint at the end of each module, 8 or 9 questions where you need 80% to pass. Passing it also adds that module’s flashcards to the daily practice.
• The tutor chat on the side, which I can collapse. It gets the current page as context.
• Memory, which I explain below because it took me two tries.

Stack & dependencies

Key decisions & trade-offs

Once I had the results of the exam, the next problem was keeping state. I needed it in two places.

My own progress (scores, flashcards, streaks) was first saved in the browser’s localStorage. That went wrong (more on it below), so I moved it to SQLite through serve.py, with one snapshot per day. Claude’s progress between sessions lives in a PROGRESS.md file: what’s built, what I asked for, and what the database shows about me. With both, Claude can open the database, see what I failed, and write the next modules around it. I lost the simplicity of a purely static site, but without this the course wouldn’t adapt to me.

For the tutor, I didn’t want to pay for an API key or give it any power. The chat calls the Claude Code CLI, so it uses my normal login. It gets the fact base and my progress with the first message, the page text with every question, and it can only read files:

cmd = [CLAUDE_BIN, "-p", prompt, "--model", "sonnet",
       "--output-format", "stream-json", "--include-partial-messages"]
if session_id:
    cmd += ["--resume", session_id]
else:
    cmd += ["--system-prompt", tutor_system_prompt()]
# read-only tutor: Read/Grep/Glob stay available, nothing that mutates or leaves
cmd += ["--disallowedTools", "Bash", "Edit", "Write", "NotebookEdit",
        "WebSearch", "WebFetch", "Task"]

The downside is that it only works while serve.py is running on my machine.

How AI fit into the build

I didn’t write any of the code. What I did was decide what the course should be, take the exam honestly, and push back when something wasn’t right.

• Fable 5 planned the contents, the modules and the basic structure.
• Opus 5 built it, in Claude Code.
• Sonnet 5 runs the tutor chat.

Skills and tools it used:

One thing I kept asking for was evidence. Every claim about our cloud had to come from the live az reads or from the Terraform, and before writing a new module Claude checked the facts against the live tenant again.

Demo

The course is private, because it’s basically a map of our production cloud. The video at the top shows the whole flow. These are the parts I can show:

My routine is about 10 minutes of flashcards, then one part of a module per sitting. I take the checkpoint when I feel I’ve got the module.

What went wrong

• In the first versions, the correct answer was always more descriptive than the wrong ones. You could pass just by picking the longest option. I had to iterate a few times until they were balanced.
• Sonnet’s chat is a bit too verbose. It’s helpful, but it often explains again things I already know, even though its system prompt asks for short answers.
• I lost track of my progress for a few days. I’d been opening the course from file:// in a browser that wasn’t Chrome, so everything was saved only in that browser. Claude got it back by opening the page there with the server running, which pushed it to the database.
• Chrome kept an old cards.js in cache and the practice page broke until I did a hard refresh. Claude fixed it with a Cache-Control: no-cache header on the local server.
• At some point Claude Code’s permission check blocked some live Key Vault and VM reads. It slowed me down, but honestly I’d rather have that check near production.
• UI/UX wasn’t the main concern for this project. It works, but I could have improved it a bit.

By the numbers

Lessons learned

Asking how sure I was told me more than the score. 75% looked okay. Seeing that most of it was guessing is what told me where to focus.

I built the source of truth before the content, and I’d do it again. Comparing the live state, the code and the official docs found drift I didn’t know we had. That alone was worth the time.

Claude did better when it could see my results. I didn’t have to explain what I was bad at. It read the database and wrote the next modules around it.

This could be our onboarding. Anyone who joins the team needs the same map I needed, and this one also quizzes you.

Replicate it

This is the prompt to start from. Paste it into Claude Code (or any coding agent) inside a repo that has your infrastructure code, and adapt the first lines to your cloud.

I just took ownership of our Azure infrastructure and I need to understand it well enough to rebuild it step by step. Build me a private, local course about OUR cloud, not generic Azure.

1. Ground truth first. Using a read-only `az` login, inventory the live tenant and write the findings to Markdown (JSON where useful). Then read all the Terraform in this repo and compare it to what is live: list the drift (resources not in code, versions that differ). For every concept, check the official Microsoft Learn and Terraform registry docs instead of relying on memory, and keep the links.
2. Split the estate into modules (e.g. foundations, Terraform, networking, compute, data and secrets, identity, edge/CI). Save everything verified as one fact base; every question and lesson must come from it.
3. Before writing lessons, give me a baseline exam: ~28 multiple-choice questions where I also tag each answer Sure / Not sure / Guessed. Make wrong answers as long and as specific as the right ones.
4. Each module has five parts: Theory, Our estate (exact names and how they connect), Improvements (best practice gaps and drift), Exercises, and a Lab of read-only `az` commands I run myself. End each module with a checkpoint (80% to pass).
5. Add practice: spaced-repetition flashcards, matching and ordering games.
6. Stack: static HTML + vanilla JS, a stdlib-only Python server on 127.0.0.1 that saves my progress to SQLite. Keep a PROGRESS.md with what's built and what I asked.
7. Add a collapsible tutor chat that knows the current page, using `claude -p` with read-only tools only.
8. Before each new batch of modules, read my results in the database and write the batch around what I got wrong or guessed.

Never run commands that change anything in the cloud. Show your evidence for every claim about our estate.