I tested my Azure infrastructure before I had an Azure account
October 24, 2026
Azure's free trial lasts 30 days from the moment you create it. I wrote and tested the whole infrastructure before opening one, with 170 Terraform tests that need no cloud and no credentials.
An Azure trial gives you 200 dollars of credit and 30 days, and the clock starts the day you create it. I had no Azure experience and knew the first month would go on writing code, so I decided not to open the account until the infrastructure was written and tested.
For comparison, Google Cloud's free trial gives you 300 dollars for 90 days. With one month, there's much less room to learn at the credit's expense, and that changed how I organized the work.
Testing without a cloud
Since version 1.7, Terraform lets you mock the provider inside its own tests. With a mocked provider, terraform test runs a real plan against Azure's schema with no credentials and nothing created. The schema is the full contract of what Azure accepts, so a shape error shows up on your laptop instead of in the cloud.
What sold me was the gap with validate. terraform validate checks syntax and types. It won't tell you whether a security group actually denies, whether the default route points at the firewall, or whether every private DNS zone got linked to both networks. Those are the properties worth protecting, and you can assert them in a plan.
I ended up with 170 tests across modules and layers, and they all run in continuous integration on every change.
What the mock taught me
The provider validates identifier formats at plan time. A policy assignment rejected the random identifier the mock makes up for a data source, and I had to give it a synthetic one with the right structure.
Assertions can only read values known at plan time. An attribute the API computes, like a resource's identifier, stays unknown and the test fails. The way out was running those tests in apply mode, which against a mocked provider still creates nothing but does resolve those values. I only use apply when an assertion needs it, because plan is cheaper and fails sooner.
And one detail that cost me a while: in the Azure provider a network's address space is a set, while a subnet's prefixes are a list. They look the same until you try to take the first element.
What the mock can't see
It has a clear limit. It knows nothing that only the API knows: your subscription's quota, whether a machine size exists in your region, whether a name is taken, how permissions work. All of that fails on the first deployment, and no mocked test will warn you.
It happened to me. The trial allows three public addresses and the firewall already uses two. And when I deployed from scratch the way a stranger would, three permissions I'd granted by hand turned out to be missing from the code. That's what the nine checks against real Azure are for: the mocked tests guard the shape, the live ones guard what only the cloud knows.
| Option | Cost | Risk | Verdict |
|---|---|---|---|
| terraform validate alone | CostNothing | RiskPasses a security group that denies nothing | VerdictNot enough |
| Tests against a mocked provider | CostWriting and maintaining 170 tests | RiskBlind to quota, permissions and regional availability | VerdictChosen for shape |
| Deploy every change to the cloud | CostCredit and minutes of waiting for every shape error | RiskBurning the free trial on details | VerdictOnly for what only the API knows |
What it cost
When I opened the account, the code had already been tested against Azure's schema, and the credit went on questions only Azure can answer.
The decision and its limits are written down in the repository.
How much of what you learn today by paying for cloud hours could you have learned on your laptop, before opening the account?