100 Days of IaC in Azure, a hundred and six-part writing series

A writing project, not a software project

100 Days of IaC in Azure is a repository of articles, with the latest available at the top. The README says so directly, and it points people at the watch and star buttons on the GitHub repository to keep up with the latest updates, and at a whois page to meet the people behind the series.

That framing matters, because the repository metadata makes it look like something else. The primary language is recorded as PLpgSQL, the PostgreSQL procedural language, and the top-level entries are `.vscode/`, `README.md`, `articles/`, `images/`, `resources/` and `whois.md`. There is no source code, no build system, no package and no licence classification in the repository metadata.

The PLpgSQL designation is a red herring and a clue at the same time. It comes from the SQL and PostgreSQL articles in the series, and it tells you the repository is being classified by the language detector running over whatever text is in the files. The articles are Markdown, and the SQL inside them is enough for a detector to make a guess.

So the repository is a publication. Each article is a Markdown file in `articles/`, named with the day number and a slug, and the README is the table of contents, generated by hand or by script, with a subject column and a link to each file. The `images/` directory holds the screenshots, `resources/` holds whatever supporting files the articles reference, and `.vscode/` holds the editor configuration the author used.

For a reader, the practical consequence is that this is a browse-and-search resource rather than a library. There is no API, no configuration file and nothing to upgrade. You clone it, or you read it on GitHub, and you find the article that covers your problem.

What the catalogue covers

The table in the README runs from day 106 down past day 61 in the visible portion, and the subject column is the more interesting of the two columns, because it is a classification of the work rather than a title.

The subject labels fall into a small number of families. ARM Template Deployments appears for day 95 on MariaDB, day 87 on Azure SQL Server, day 85 on MySQL, day 84 on Cosmos DB with the Mongo API, and day 82 on PostgreSQL. Azure CLI is a subject of its own for day 86 on deploying Azure SQL Server. Azure Bicep is the subject of the newest entry, day 106, on getting Bicep up and running in ten minutes.

Azure DevOps integrations cover several days: day 81 on troubleshooting Kubernetes applications with kubectl, days 78 to 80 on integrating Azure DevOps with Microsoft Teams in three parts, day 76 on self-hosted agents, and day 75 on securing GitHub Enterprise connections, with day 65 on integrating GitHub Enterprise with an Azure pipeline.

Kubernetes in Azure occupies days 71 to 74, with day 71 on the current state of Kubernetes in Azure and the following three on deploying a private Kubernetes cluster in Azure, in parts. DevSecOps in Azure DevOps is day 77, on the security code analysis extension.

Then there is the Azure SQL and storage articles, with days 102 and 103 on SQL deployment and security, day 88 on BACPAC files, day 94 on the Blobxfer utility for long-term backup retention, and day 93 on long-term backup retention for Azure Database for PostgreSQL.

That distribution is itself informative. Most of the entries in the visible range are about deploying one specific Azure service with a specific tool, and a large share of them are about securing or restricting access to a service. The series is not a tour of Azure services. It is a record of the infrastructure problems one team actually ran into.

The multi-part arcs, and what they show

The numbering makes the series' structure visible, and the multi-day arcs are the clearest sign of which topics the author considered deep enough to need more than one article.

Azure Front Door takes days 99 and 100, in parts. Azure SQL deployment and security takes days 102 and 103, and the subject column distinguishes them as part 1 and part 2. Private Kubernetes cluster deployment in Azure takes three days, 72, 73 and 74. Managing access to Linux VMs using Azure Key Vault takes three, 68, 69 and 70, again split into parts.

The Azure DevOps and Microsoft Teams integration is also a three-part run, days 78, 79 and 80, and the titles carry the part number explicitly, so the series is not shy about it.

The Kubernetes arc is the most instructive, because the first of the three is not a how-to at all. Day 71 is on the current state of Kubernetes in Azure, and the following three days are the deployment. The order suggests the author first established what the managed service looked like at the time, and only then wrote the procedure, which is a different editorial pattern from the one the day numbers imply for a reader skimming the list.

The resource locks articles are a run of three days as well, 96, 97 and 98, and it shows a pattern in the titles. Day 96 is using resource locks on individual resources in Azure, day 97 is automating resource locks on individual resources in Azure, and day 98 is using resource locks in a YAML pipeline. The progression is from the manual concept, to automating it, to putting it into a pipeline, which is the shape of most of the security articles in the series.

The Petri DevOps Day entries are a different kind of item, and the subject column says so. YAML Pipelines up and running in an hour, and Kubernetes up and running in an hour, sit in a `petri` subdirectory of articles rather than in the day-numbered set, and the title format is a time-to-value promise rather than a day number. They read as conference or community articles contributed alongside the main series.

The security through-line

If you read only one thread through the catalogue, it is the access control articles, and it is worth pulling out because it shows a particular way of thinking.

Four consecutive days, 89 to 92, are about restricting network access. Day 89 is on the options for managing access security to Azure Storage, day 90 on restricting network access to Azure Key Vault, day 91 on restricting network access to Azure Container Registry, and day 92 on restricting network access to Azure Database for PostgreSQL.

Four services, four days, one pattern. That is a systematic treatment of a problem rather than a set of unrelated posts, and the ordering is suggestive: storage first, then Key Vault, then the container registry, then the database. It reads like a team working through their own estate and writing down what they learned service by service.

The Key Vault articles appear twice. The three-part series on managing access to Linux VMs with Key Vault, days 68 to 70, is the earlier treatment, and day 104 on Azure Key Vault security and automation in plain English is the later one, framed for a reader who does not want the deep version. The parenthetical in the title, in plain English, is a signal about the intended audience of that entry in particular.

Day 105 is Azure Storage security end to end, which reads as a consolidation of the earlier storage work, and day 103 is part 2 of SQL deployment and security, so the security articles continue past the 90s.

For a reader, the value of this thread is that the articles are per-service, which is exactly how you look things up. If you have a container registry and a question about who can reach it, day 91 is the article. The downside is that these articles are dated, and the Azure CLI, the ARM template schema and the portal itself all move, so an article on a given day is a snapshot of a particular version of the tooling.

The tooling arc, from ARM to Bicep

The most interesting thing in the catalogue is what it says about tooling choices over time, and you can read that off the subject column and the day numbers.

ARM templates are the dominant label through the visible range. Day 95 on MariaDB, day 87 on Azure SQL Server, day 85 on MySQL, day 84 on Cosmos DB, day 82 on PostgreSQL, all as ARM template deployments. And two dedicated entries to the subject of ARM template technique itself, day 67 on Azure Resource Manager outputs and day 64 on implementing resource locks in ARM templates for infrastructure as code.

Then the Azure CLI appears as its own subject on day 86, deploying Azure SQL Server with the Azure CLI, and the newest entry, day 106, is Azure Bicep on getting up and running in ten minutes. Bicep is the newer declarative language that compiles to ARM templates, so a series that spent most of its time on ARM templates ending with a Bicep entry is a series that watched the ecosystem move and wrote about the new thing when it arrived.

The Kubernetes thread runs alongside. Day 71 is the state of Kubernetes in Azure, days 72 to 74 deploy a private cluster, and day 81 is a kubectl cheatsheet for troubleshooting Kubernetes applications, filed under Azure DevOps integrations. The kubectl cheatsheet is a different genre from the rest, a reference sheet rather than an article, and it sits at day 81 rather than in the numbered sequence proper.

There is also a build-pipeline thread that runs alongside everything else: day 98 on resource locks in a YAML pipeline, day 63 on a sample pipeline for the Azure network pattern, day 66 on a pipeline-friendly Azure Files script, and the Petri DevOps Day entries on YAML pipelines and Kubernetes in an hour.

So the through-line of the series is that the author kept a working Azure estate and wrote down each task as it came up, with the tasks themselves arranged by day number. The tooling arc is a side effect of that, and it happens to document a real migration from hand-written ARM templates toward a higher-level language.

What to expect from the series, and where to look instead

It is worth being clear about the kind of resource this is, because the name suggests something more structured than it is.

The title promises a hundred days, and the numbering delivers that, with the catalogue running past day 106. But the promise is about the count of articles, not about a curriculum. There is no stated learning objective per day, no progression from simple to advanced, and no exercise. It is a work diary with a serial number.

That is not a criticism, because a work diary is more useful in a specific way than a curriculum is. Every article answers a question that actually came up, with the commands that worked, on a service in front of the author. A curated tutorial path would tell you what to learn and in what order, and would answer questions nobody has. This answers real questions, in an order that reflects urgency rather than pedagogy.

The limitations follow from that. The articles are dated snapshots, so a command or a parameter may have changed. There is no version pinning, no automated testing of the examples and no mechanism that would notice when a service changes. The repository has no GitHub releases, and the last push to the repository was on 2026-09-26, so the state of the series is whatever is on the `master` branch. And the repository shows no licence classification in its metadata, which for a body of written articles is a small thing, but for anyone who wants to reuse the text or the images is worth resolving by asking the author or by reading the repository's licence file.

The alternatives are the obvious ones and they are good. The official Microsoft documentation for each service is authoritative and current, and where this series is more useful is the operational detail that documentation leaves out. A worked example of a specific service in a specific situation, written by someone who had to make it work, is the value here. And the subject index means you can find the one day that covers your problem without reading the rest.

The best way to use it is as a second opinion. When you are blocked on restricting network access to a container registry, or deploying a private AKS cluster, or setting up long-term backups for an Azure database, look up the day, read the article, and then check the current documentation for the parts it might have missed. That combination is faster and more reliable than either source alone.

Editorial conclusion

The series suits an Azure engineer who wants a worked example of one specific task, such as restricting network access to a Key Vault or deploying AKS from the Cloud Shell, and it suits a team that wants to see how a practitioner moved between ARM templates, the CLI and Bicep over a year of production work. It is not a tool, a module or a template library, and there is nothing to install. Verify first that the article you need covers the current shape of the service, since the series runs to day 106 with its most recent entry on Bicep, and check the linked Microsoft documentation for the feature itself, because the articles are dated snapshots of how the tooling behaved at the time.

Frequently asked questions

Official sources

1. Issues
2. README
3. starkfell/100DaysOfIaC on GitHub