July 14, 2026
Infrastructure as Code - Simply Explained
Managing cloud infrastructure by clicking through the Azure Portal might work for a single virtual machine, but it quickly becomes slow, inconsistent, and difficult to maintain as environments grow. Infrastructure as Code (IaC) changes that completely. In this episode, we explain Infrastructure as Code in plain English, showing how organizations automate Azure deployments using reusable templates instead of manual configuration. Whether you're an IT administrator, cloud engineer, developer, or just beginning your Azure journey, this episode provides a practical introduction to one of the most important concepts in modern cloud computing.
THE PROBLEM WITH MANUAL DEPLOYMENTS
Creating Azure resources manually through the portal introduces human error, inconsistent configurations, and configuration drift between development, testing, and production environments. Every mouse click becomes an opportunity to select the wrong region, choose an incorrect virtual machine size, misconfigure networking, or overlook important security settings. As organizations scale, these small inconsistencies become major operational challenges that consume valuable time and increase business risk. Infrastructure as Code eliminates these problems by replacing manual deployment with repeatable automation.
WHAT IS INFRASTRUCTURE AS CODE?
Infrastructure as Code, often abbreviated as IaC, is the practice of describing cloud infrastructure in source code instead of configuring resources manually. Rather than clicking through deployment wizards, administrators write files that define the desired infrastructure. Azure then reads these files and automatically provisions resource groups, virtual networks, storage accounts, virtual machines, databases, and security settings exactly as specified. This declarative approach focuses on the desired outcome while Azure handles the deployment process automatically.
THE AZURE INFRASTRUCTURE AS CODE TOOLKIT
Microsoft provides several technologies for implementing Infrastructure as Code. ARM Templates were the original deployment format, offering complete Azure coverage through JSON-based templates. Bicep builds upon ARM by providing a cleaner, easier-to-read language that compiles directly into ARM Templates while dramatically improving the authoring experience. Organizations operating across multiple cloud providers often choose Terraform, while Azure-focused teams increasingly adopt Bicep because of its native Azure integration, simplified syntax, and immediate support for new Azure services.
VERSION CONTROL CHANGES EVERYTHING
The greatest advantage of Infrastructure as Code is not simply automation—it's version control. By storing infrastructure definitions in Git repositories, organizations gain complete visibility into every infrastructure change. Teams can review modifications through pull requests, track deployment history, roll back problematic changes, and ensure development, testing, and production environments are built from the exact same source files. Infrastructure becomes fully auditable, collaborative, and significantly easier to maintain over time.
SECURITY BUILT INTO EVERY DEPLOYMENT
Infrastructure as Code enables organizations to standardize security from the very beginning. Encryption, networking policies, firewall rules, HTTPS enforcement, and compliance requirements become part of the deployment template itself instead of relying on manual configuration. Combined with Azure Policy, Azure Key Vault, and automated deployment pipelines, Infrastructure as Code helps organizations prevent configuration drift while ensuring every new environment follows the same secure baseline.
GETTING STARTED WITH IAC
Adopting Infrastructure as Code doesn't require rebuilding an entire Azure environment overnight. A practical starting point is exporting an existing Azure deployment as an ARM Template, studying its structure, and gradually transitioning to Bicep for future deployments. Microsoft provides free tooling through Azure CLI, Visual Studio Code, and the official Bicep extension, allowing administrators to learn incrementally while automating increasingly complex Azure workloads over time.
COMMON MISTAKES TO AVOID
New users often make several predictable mistakes when adopting Infrastructure as Code. Hardcoding passwords instead of using Azure Key Vault, treating templates as one-time deployment scripts, and making quick manual changes directly in the Azure Portal all introduce security risks and configuration drift. Maintaining descriptive templates, storing everything in source control, validating deployments before execution, and avoiding manual production changes help ensure long-term success with Infrastructure as Code.
WHY EVERY AZURE PROFESSIONAL SHOULD LEARN IAC
Infrastructure as Code has become a foundational skill for modern Azure administration. It improves deployment consistency, simplifies disaster recovery, enables CI/CD automation, strengthens security, supports collaboration, and dramatically reduces human error. Whether you're managing a single Azure subscription or enterprise-scale cloud platforms, Infrastructure as Code provides a reliable and scalable way to build, maintain, and evolve your cloud infrastructure with confidence.
KEY TAKEAWAYS
Infrastructure as Code replaces manual Azure configuration with repeatable, version-controlled deployment files that become the single source of truth for your cloud environment. By combining automation, security, governance, and collaboration into one modern workflow, IaC allows organizations to deploy Azure resources faster, reduce operational risk, and maintain consistent environments across every stage of the application lifecycle. It's no longer an advanced cloud technique—it's the standard approach to managing modern Azure infrastructure.
Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support.
🚀 Want to be part of m365.fm?
Then stop just listening… and start showing up.
👉 Connect with me on LinkedIn and let’s make something happen:
- 🎙️ Be a podcast guest and share your story
- 🎧 Host your own episode (yes, seriously)
- 💡 Pitch topics the community actually wants to hear
- 🌍 Build your personal brand in the Microsoft 365 space
This isn’t just a podcast — it’s a platform for people who take action.
🔥 Most people wait. The best ones don’t.
👉 Connect with me on LinkedIn and send me a message:
"I want in"
Let’s build something awesome 👊
1
00:00:00,000 --> 00:00:00,840
Imagine this.
2
00:00:00,840 --> 00:00:03,640
You need a test environment in Azure, nothing fancy.
3
00:00:03,640 --> 00:00:04,760
Just a virtual network,
4
00:00:04,760 --> 00:00:06,840
a couple of virtual machines and a storage account.
5
00:00:06,840 --> 00:00:08,260
So you log into the portal,
6
00:00:08,260 --> 00:00:10,640
find the resource group button and start clicking.
7
00:00:10,640 --> 00:00:12,120
One click to create the group.
8
00:00:12,120 --> 00:00:14,080
A few more to set up the virtual network
9
00:00:14,080 --> 00:00:16,600
then you walk through the VM creation wizard,
10
00:00:16,600 --> 00:00:19,120
pick the region, pick the size, pick the image,
11
00:00:19,120 --> 00:00:21,000
configure the disk, set up networking.
12
00:00:21,000 --> 00:00:22,760
That is maybe 50 clicks right there.
13
00:00:22,760 --> 00:00:24,560
Then you do it again for the second VM,
14
00:00:24,560 --> 00:00:26,160
then you configure the storage account,
15
00:00:26,160 --> 00:00:27,680
then you set up the firewall rules.
16
00:00:27,680 --> 00:00:28,560
And here's the thing.
17
00:00:28,560 --> 00:00:30,000
Every single one of those clicks
18
00:00:30,000 --> 00:00:31,360
is a chance to make a mistake.
19
00:00:31,360 --> 00:00:34,080
Pick the wrong region, your app runs slower than it should,
20
00:00:34,080 --> 00:00:37,360
choose the wrong VM size, you are overpaying from day one.
21
00:00:37,360 --> 00:00:38,600
Forget to close a port,
22
00:00:38,600 --> 00:00:40,760
you just exposed your environment to the internet
23
00:00:40,760 --> 00:00:41,800
without realizing it.
24
00:00:41,800 --> 00:00:43,680
Now multiply that by three environments.
25
00:00:43,680 --> 00:00:45,560
Dev, test, production,
26
00:00:45,560 --> 00:00:47,680
suddenly you are not doing 50 clicks,
27
00:00:47,680 --> 00:00:49,120
you are doing 150.
28
00:00:49,120 --> 00:00:50,320
And somewhere in that process,
29
00:00:50,320 --> 00:00:53,720
production ends up looking nothing like dev.
30
00:00:53,720 --> 00:00:55,320
A setting here, a checkbox there.
31
00:00:55,320 --> 00:00:57,600
Small differences that cause big headaches later.
32
00:00:57,600 --> 00:01:00,080
But what if you could describe your entire Azure setup
33
00:01:00,080 --> 00:01:02,480
in a file instead of clicking through all those screens?
34
00:01:02,480 --> 00:01:04,320
What if you could run that file once
35
00:01:04,320 --> 00:01:06,440
and get the same result every single time?
36
00:01:06,440 --> 00:01:08,040
That is what we are talking about today.
37
00:01:08,040 --> 00:01:09,440
By the end of this episode,
38
00:01:09,440 --> 00:01:13,120
you will understand what infrastructure as code actually is,
39
00:01:13,120 --> 00:01:14,920
why as your teams rely on it
40
00:01:14,920 --> 00:01:17,720
and how you can start using it without being a developer.
41
00:01:17,720 --> 00:01:21,200
What manual provisioning actually costs you?
42
00:01:21,200 --> 00:01:23,360
Let us walk through a typical Azure setup.
43
00:01:23,360 --> 00:01:25,320
You need a resource group inside that,
44
00:01:25,320 --> 00:01:27,800
a virtual network with a couple of subnets,
45
00:01:27,800 --> 00:01:29,160
then a couple of virtual machines,
46
00:01:29,160 --> 00:01:31,520
one for your web server, one for your database
47
00:01:31,520 --> 00:01:33,720
and a storage account for your application data.
48
00:01:33,720 --> 00:01:36,200
In the portal, that is a solid afternoon of clicking.
49
00:01:36,200 --> 00:01:37,200
And here is the problem.
50
00:01:37,200 --> 00:01:39,640
Every single click is a chance for a mistake.
51
00:01:39,640 --> 00:01:40,920
Maybe you pick the wrong region
52
00:01:40,920 --> 00:01:42,680
because the drop down defaults to East US
53
00:01:42,680 --> 00:01:43,920
and you meant West Europe.
54
00:01:43,920 --> 00:01:46,560
Maybe you choose a VM size that is way too expensive
55
00:01:46,560 --> 00:01:47,960
for what you actually need.
56
00:01:47,960 --> 00:01:49,680
Maybe you accidentally leave a management port
57
00:01:49,680 --> 00:01:50,800
open to the internet.
58
00:01:50,800 --> 00:01:51,960
These mistakes happen.
59
00:01:51,960 --> 00:01:53,600
They happen because the portal makes it easy
60
00:01:53,600 --> 00:01:56,000
to click fast and hard to slow down and check your work.
61
00:01:56,000 --> 00:01:57,720
And the real cost is not just the time
62
00:01:57,720 --> 00:01:59,400
you waste fixing those mistakes.
63
00:01:59,400 --> 00:02:01,280
It is the time you spend repeating the same clicks
64
00:02:01,280 --> 00:02:03,520
for dev, test, staging and production
65
00:02:03,520 --> 00:02:04,600
because here is what happens.
66
00:02:04,600 --> 00:02:05,720
You build dev on Monday.
67
00:02:05,720 --> 00:02:07,680
It takes you three hours and it works perfectly.
68
00:02:07,680 --> 00:02:09,600
On Tuesday, you build test.
69
00:02:09,600 --> 00:02:12,480
You are a little faster this time, two and a half hours.
70
00:02:12,480 --> 00:02:13,800
But you forget one setting.
71
00:02:13,800 --> 00:02:16,760
A firewall rule that was open in dev is closed in test.
72
00:02:16,760 --> 00:02:18,040
Your application behaves differently
73
00:02:18,040 --> 00:02:19,680
and you spend an hour debugging it.
74
00:02:19,680 --> 00:02:21,800
By the time you get to production on Friday,
75
00:02:21,800 --> 00:02:24,040
your environment looks nothing like dev.
76
00:02:24,040 --> 00:02:27,080
Different VM sizes, different storage configurations.
77
00:02:27,080 --> 00:02:28,800
A few settings you change because someone said,
78
00:02:28,800 --> 00:02:30,280
just try this real quick.
79
00:02:30,280 --> 00:02:31,720
That is configuration drift.
80
00:02:31,720 --> 00:02:34,840
And it is the natural result of building environments by hand.
81
00:02:34,840 --> 00:02:37,480
The real problem is that you cannot audit a mouse click.
82
00:02:37,480 --> 00:02:38,960
You cannot roll back a mouse click.
83
00:02:38,960 --> 00:02:41,360
If something breaks in production six weeks from now,
84
00:02:41,360 --> 00:02:43,880
you will not remember which checkbox you checked or unchecked.
85
00:02:43,880 --> 00:02:46,920
You will not have a record of what changed between dev and production.
86
00:02:46,920 --> 00:02:50,320
So what if you could describe your entire Azure setup in a file
87
00:02:50,320 --> 00:02:52,000
instead of clicking through screens?
88
00:02:52,000 --> 00:02:54,720
One file that says exactly what your environment should look like.
89
00:02:54,720 --> 00:02:56,560
Run it once, get the same result every time.
90
00:02:56,560 --> 00:02:58,240
Run it again, get the same result again.
91
00:02:58,240 --> 00:02:59,920
No drift, no forgotten settings,
92
00:02:59,920 --> 00:03:03,080
no production environments that look nothing like dev.
93
00:03:03,080 --> 00:03:06,120
Infrastructure as code, the one sentence definition.
94
00:03:06,120 --> 00:03:08,720
Infrastructure as code means describing your infrastructure
95
00:03:08,720 --> 00:03:10,760
in a file that Azure can read and build for you.
96
00:03:10,760 --> 00:03:11,440
That is it.
97
00:03:11,440 --> 00:03:12,400
One sentence.
98
00:03:12,400 --> 00:03:15,520
You write a file, Azure reads it, and your environment appears.
99
00:03:15,520 --> 00:03:16,880
Think of it like an office building.
100
00:03:16,880 --> 00:03:18,400
If you wanted to set up a new office,
101
00:03:18,400 --> 00:03:22,120
you could walk around and tell each worker where to put every desk and every chair.
102
00:03:22,120 --> 00:03:23,520
That is the manual approach.
103
00:03:23,520 --> 00:03:27,480
It works, but it is slow and everyone will end up with a slightly different arrangement.
104
00:03:27,480 --> 00:03:28,920
Or you could hand them a blueprint.
105
00:03:28,920 --> 00:03:31,480
One piece of paper that says exactly where everything goes.
106
00:03:31,480 --> 00:03:34,720
Every room is identical because everyone followed the same plan.
107
00:03:34,720 --> 00:03:36,520
Your ISE file is that blueprint.
108
00:03:36,520 --> 00:03:40,000
It is a single source of truth for your entire Azure environment.
109
00:03:40,000 --> 00:03:41,520
Everything your environment needs,
110
00:03:41,520 --> 00:03:43,840
the resource groups, the virtual networks, the VMs,
111
00:03:43,840 --> 00:03:47,800
the storage accounts, the firewall rules, it is all in that one file.
112
00:03:47,800 --> 00:03:49,840
Now there is an important distinction here.
113
00:03:49,840 --> 00:03:52,280
IAC uses what is called a declarative approach.
114
00:03:52,280 --> 00:03:54,920
That is a fancy way of saying you tell Azure what you want,
115
00:03:54,920 --> 00:03:57,280
not how to build it, step by step.
116
00:03:57,280 --> 00:03:59,120
You do not say create a resource group,
117
00:03:59,120 --> 00:04:01,160
then create a virtual network inside it,
118
00:04:01,160 --> 00:04:03,360
then create a subnet inside that.
119
00:04:03,360 --> 00:04:07,200
You say, I want a resource group with a virtual network that has a subnet.
120
00:04:07,200 --> 00:04:08,440
Azure figures out the order.
121
00:04:08,440 --> 00:04:12,080
This is different from the scripts that system administrators have used for years.
122
00:04:12,080 --> 00:04:13,320
Scripts are imperative.
123
00:04:13,320 --> 00:04:16,720
They tell the system exactly what to do, step by step, do this,
124
00:04:16,720 --> 00:04:17,520
then do that,
125
00:04:17,520 --> 00:04:18,520
then do this other thing.
126
00:04:18,520 --> 00:04:20,720
And if one step fails, the whole thing breaks.
127
00:04:20,720 --> 00:04:22,200
IAC is the opposite.
128
00:04:22,200 --> 00:04:25,640
You describe the end state and the system figures out how to get there.
129
00:04:25,640 --> 00:04:27,080
Here is a concrete example.
130
00:04:27,080 --> 00:04:31,160
Instead of typing 50 separate CLI commands to create a virtual machine,
131
00:04:31,160 --> 00:04:32,160
you write something like,
132
00:04:32,160 --> 00:04:35,000
I need a virtual machine with eight gigabytes of RAM,
133
00:04:35,000 --> 00:04:36,920
running Ubuntu 22.04,
134
00:04:36,920 --> 00:04:40,360
connected to this virtual network with this storage account attached.
135
00:04:40,360 --> 00:04:42,840
That is it, one description instead of 100 commands.
136
00:04:42,840 --> 00:04:46,840
And this matters for Azure specifically because the portal makes it so easy to start.
137
00:04:46,840 --> 00:04:50,280
You can have a virtual machine running in 10 minutes with a few clicks.
138
00:04:50,280 --> 00:04:53,680
But the portal does not scale when you need 10 environments instead of one,
139
00:04:53,680 --> 00:04:55,520
the portal becomes a liability.
140
00:04:55,520 --> 00:04:57,520
IAC is how you break out of that trap.
141
00:04:57,520 --> 00:04:58,560
So that sounds useful, right?
142
00:04:58,560 --> 00:05:02,760
But what tools does Microsoft actually give you to write these blueprint files?
143
00:05:02,760 --> 00:05:06,320
The Azure IAC toolkit, ARM, bicep, and the elephant in the room.
144
00:05:06,320 --> 00:05:10,200
So what tools does Microsoft actually give you to write these blueprint files?
145
00:05:10,200 --> 00:05:12,200
The original one is called ARM templates.
146
00:05:12,200 --> 00:05:14,280
ARM stands for Azure Resource Manager,
147
00:05:14,280 --> 00:05:16,520
and these templates have been around since the beginning.
148
00:05:16,520 --> 00:05:21,640
They are written in JSON, which is a data format that looks like a configuration file from 2015.
149
00:05:21,640 --> 00:05:24,640
Lots of curly braces, lots of brackets, lots of indentation.
150
00:05:24,640 --> 00:05:27,160
If you have ever looked at a JSON file, you know what I mean.
151
00:05:27,160 --> 00:05:29,960
It is functional, but it is not pleasant to read.
152
00:05:29,960 --> 00:05:33,280
ARM templates are still widely used, especially in enterprise environments.
153
00:05:33,280 --> 00:05:36,720
Big companies have invested years into building their template libraries.
154
00:05:36,720 --> 00:05:38,800
And they are not about to throw that work away.
155
00:05:38,800 --> 00:05:43,440
But if you are a beginner looking at an ARM template for the first time can be intimidating.
156
00:05:43,440 --> 00:05:45,400
It is verbose, it is easy to break.
157
00:05:45,400 --> 00:05:47,320
One missing comma and the whole thing fails.
158
00:05:47,320 --> 00:05:48,880
Writing one by hand is painful.
159
00:05:48,880 --> 00:05:50,800
Microsoft recognized this problem.
160
00:05:50,800 --> 00:05:52,160
So they built bicep.
161
00:05:52,160 --> 00:05:55,880
bicep is Microsoft's answer to ARM templates are too complicated.
162
00:05:55,880 --> 00:05:59,480
It is a newer language that compiles down to ARM templates behind the scenes.
163
00:05:59,480 --> 00:06:00,960
But the syntax is much cleaner.
164
00:06:00,960 --> 00:06:02,320
It looks like actual code.
165
00:06:02,320 --> 00:06:05,320
You write something like resource myvm, Microsoft.
166
00:06:05,320 --> 00:06:08,880
Compute virtual machines at 223.0301.
167
00:06:08,880 --> 00:06:09,680
L.O.
168
00:06:09,680 --> 00:06:11,960
Instead of pages of nested JSON.
169
00:06:11,960 --> 00:06:13,840
It is designed for humans first.
170
00:06:13,840 --> 00:06:16,920
Now there is another option you will hear about Terraform.
171
00:06:16,920 --> 00:06:20,760
Terraform is a tool from a company called Hashikorp and it works with Azure and other clouds.
172
00:06:20,760 --> 00:06:26,080
If you need to manage infrastructure across AWS, Google Cloud and Azure all at once, Terraform
173
00:06:26,080 --> 00:06:27,080
is your best bet.
174
00:06:27,080 --> 00:06:28,160
It is more portable.
175
00:06:28,160 --> 00:06:30,240
But that portability comes with a cost.
176
00:06:30,240 --> 00:06:32,680
Terraform adds a layer of abstraction between you and Azure.
177
00:06:32,680 --> 00:06:37,440
You have to learn Terraform's own language, HCl, on top of understanding Azure itself.
178
00:06:37,440 --> 00:06:40,080
It is powerful but it introduces its own complexity.
179
00:06:40,080 --> 00:06:41,640
So which one should the beginner pick?
180
00:06:41,640 --> 00:06:43,880
If you are a Zua only, start with bicep.
181
00:06:43,880 --> 00:06:44,880
The reason is simple.
182
00:06:44,880 --> 00:06:45,880
Native integration.
183
00:06:45,880 --> 00:06:48,120
bicep is built by Microsoft specifically for Azure.
184
00:06:48,120 --> 00:06:49,720
It has fewer moving parts.
185
00:06:49,720 --> 00:06:51,480
It gets Microsoft's full support.
186
00:06:51,480 --> 00:06:55,120
And because it compiles down to ARM templates, you are not locked into anything.
187
00:06:55,120 --> 00:06:58,320
You can always switch to raw ARM templates later if you need to.
188
00:06:58,320 --> 00:07:02,160
bicep is the path of least resistance for someone who just wants to get started.
189
00:07:02,160 --> 00:07:04,120
Here is how these tools work in practice.
190
00:07:04,120 --> 00:07:05,120
You write a file.
191
00:07:05,120 --> 00:07:07,560
A bicep file, an ARM template, whatever you choose.
192
00:07:07,560 --> 00:07:08,920
Then you run a command.
193
00:07:08,920 --> 00:07:12,280
A bicep that command is as deployment group create.
194
00:07:12,280 --> 00:07:13,880
Azure reads your file.
195
00:07:13,880 --> 00:07:17,440
Compares it to what already exists and builds whatever is missing or changes whatever is
196
00:07:17,440 --> 00:07:18,440
different.
197
00:07:18,440 --> 00:07:20,520
You do not have to tell Azure what order to do things in.
198
00:07:20,520 --> 00:07:22,080
It figures that out on its own.
199
00:07:22,080 --> 00:07:23,720
And here is where it gets really interesting.
200
00:07:23,720 --> 00:07:26,160
You can hook this into a CICD pipeline.
201
00:07:26,160 --> 00:07:28,120
Continuous integration, continuous deployment.
202
00:07:28,120 --> 00:07:32,160
That means every time you push a change to your code repository, Azure automatically runs
203
00:07:32,160 --> 00:07:34,640
your IAC file and updates your infrastructure.
204
00:07:34,640 --> 00:07:37,280
No manual steps, no one logging into the portal.
205
00:07:37,280 --> 00:07:40,160
That code changes flowing into production automatically.
206
00:07:40,160 --> 00:07:42,520
So you have a file that describes your infrastructure.
207
00:07:42,520 --> 00:07:44,440
You can run it and get a consistent result.
208
00:07:44,440 --> 00:07:46,640
You can even automate the whole thing with a pipeline.
209
00:07:46,640 --> 00:07:48,040
But what does that actually unlock?
210
00:07:48,040 --> 00:07:50,080
That is where things get really powerful.
211
00:07:50,080 --> 00:07:53,080
What version control does for your Azure environment?
212
00:07:53,080 --> 00:07:55,160
Here is the thing people do not talk about enough.
213
00:07:55,160 --> 00:07:57,920
The real superpower of IAC is not the template format itself.
214
00:07:57,920 --> 00:08:00,320
It is not bicep versus ARM versus Terraform.
215
00:08:00,320 --> 00:08:02,080
The real superpower is version control.
216
00:08:02,080 --> 00:08:06,600
When you store your IAC files in a repository like GitHub or Azure Repos, every single
217
00:08:06,600 --> 00:08:08,240
change becomes trackable.
218
00:08:08,240 --> 00:08:09,240
Who changed what?
219
00:08:09,240 --> 00:08:10,240
When they changed it?
220
00:08:10,240 --> 00:08:11,240
Why they changed it?
221
00:08:11,240 --> 00:08:15,040
You get a complete history of every modification to your infrastructure going back to day
222
00:08:15,040 --> 00:08:16,040
one.
223
00:08:16,040 --> 00:08:17,040
And that means you can roll back.
224
00:08:17,040 --> 00:08:20,120
If a deployment breaks something, you do not have to guess what went wrong.
225
00:08:20,120 --> 00:08:23,720
You do not have to dig through portal audit logs hoping to find the answer.
226
00:08:23,720 --> 00:08:27,160
You just revert to the last working version of your IAC file and redeploy.
227
00:08:27,160 --> 00:08:28,520
The problem disappears.
228
00:08:28,520 --> 00:08:31,440
That is something you simply cannot do with mouse clicks.
229
00:08:31,440 --> 00:08:33,920
It also means your environments stay consistent.
230
00:08:33,920 --> 00:08:36,720
You have tests and production all come from the same files.
231
00:08:36,720 --> 00:08:40,680
Not similar files, not files that started the same but drifted apart over time, the same
232
00:08:40,680 --> 00:08:41,680
files.
233
00:08:41,680 --> 00:08:43,040
You deploy dev from your main branch.
234
00:08:43,040 --> 00:08:47,080
When you are ready for test, you deploy the same files to the test subscription.
235
00:08:47,080 --> 00:08:50,280
When you are ready for production, you deploy the same files again.
236
00:08:50,280 --> 00:08:54,400
Every environment is identical because every environment was built from the same blueprint.
237
00:08:54,400 --> 00:08:58,880
And because these files live in a repository, you can do code reviews for infrastructure.
238
00:08:58,880 --> 00:09:03,280
Before anyone deploys a change, another team member has to look at it and approve it.
239
00:09:03,280 --> 00:09:06,120
It catches mistakes before they ever reach your environment.
240
00:09:06,120 --> 00:09:09,560
It is the same process software developers use for application code.
241
00:09:09,560 --> 00:09:10,880
Apply to your Azure setup.
242
00:09:10,880 --> 00:09:12,240
Here is a real world example.
243
00:09:12,240 --> 00:09:15,160
Someone on your team accidentally opens a storage account to the public.
244
00:09:15,160 --> 00:09:18,120
Without IAC, you might not notice until the bill arrives.
245
00:09:18,120 --> 00:09:20,280
Or until someone tells you your data is exposed.
246
00:09:20,280 --> 00:09:22,680
With IAC, that change is visible in the repository.
247
00:09:22,680 --> 00:09:24,280
It goes through code review.
248
00:09:24,280 --> 00:09:27,560
Someone spots it and says, "Hey, that storage account should not be public."
249
00:09:27,560 --> 00:09:30,040
The change gets blocked before it ever reaches production.
250
00:09:30,040 --> 00:09:32,680
And if it somehow slips through, you can roll it back in seconds.
251
00:09:32,680 --> 00:09:34,680
You can even use branching strategies.
252
00:09:34,680 --> 00:09:36,520
Want to experiment with a new configuration?
253
00:09:36,520 --> 00:09:40,480
Create a separate branch, make your changes, deploy to a test environment, see if it works.
254
00:09:40,480 --> 00:09:42,120
If it does merge back to the main branch.
255
00:09:42,120 --> 00:09:45,040
If it does not, delete the branch and try something else.
256
00:09:45,040 --> 00:09:48,960
Your production environment never gets touched until you are confident that change is safe.
257
00:09:48,960 --> 00:09:50,160
Consistency is great.
258
00:09:50,160 --> 00:09:53,040
But IAC also makes your Azure setup more secure.
259
00:09:53,040 --> 00:09:57,000
And that matters whether you have one person managing everything or a whole team.
260
00:09:57,000 --> 00:09:59,520
Security by design, not by accident.
261
00:09:59,520 --> 00:10:01,800
Here is something that surprises a lot of people.
262
00:10:01,800 --> 00:10:04,880
When you use IAC, security is not something you add later.
263
00:10:04,880 --> 00:10:07,200
It is baked into the template from the start.
264
00:10:07,200 --> 00:10:10,640
Instead of remembering to enable encryption on every new storage account, it is already in
265
00:10:10,640 --> 00:10:11,640
your file.
266
00:10:11,640 --> 00:10:15,200
Instead of hoping someone configured the firewall rules correctly, the rules are written
267
00:10:15,200 --> 00:10:17,320
down and enforced every single time.
268
00:10:17,320 --> 00:10:19,560
This idea has a name, policy as code.
269
00:10:19,560 --> 00:10:22,640
You encode your security rules directly into your deployment pipeline.
270
00:10:22,640 --> 00:10:27,040
So every time someone tries to deploy a storage account, the pipeline checks that HTTPS
271
00:10:27,040 --> 00:10:30,840
is enabled, that encryption is turned on, that public access is blocked.
272
00:10:30,840 --> 00:10:33,880
If the template does not meet those rules, the deployment fails.
273
00:10:33,880 --> 00:10:36,880
The insecure configuration never reaches your environment.
274
00:10:36,880 --> 00:10:38,520
Think about what that replaces.
275
00:10:38,520 --> 00:10:40,000
Dozens of manual checks.
276
00:10:40,000 --> 00:10:42,320
Someone remembering to tick the right checkbox.
277
00:10:42,320 --> 00:10:44,320
Someone else auditing those checkboxes later.
278
00:10:44,320 --> 00:10:45,680
All of that goes away.
279
00:10:45,680 --> 00:10:51,240
One secure template, one set of policies and every deployment automatically meets your security
280
00:10:51,240 --> 00:10:52,240
baseline.
281
00:10:52,240 --> 00:10:54,680
But here is where it gets really interesting, disaster recovery.
282
00:10:54,680 --> 00:10:57,880
The file that describes your infrastructure can rebuild it anywhere.
283
00:10:57,880 --> 00:11:01,600
If an attacker compromises your environment, you do not have to spend days trying to figure
284
00:11:01,600 --> 00:11:03,480
out what they changed and how to fix it.
285
00:11:03,480 --> 00:11:04,480
You tear it down.
286
00:11:04,480 --> 00:11:06,120
You redeploy from your IAC file.
287
00:11:06,120 --> 00:11:08,080
Your clean environment is back in minutes.
288
00:11:08,080 --> 00:11:10,920
That is not possible when your infrastructure was built by hand.
289
00:11:10,920 --> 00:11:13,720
And because everything is in version control, you have an audit trail.
290
00:11:13,720 --> 00:11:15,760
Every change to your infrastructure is recorded.
291
00:11:15,760 --> 00:11:16,760
Who made it?
292
00:11:16,760 --> 00:11:17,760
When?
293
00:11:17,760 --> 00:11:18,760
Why?
294
00:11:18,760 --> 00:11:20,520
That is compliance evidence without anyone having to fill out a spreadsheet.
295
00:11:20,520 --> 00:11:24,760
For small teams, without dedicated security staff, this is a force multiplier.
296
00:11:24,760 --> 00:11:28,840
You get enterprise grade security practices without hiring an enterprise grade security team.
297
00:11:28,840 --> 00:11:30,280
This all sounds great on paper.
298
00:11:30,280 --> 00:11:32,160
But getting started can feel overwhelming.
299
00:11:32,160 --> 00:11:35,040
Let me give you a realistic path forward.
300
00:11:35,040 --> 00:11:37,080
How to start without breaking anything?
301
00:11:37,080 --> 00:11:38,080
Rule one.
302
00:11:38,080 --> 00:11:39,080
Do not start with production.
303
00:11:39,080 --> 00:11:40,760
I cannot emphasize this enough.
304
00:11:40,760 --> 00:11:43,120
IAC is powerful, but it is also new.
305
00:11:43,120 --> 00:11:44,240
You will make mistakes.
306
00:11:44,240 --> 00:11:45,240
Make them somewhere.
307
00:11:45,240 --> 00:11:46,240
It does not matter.
308
00:11:46,240 --> 00:11:49,640
Pick one small piece of your Azure environment, a resource group with a single virtual
309
00:11:49,640 --> 00:11:51,600
machine or a storage account.
310
00:11:51,600 --> 00:11:53,560
Something simple that you already have running.
311
00:11:53,560 --> 00:11:54,560
Something you know works.
312
00:11:54,560 --> 00:11:55,560
Here is the trick.
313
00:11:55,560 --> 00:11:59,480
The Azure portal can actually generate arm templates from your existing resources.
314
00:11:59,480 --> 00:12:02,480
You go to your resource group, click export template.
315
00:12:02,480 --> 00:12:05,840
An Azure gives you the JSON file that describes everything in that group.
316
00:12:05,840 --> 00:12:07,000
It is not perfect.
317
00:12:07,000 --> 00:12:09,920
The exported template often includes things you do not need.
318
00:12:09,920 --> 00:12:11,320
But it is a starting point.
319
00:12:11,320 --> 00:12:14,440
You take something you build manually and convert it to code.
320
00:12:14,440 --> 00:12:17,840
That is the reverse engineer approach and it is the fastest way to learn.
321
00:12:17,840 --> 00:12:20,000
Start with bicep and the free Azure tools.
322
00:12:20,000 --> 00:12:24,080
Microsoft has a VS Code extension for bicep that gives you syntax highlighting, auto completion
323
00:12:24,080 --> 00:12:26,120
and a visual preview of what you are building.
324
00:12:26,120 --> 00:12:29,680
You can see your virtual network and your subnets rendered as a diagram before you deploy
325
00:12:29,680 --> 00:12:30,680
anything.
326
00:12:30,680 --> 00:12:33,920
That makes it much easier to understand what your code actually does.
327
00:12:33,920 --> 00:12:35,880
Use a separate subscription for testing.
328
00:12:35,880 --> 00:12:39,160
Most Azure subscriptions have spending limits and free credits.
329
00:12:39,160 --> 00:12:40,640
Create a test subscription.
330
00:12:40,640 --> 00:12:44,000
Deploy your IAC there, break things, fix them, learn.
331
00:12:44,000 --> 00:12:47,440
When you are confident, move to a non-production subscription.
332
00:12:47,440 --> 00:12:49,040
Production comes last.
333
00:12:49,040 --> 00:12:51,000
Here is the part that might surprise you.
334
00:12:51,000 --> 00:12:53,480
You do not need to be a software engineer to do this.
335
00:12:53,480 --> 00:12:55,240
The citizen developer angle is real.
336
00:12:55,240 --> 00:12:59,640
Bicep was designed for people who manage Azure infrastructure not for professional programmers.
337
00:12:59,640 --> 00:13:00,640
It is readable.
338
00:13:00,640 --> 00:13:03,080
It has less ceremony than traditional programming languages.
339
00:13:03,080 --> 00:13:04,840
It is focused on Azure and nothing else.
340
00:13:04,840 --> 00:13:08,880
If you can understand what a virtual machine is, you can learn to describe one in bicep.
341
00:13:08,880 --> 00:13:10,600
Your first practical project?
342
00:13:10,600 --> 00:13:13,040
Automate your dev environment, tear down and rebuild.
343
00:13:13,040 --> 00:13:15,560
Write a bicep file that creates your dev setup.
344
00:13:15,560 --> 00:13:18,360
Deploy it, use it, then tear it down and deploy it again.
345
00:13:18,360 --> 00:13:21,040
Do that a few times until the process feels routine.
346
00:13:21,040 --> 00:13:24,840
And exercise alone will teach you more about IAC than any tutorial.
347
00:13:24,840 --> 00:13:27,200
A few pieces of common beginner advice.
348
00:13:27,200 --> 00:13:28,880
Commit early and commit often.
349
00:13:28,880 --> 00:13:32,360
Every time you get a piece of your template working, save it to your repository that gives
350
00:13:32,360 --> 00:13:34,240
you checkpoints you can go back to.
351
00:13:34,240 --> 00:13:36,960
And always run the preview command before deploying.
352
00:13:36,960 --> 00:13:38,560
In bicep that is what if.
353
00:13:38,560 --> 00:13:41,680
It shows you exactly what will change before anything actually changes.
354
00:13:41,680 --> 00:13:43,200
No surprises.
355
00:13:43,200 --> 00:13:47,120
Even with the best intentions, there are a few traps beginners fall into.
356
00:13:47,120 --> 00:13:49,840
Let me save you some late night debugging sessions.
357
00:13:49,840 --> 00:13:51,400
Three mistakes that will haunt you.
358
00:13:51,400 --> 00:13:52,800
And how to avoid them.
359
00:13:52,800 --> 00:13:54,600
Mistake number one is the classic.
360
00:13:54,600 --> 00:13:55,600
Hard coding secrets.
361
00:13:55,600 --> 00:13:56,600
You are in a hurry.
362
00:13:56,600 --> 00:13:59,800
You need to get a template working so you drop the database password right there in the
363
00:13:59,800 --> 00:14:00,800
file.
364
00:14:00,800 --> 00:14:01,800
It works.
365
00:14:01,800 --> 00:14:02,800
You move on.
366
00:14:02,800 --> 00:14:06,080
And now your password is sitting in your IAC repository for anyone with access to see.
367
00:14:06,080 --> 00:14:07,160
Obviously in hindsight, right?
368
00:14:07,160 --> 00:14:10,760
But it is incredibly easy to do when you are focused on getting something to work.
369
00:14:10,760 --> 00:14:12,560
The solution is Azure Key Vault.
370
00:14:12,560 --> 00:14:17,640
Both bicep and ARM templates can pull secrets directly from Key Vault at deployment time.
371
00:14:17,640 --> 00:14:21,880
Your file says get the password from this vault instead of containing the actual password.
372
00:14:21,880 --> 00:14:24,000
The secret never touches your repository.
373
00:14:24,000 --> 00:14:27,800
Never put passwords, connection strings or API keys in your IAC files.
374
00:14:27,800 --> 00:14:30,560
Use Key Vault every single time.
375
00:14:30,560 --> 00:14:33,840
Mistake number two is treating IAC like a one time script.
376
00:14:33,840 --> 00:14:37,440
You write a template, deploy it, it works, and you never look at it again.
377
00:14:37,440 --> 00:14:39,000
Six months later, something breaks.
378
00:14:39,000 --> 00:14:42,040
You open the file and have no idea what half of it does.
379
00:14:42,040 --> 00:14:44,520
That parameter called Param1, no idea.
380
00:14:44,520 --> 00:14:47,840
It resorts with the cryptic name, no clue.
381
00:14:47,840 --> 00:14:51,600
Write your IAC as if someone else will maintain it six months from now because that someone
382
00:14:51,600 --> 00:14:54,720
else is probably you and you will have forgotten everything.
383
00:14:54,720 --> 00:14:57,880
Add comments, use descriptive names instead of abbreviations.
384
00:14:57,880 --> 00:14:59,800
Keep files small and focused on one thing.
385
00:14:59,800 --> 00:15:03,200
A bicep file that creates a virtual network should be about virtual networks, not about
386
00:15:03,200 --> 00:15:04,360
the whole data center.
387
00:15:04,360 --> 00:15:07,600
Mistake number three is bypassing the pipeline for quick fixes.
388
00:15:07,600 --> 00:15:09,120
The portal is always tempting.
389
00:15:09,120 --> 00:15:10,120
You need to change one setting.
390
00:15:10,120 --> 00:15:14,160
It would take five minutes to edit the template, commit and deploy through the pipeline.
391
00:15:14,160 --> 00:15:18,280
Or you can just log into the portal, click three times and be done in 30 seconds.
392
00:15:18,280 --> 00:15:20,200
That quick change creates drift.
393
00:15:20,200 --> 00:15:22,800
Your code says one thing, reality says another.
394
00:15:22,800 --> 00:15:26,520
Next time you deploy from your template, as you are trying to undo your manual change.
395
00:15:26,520 --> 00:15:31,040
Or worse, it does not notice the drift and your environment slowly diverge until production
396
00:15:31,040 --> 00:15:33,160
behaves completely differently from dev.
397
00:15:33,160 --> 00:15:34,400
The discipline is simple.
398
00:15:34,400 --> 00:15:37,120
Make the change in code, deploy through the pipeline.
399
00:15:37,120 --> 00:15:41,800
Even if it takes five extra minutes, that five minutes saves you hours of debugging later.
400
00:15:41,800 --> 00:15:45,200
One bonus tip, always run the preview command before applying changes.
401
00:15:45,200 --> 00:15:46,840
In bicep, that is what if?
402
00:15:46,840 --> 00:15:49,880
It shows you exactly what will be created, modified or destroyed.
403
00:15:49,880 --> 00:15:50,880
No surprises.
404
00:15:50,880 --> 00:15:52,280
You see the impact before it happens.
405
00:15:52,280 --> 00:15:56,680
That is, IAC in plain English, no jargon, no marketing fluff, just a practical tool that
406
00:15:56,680 --> 00:15:58,960
makes your Azure life easier.
407
00:15:58,960 --> 00:16:00,440
The one thing to try this week.
408
00:16:00,440 --> 00:16:01,440
So here is what we covered.
409
00:16:01,440 --> 00:16:06,800
IAC turns your Azure infrastructure into a version controlled, repeatable, secure blueprint.
410
00:16:06,800 --> 00:16:10,040
One file that describes everything, deployed the same way every time.
411
00:16:10,040 --> 00:16:11,360
Your challenge this week.
412
00:16:11,360 --> 00:16:14,200
One existing Azure resource as an ARM template.
413
00:16:14,200 --> 00:16:15,400
Open it in VS code.
414
00:16:15,400 --> 00:16:16,920
See if you can understand what it does.
415
00:16:16,920 --> 00:16:21,120
That single exercise will teach you more than any explanation I could give.
416
00:16:21,120 --> 00:16:25,000
Next up in this series, we walk through writing your first bicep file step by step.
417
00:16:25,000 --> 00:16:28,760
Subscribe on your favorite podcast platform and share this with a teammate who is still
418
00:16:28,760 --> 00:16:29,800
clicking through the portal.
00:00:00,000 --> 00:00:00,840
Imagine this.
2
00:00:00,840 --> 00:00:03,640
You need a test environment in Azure, nothing fancy.
3
00:00:03,640 --> 00:00:04,760
Just a virtual network,
4
00:00:04,760 --> 00:00:06,840
a couple of virtual machines and a storage account.
5
00:00:06,840 --> 00:00:08,260
So you log into the portal,
6
00:00:08,260 --> 00:00:10,640
find the resource group button and start clicking.
7
00:00:10,640 --> 00:00:12,120
One click to create the group.
8
00:00:12,120 --> 00:00:14,080
A few more to set up the virtual network
9
00:00:14,080 --> 00:00:16,600
then you walk through the VM creation wizard,
10
00:00:16,600 --> 00:00:19,120
pick the region, pick the size, pick the image,
11
00:00:19,120 --> 00:00:21,000
configure the disk, set up networking.
12
00:00:21,000 --> 00:00:22,760
That is maybe 50 clicks right there.
13
00:00:22,760 --> 00:00:24,560
Then you do it again for the second VM,
14
00:00:24,560 --> 00:00:26,160
then you configure the storage account,
15
00:00:26,160 --> 00:00:27,680
then you set up the firewall rules.
16
00:00:27,680 --> 00:00:28,560
And here's the thing.
17
00:00:28,560 --> 00:00:30,000
Every single one of those clicks
18
00:00:30,000 --> 00:00:31,360
is a chance to make a mistake.
19
00:00:31,360 --> 00:00:34,080
Pick the wrong region, your app runs slower than it should,
20
00:00:34,080 --> 00:00:37,360
choose the wrong VM size, you are overpaying from day one.
21
00:00:37,360 --> 00:00:38,600
Forget to close a port,
22
00:00:38,600 --> 00:00:40,760
you just exposed your environment to the internet
23
00:00:40,760 --> 00:00:41,800
without realizing it.
24
00:00:41,800 --> 00:00:43,680
Now multiply that by three environments.
25
00:00:43,680 --> 00:00:45,560
Dev, test, production,
26
00:00:45,560 --> 00:00:47,680
suddenly you are not doing 50 clicks,
27
00:00:47,680 --> 00:00:49,120
you are doing 150.
28
00:00:49,120 --> 00:00:50,320
And somewhere in that process,
29
00:00:50,320 --> 00:00:53,720
production ends up looking nothing like dev.
30
00:00:53,720 --> 00:00:55,320
A setting here, a checkbox there.
31
00:00:55,320 --> 00:00:57,600
Small differences that cause big headaches later.
32
00:00:57,600 --> 00:01:00,080
But what if you could describe your entire Azure setup
33
00:01:00,080 --> 00:01:02,480
in a file instead of clicking through all those screens?
34
00:01:02,480 --> 00:01:04,320
What if you could run that file once
35
00:01:04,320 --> 00:01:06,440
and get the same result every single time?
36
00:01:06,440 --> 00:01:08,040
That is what we are talking about today.
37
00:01:08,040 --> 00:01:09,440
By the end of this episode,
38
00:01:09,440 --> 00:01:13,120
you will understand what infrastructure as code actually is,
39
00:01:13,120 --> 00:01:14,920
why as your teams rely on it
40
00:01:14,920 --> 00:01:17,720
and how you can start using it without being a developer.
41
00:01:17,720 --> 00:01:21,200
What manual provisioning actually costs you?
42
00:01:21,200 --> 00:01:23,360
Let us walk through a typical Azure setup.
43
00:01:23,360 --> 00:01:25,320
You need a resource group inside that,
44
00:01:25,320 --> 00:01:27,800
a virtual network with a couple of subnets,
45
00:01:27,800 --> 00:01:29,160
then a couple of virtual machines,
46
00:01:29,160 --> 00:01:31,520
one for your web server, one for your database
47
00:01:31,520 --> 00:01:33,720
and a storage account for your application data.
48
00:01:33,720 --> 00:01:36,200
In the portal, that is a solid afternoon of clicking.
49
00:01:36,200 --> 00:01:37,200
And here is the problem.
50
00:01:37,200 --> 00:01:39,640
Every single click is a chance for a mistake.
51
00:01:39,640 --> 00:01:40,920
Maybe you pick the wrong region
52
00:01:40,920 --> 00:01:42,680
because the drop down defaults to East US
53
00:01:42,680 --> 00:01:43,920
and you meant West Europe.
54
00:01:43,920 --> 00:01:46,560
Maybe you choose a VM size that is way too expensive
55
00:01:46,560 --> 00:01:47,960
for what you actually need.
56
00:01:47,960 --> 00:01:49,680
Maybe you accidentally leave a management port
57
00:01:49,680 --> 00:01:50,800
open to the internet.
58
00:01:50,800 --> 00:01:51,960
These mistakes happen.
59
00:01:51,960 --> 00:01:53,600
They happen because the portal makes it easy
60
00:01:53,600 --> 00:01:56,000
to click fast and hard to slow down and check your work.
61
00:01:56,000 --> 00:01:57,720
And the real cost is not just the time
62
00:01:57,720 --> 00:01:59,400
you waste fixing those mistakes.
63
00:01:59,400 --> 00:02:01,280
It is the time you spend repeating the same clicks
64
00:02:01,280 --> 00:02:03,520
for dev, test, staging and production
65
00:02:03,520 --> 00:02:04,600
because here is what happens.
66
00:02:04,600 --> 00:02:05,720
You build dev on Monday.
67
00:02:05,720 --> 00:02:07,680
It takes you three hours and it works perfectly.
68
00:02:07,680 --> 00:02:09,600
On Tuesday, you build test.
69
00:02:09,600 --> 00:02:12,480
You are a little faster this time, two and a half hours.
70
00:02:12,480 --> 00:02:13,800
But you forget one setting.
71
00:02:13,800 --> 00:02:16,760
A firewall rule that was open in dev is closed in test.
72
00:02:16,760 --> 00:02:18,040
Your application behaves differently
73
00:02:18,040 --> 00:02:19,680
and you spend an hour debugging it.
74
00:02:19,680 --> 00:02:21,800
By the time you get to production on Friday,
75
00:02:21,800 --> 00:02:24,040
your environment looks nothing like dev.
76
00:02:24,040 --> 00:02:27,080
Different VM sizes, different storage configurations.
77
00:02:27,080 --> 00:02:28,800
A few settings you change because someone said,
78
00:02:28,800 --> 00:02:30,280
just try this real quick.
79
00:02:30,280 --> 00:02:31,720
That is configuration drift.
80
00:02:31,720 --> 00:02:34,840
And it is the natural result of building environments by hand.
81
00:02:34,840 --> 00:02:37,480
The real problem is that you cannot audit a mouse click.
82
00:02:37,480 --> 00:02:38,960
You cannot roll back a mouse click.
83
00:02:38,960 --> 00:02:41,360
If something breaks in production six weeks from now,
84
00:02:41,360 --> 00:02:43,880
you will not remember which checkbox you checked or unchecked.
85
00:02:43,880 --> 00:02:46,920
You will not have a record of what changed between dev and production.
86
00:02:46,920 --> 00:02:50,320
So what if you could describe your entire Azure setup in a file
87
00:02:50,320 --> 00:02:52,000
instead of clicking through screens?
88
00:02:52,000 --> 00:02:54,720
One file that says exactly what your environment should look like.
89
00:02:54,720 --> 00:02:56,560
Run it once, get the same result every time.
90
00:02:56,560 --> 00:02:58,240
Run it again, get the same result again.
91
00:02:58,240 --> 00:02:59,920
No drift, no forgotten settings,
92
00:02:59,920 --> 00:03:03,080
no production environments that look nothing like dev.
93
00:03:03,080 --> 00:03:06,120
Infrastructure as code, the one sentence definition.
94
00:03:06,120 --> 00:03:08,720
Infrastructure as code means describing your infrastructure
95
00:03:08,720 --> 00:03:10,760
in a file that Azure can read and build for you.
96
00:03:10,760 --> 00:03:11,440
That is it.
97
00:03:11,440 --> 00:03:12,400
One sentence.
98
00:03:12,400 --> 00:03:15,520
You write a file, Azure reads it, and your environment appears.
99
00:03:15,520 --> 00:03:16,880
Think of it like an office building.
100
00:03:16,880 --> 00:03:18,400
If you wanted to set up a new office,
101
00:03:18,400 --> 00:03:22,120
you could walk around and tell each worker where to put every desk and every chair.
102
00:03:22,120 --> 00:03:23,520
That is the manual approach.
103
00:03:23,520 --> 00:03:27,480
It works, but it is slow and everyone will end up with a slightly different arrangement.
104
00:03:27,480 --> 00:03:28,920
Or you could hand them a blueprint.
105
00:03:28,920 --> 00:03:31,480
One piece of paper that says exactly where everything goes.
106
00:03:31,480 --> 00:03:34,720
Every room is identical because everyone followed the same plan.
107
00:03:34,720 --> 00:03:36,520
Your ISE file is that blueprint.
108
00:03:36,520 --> 00:03:40,000
It is a single source of truth for your entire Azure environment.
109
00:03:40,000 --> 00:03:41,520
Everything your environment needs,
110
00:03:41,520 --> 00:03:43,840
the resource groups, the virtual networks, the VMs,
111
00:03:43,840 --> 00:03:47,800
the storage accounts, the firewall rules, it is all in that one file.
112
00:03:47,800 --> 00:03:49,840
Now there is an important distinction here.
113
00:03:49,840 --> 00:03:52,280
IAC uses what is called a declarative approach.
114
00:03:52,280 --> 00:03:54,920
That is a fancy way of saying you tell Azure what you want,
115
00:03:54,920 --> 00:03:57,280
not how to build it, step by step.
116
00:03:57,280 --> 00:03:59,120
You do not say create a resource group,
117
00:03:59,120 --> 00:04:01,160
then create a virtual network inside it,
118
00:04:01,160 --> 00:04:03,360
then create a subnet inside that.
119
00:04:03,360 --> 00:04:07,200
You say, I want a resource group with a virtual network that has a subnet.
120
00:04:07,200 --> 00:04:08,440
Azure figures out the order.
121
00:04:08,440 --> 00:04:12,080
This is different from the scripts that system administrators have used for years.
122
00:04:12,080 --> 00:04:13,320
Scripts are imperative.
123
00:04:13,320 --> 00:04:16,720
They tell the system exactly what to do, step by step, do this,
124
00:04:16,720 --> 00:04:17,520
then do that,
125
00:04:17,520 --> 00:04:18,520
then do this other thing.
126
00:04:18,520 --> 00:04:20,720
And if one step fails, the whole thing breaks.
127
00:04:20,720 --> 00:04:22,200
IAC is the opposite.
128
00:04:22,200 --> 00:04:25,640
You describe the end state and the system figures out how to get there.
129
00:04:25,640 --> 00:04:27,080
Here is a concrete example.
130
00:04:27,080 --> 00:04:31,160
Instead of typing 50 separate CLI commands to create a virtual machine,
131
00:04:31,160 --> 00:04:32,160
you write something like,
132
00:04:32,160 --> 00:04:35,000
I need a virtual machine with eight gigabytes of RAM,
133
00:04:35,000 --> 00:04:36,920
running Ubuntu 22.04,
134
00:04:36,920 --> 00:04:40,360
connected to this virtual network with this storage account attached.
135
00:04:40,360 --> 00:04:42,840
That is it, one description instead of 100 commands.
136
00:04:42,840 --> 00:04:46,840
And this matters for Azure specifically because the portal makes it so easy to start.
137
00:04:46,840 --> 00:04:50,280
You can have a virtual machine running in 10 minutes with a few clicks.
138
00:04:50,280 --> 00:04:53,680
But the portal does not scale when you need 10 environments instead of one,
139
00:04:53,680 --> 00:04:55,520
the portal becomes a liability.
140
00:04:55,520 --> 00:04:57,520
IAC is how you break out of that trap.
141
00:04:57,520 --> 00:04:58,560
So that sounds useful, right?
142
00:04:58,560 --> 00:05:02,760
But what tools does Microsoft actually give you to write these blueprint files?
143
00:05:02,760 --> 00:05:06,320
The Azure IAC toolkit, ARM, bicep, and the elephant in the room.
144
00:05:06,320 --> 00:05:10,200
So what tools does Microsoft actually give you to write these blueprint files?
145
00:05:10,200 --> 00:05:12,200
The original one is called ARM templates.
146
00:05:12,200 --> 00:05:14,280
ARM stands for Azure Resource Manager,
147
00:05:14,280 --> 00:05:16,520
and these templates have been around since the beginning.
148
00:05:16,520 --> 00:05:21,640
They are written in JSON, which is a data format that looks like a configuration file from 2015.
149
00:05:21,640 --> 00:05:24,640
Lots of curly braces, lots of brackets, lots of indentation.
150
00:05:24,640 --> 00:05:27,160
If you have ever looked at a JSON file, you know what I mean.
151
00:05:27,160 --> 00:05:29,960
It is functional, but it is not pleasant to read.
152
00:05:29,960 --> 00:05:33,280
ARM templates are still widely used, especially in enterprise environments.
153
00:05:33,280 --> 00:05:36,720
Big companies have invested years into building their template libraries.
154
00:05:36,720 --> 00:05:38,800
And they are not about to throw that work away.
155
00:05:38,800 --> 00:05:43,440
But if you are a beginner looking at an ARM template for the first time can be intimidating.
156
00:05:43,440 --> 00:05:45,400
It is verbose, it is easy to break.
157
00:05:45,400 --> 00:05:47,320
One missing comma and the whole thing fails.
158
00:05:47,320 --> 00:05:48,880
Writing one by hand is painful.
159
00:05:48,880 --> 00:05:50,800
Microsoft recognized this problem.
160
00:05:50,800 --> 00:05:52,160
So they built bicep.
161
00:05:52,160 --> 00:05:55,880
bicep is Microsoft's answer to ARM templates are too complicated.
162
00:05:55,880 --> 00:05:59,480
It is a newer language that compiles down to ARM templates behind the scenes.
163
00:05:59,480 --> 00:06:00,960
But the syntax is much cleaner.
164
00:06:00,960 --> 00:06:02,320
It looks like actual code.
165
00:06:02,320 --> 00:06:05,320
You write something like resource myvm, Microsoft.
166
00:06:05,320 --> 00:06:08,880
Compute virtual machines at 223.0301.
167
00:06:08,880 --> 00:06:09,680
L.O.
168
00:06:09,680 --> 00:06:11,960
Instead of pages of nested JSON.
169
00:06:11,960 --> 00:06:13,840
It is designed for humans first.
170
00:06:13,840 --> 00:06:16,920
Now there is another option you will hear about Terraform.
171
00:06:16,920 --> 00:06:20,760
Terraform is a tool from a company called Hashikorp and it works with Azure and other clouds.
172
00:06:20,760 --> 00:06:26,080
If you need to manage infrastructure across AWS, Google Cloud and Azure all at once, Terraform
173
00:06:26,080 --> 00:06:27,080
is your best bet.
174
00:06:27,080 --> 00:06:28,160
It is more portable.
175
00:06:28,160 --> 00:06:30,240
But that portability comes with a cost.
176
00:06:30,240 --> 00:06:32,680
Terraform adds a layer of abstraction between you and Azure.
177
00:06:32,680 --> 00:06:37,440
You have to learn Terraform's own language, HCl, on top of understanding Azure itself.
178
00:06:37,440 --> 00:06:40,080
It is powerful but it introduces its own complexity.
179
00:06:40,080 --> 00:06:41,640
So which one should the beginner pick?
180
00:06:41,640 --> 00:06:43,880
If you are a Zua only, start with bicep.
181
00:06:43,880 --> 00:06:44,880
The reason is simple.
182
00:06:44,880 --> 00:06:45,880
Native integration.
183
00:06:45,880 --> 00:06:48,120
bicep is built by Microsoft specifically for Azure.
184
00:06:48,120 --> 00:06:49,720
It has fewer moving parts.
185
00:06:49,720 --> 00:06:51,480
It gets Microsoft's full support.
186
00:06:51,480 --> 00:06:55,120
And because it compiles down to ARM templates, you are not locked into anything.
187
00:06:55,120 --> 00:06:58,320
You can always switch to raw ARM templates later if you need to.
188
00:06:58,320 --> 00:07:02,160
bicep is the path of least resistance for someone who just wants to get started.
189
00:07:02,160 --> 00:07:04,120
Here is how these tools work in practice.
190
00:07:04,120 --> 00:07:05,120
You write a file.
191
00:07:05,120 --> 00:07:07,560
A bicep file, an ARM template, whatever you choose.
192
00:07:07,560 --> 00:07:08,920
Then you run a command.
193
00:07:08,920 --> 00:07:12,280
A bicep that command is as deployment group create.
194
00:07:12,280 --> 00:07:13,880
Azure reads your file.
195
00:07:13,880 --> 00:07:17,440
Compares it to what already exists and builds whatever is missing or changes whatever is
196
00:07:17,440 --> 00:07:18,440
different.
197
00:07:18,440 --> 00:07:20,520
You do not have to tell Azure what order to do things in.
198
00:07:20,520 --> 00:07:22,080
It figures that out on its own.
199
00:07:22,080 --> 00:07:23,720
And here is where it gets really interesting.
200
00:07:23,720 --> 00:07:26,160
You can hook this into a CICD pipeline.
201
00:07:26,160 --> 00:07:28,120
Continuous integration, continuous deployment.
202
00:07:28,120 --> 00:07:32,160
That means every time you push a change to your code repository, Azure automatically runs
203
00:07:32,160 --> 00:07:34,640
your IAC file and updates your infrastructure.
204
00:07:34,640 --> 00:07:37,280
No manual steps, no one logging into the portal.
205
00:07:37,280 --> 00:07:40,160
That code changes flowing into production automatically.
206
00:07:40,160 --> 00:07:42,520
So you have a file that describes your infrastructure.
207
00:07:42,520 --> 00:07:44,440
You can run it and get a consistent result.
208
00:07:44,440 --> 00:07:46,640
You can even automate the whole thing with a pipeline.
209
00:07:46,640 --> 00:07:48,040
But what does that actually unlock?
210
00:07:48,040 --> 00:07:50,080
That is where things get really powerful.
211
00:07:50,080 --> 00:07:53,080
What version control does for your Azure environment?
212
00:07:53,080 --> 00:07:55,160
Here is the thing people do not talk about enough.
213
00:07:55,160 --> 00:07:57,920
The real superpower of IAC is not the template format itself.
214
00:07:57,920 --> 00:08:00,320
It is not bicep versus ARM versus Terraform.
215
00:08:00,320 --> 00:08:02,080
The real superpower is version control.
216
00:08:02,080 --> 00:08:06,600
When you store your IAC files in a repository like GitHub or Azure Repos, every single
217
00:08:06,600 --> 00:08:08,240
change becomes trackable.
218
00:08:08,240 --> 00:08:09,240
Who changed what?
219
00:08:09,240 --> 00:08:10,240
When they changed it?
220
00:08:10,240 --> 00:08:11,240
Why they changed it?
221
00:08:11,240 --> 00:08:15,040
You get a complete history of every modification to your infrastructure going back to day
222
00:08:15,040 --> 00:08:16,040
one.
223
00:08:16,040 --> 00:08:17,040
And that means you can roll back.
224
00:08:17,040 --> 00:08:20,120
If a deployment breaks something, you do not have to guess what went wrong.
225
00:08:20,120 --> 00:08:23,720
You do not have to dig through portal audit logs hoping to find the answer.
226
00:08:23,720 --> 00:08:27,160
You just revert to the last working version of your IAC file and redeploy.
227
00:08:27,160 --> 00:08:28,520
The problem disappears.
228
00:08:28,520 --> 00:08:31,440
That is something you simply cannot do with mouse clicks.
229
00:08:31,440 --> 00:08:33,920
It also means your environments stay consistent.
230
00:08:33,920 --> 00:08:36,720
You have tests and production all come from the same files.
231
00:08:36,720 --> 00:08:40,680
Not similar files, not files that started the same but drifted apart over time, the same
232
00:08:40,680 --> 00:08:41,680
files.
233
00:08:41,680 --> 00:08:43,040
You deploy dev from your main branch.
234
00:08:43,040 --> 00:08:47,080
When you are ready for test, you deploy the same files to the test subscription.
235
00:08:47,080 --> 00:08:50,280
When you are ready for production, you deploy the same files again.
236
00:08:50,280 --> 00:08:54,400
Every environment is identical because every environment was built from the same blueprint.
237
00:08:54,400 --> 00:08:58,880
And because these files live in a repository, you can do code reviews for infrastructure.
238
00:08:58,880 --> 00:09:03,280
Before anyone deploys a change, another team member has to look at it and approve it.
239
00:09:03,280 --> 00:09:06,120
It catches mistakes before they ever reach your environment.
240
00:09:06,120 --> 00:09:09,560
It is the same process software developers use for application code.
241
00:09:09,560 --> 00:09:10,880
Apply to your Azure setup.
242
00:09:10,880 --> 00:09:12,240
Here is a real world example.
243
00:09:12,240 --> 00:09:15,160
Someone on your team accidentally opens a storage account to the public.
244
00:09:15,160 --> 00:09:18,120
Without IAC, you might not notice until the bill arrives.
245
00:09:18,120 --> 00:09:20,280
Or until someone tells you your data is exposed.
246
00:09:20,280 --> 00:09:22,680
With IAC, that change is visible in the repository.
247
00:09:22,680 --> 00:09:24,280
It goes through code review.
248
00:09:24,280 --> 00:09:27,560
Someone spots it and says, "Hey, that storage account should not be public."
249
00:09:27,560 --> 00:09:30,040
The change gets blocked before it ever reaches production.
250
00:09:30,040 --> 00:09:32,680
And if it somehow slips through, you can roll it back in seconds.
251
00:09:32,680 --> 00:09:34,680
You can even use branching strategies.
252
00:09:34,680 --> 00:09:36,520
Want to experiment with a new configuration?
253
00:09:36,520 --> 00:09:40,480
Create a separate branch, make your changes, deploy to a test environment, see if it works.
254
00:09:40,480 --> 00:09:42,120
If it does merge back to the main branch.
255
00:09:42,120 --> 00:09:45,040
If it does not, delete the branch and try something else.
256
00:09:45,040 --> 00:09:48,960
Your production environment never gets touched until you are confident that change is safe.
257
00:09:48,960 --> 00:09:50,160
Consistency is great.
258
00:09:50,160 --> 00:09:53,040
But IAC also makes your Azure setup more secure.
259
00:09:53,040 --> 00:09:57,000
And that matters whether you have one person managing everything or a whole team.
260
00:09:57,000 --> 00:09:59,520
Security by design, not by accident.
261
00:09:59,520 --> 00:10:01,800
Here is something that surprises a lot of people.
262
00:10:01,800 --> 00:10:04,880
When you use IAC, security is not something you add later.
263
00:10:04,880 --> 00:10:07,200
It is baked into the template from the start.
264
00:10:07,200 --> 00:10:10,640
Instead of remembering to enable encryption on every new storage account, it is already in
265
00:10:10,640 --> 00:10:11,640
your file.
266
00:10:11,640 --> 00:10:15,200
Instead of hoping someone configured the firewall rules correctly, the rules are written
267
00:10:15,200 --> 00:10:17,320
down and enforced every single time.
268
00:10:17,320 --> 00:10:19,560
This idea has a name, policy as code.
269
00:10:19,560 --> 00:10:22,640
You encode your security rules directly into your deployment pipeline.
270
00:10:22,640 --> 00:10:27,040
So every time someone tries to deploy a storage account, the pipeline checks that HTTPS
271
00:10:27,040 --> 00:10:30,840
is enabled, that encryption is turned on, that public access is blocked.
272
00:10:30,840 --> 00:10:33,880
If the template does not meet those rules, the deployment fails.
273
00:10:33,880 --> 00:10:36,880
The insecure configuration never reaches your environment.
274
00:10:36,880 --> 00:10:38,520
Think about what that replaces.
275
00:10:38,520 --> 00:10:40,000
Dozens of manual checks.
276
00:10:40,000 --> 00:10:42,320
Someone remembering to tick the right checkbox.
277
00:10:42,320 --> 00:10:44,320
Someone else auditing those checkboxes later.
278
00:10:44,320 --> 00:10:45,680
All of that goes away.
279
00:10:45,680 --> 00:10:51,240
One secure template, one set of policies and every deployment automatically meets your security
280
00:10:51,240 --> 00:10:52,240
baseline.
281
00:10:52,240 --> 00:10:54,680
But here is where it gets really interesting, disaster recovery.
282
00:10:54,680 --> 00:10:57,880
The file that describes your infrastructure can rebuild it anywhere.
283
00:10:57,880 --> 00:11:01,600
If an attacker compromises your environment, you do not have to spend days trying to figure
284
00:11:01,600 --> 00:11:03,480
out what they changed and how to fix it.
285
00:11:03,480 --> 00:11:04,480
You tear it down.
286
00:11:04,480 --> 00:11:06,120
You redeploy from your IAC file.
287
00:11:06,120 --> 00:11:08,080
Your clean environment is back in minutes.
288
00:11:08,080 --> 00:11:10,920
That is not possible when your infrastructure was built by hand.
289
00:11:10,920 --> 00:11:13,720
And because everything is in version control, you have an audit trail.
290
00:11:13,720 --> 00:11:15,760
Every change to your infrastructure is recorded.
291
00:11:15,760 --> 00:11:16,760
Who made it?
292
00:11:16,760 --> 00:11:17,760
When?
293
00:11:17,760 --> 00:11:18,760
Why?
294
00:11:18,760 --> 00:11:20,520
That is compliance evidence without anyone having to fill out a spreadsheet.
295
00:11:20,520 --> 00:11:24,760
For small teams, without dedicated security staff, this is a force multiplier.
296
00:11:24,760 --> 00:11:28,840
You get enterprise grade security practices without hiring an enterprise grade security team.
297
00:11:28,840 --> 00:11:30,280
This all sounds great on paper.
298
00:11:30,280 --> 00:11:32,160
But getting started can feel overwhelming.
299
00:11:32,160 --> 00:11:35,040
Let me give you a realistic path forward.
300
00:11:35,040 --> 00:11:37,080
How to start without breaking anything?
301
00:11:37,080 --> 00:11:38,080
Rule one.
302
00:11:38,080 --> 00:11:39,080
Do not start with production.
303
00:11:39,080 --> 00:11:40,760
I cannot emphasize this enough.
304
00:11:40,760 --> 00:11:43,120
IAC is powerful, but it is also new.
305
00:11:43,120 --> 00:11:44,240
You will make mistakes.
306
00:11:44,240 --> 00:11:45,240
Make them somewhere.
307
00:11:45,240 --> 00:11:46,240
It does not matter.
308
00:11:46,240 --> 00:11:49,640
Pick one small piece of your Azure environment, a resource group with a single virtual
309
00:11:49,640 --> 00:11:51,600
machine or a storage account.
310
00:11:51,600 --> 00:11:53,560
Something simple that you already have running.
311
00:11:53,560 --> 00:11:54,560
Something you know works.
312
00:11:54,560 --> 00:11:55,560
Here is the trick.
313
00:11:55,560 --> 00:11:59,480
The Azure portal can actually generate arm templates from your existing resources.
314
00:11:59,480 --> 00:12:02,480
You go to your resource group, click export template.
315
00:12:02,480 --> 00:12:05,840
An Azure gives you the JSON file that describes everything in that group.
316
00:12:05,840 --> 00:12:07,000
It is not perfect.
317
00:12:07,000 --> 00:12:09,920
The exported template often includes things you do not need.
318
00:12:09,920 --> 00:12:11,320
But it is a starting point.
319
00:12:11,320 --> 00:12:14,440
You take something you build manually and convert it to code.
320
00:12:14,440 --> 00:12:17,840
That is the reverse engineer approach and it is the fastest way to learn.
321
00:12:17,840 --> 00:12:20,000
Start with bicep and the free Azure tools.
322
00:12:20,000 --> 00:12:24,080
Microsoft has a VS Code extension for bicep that gives you syntax highlighting, auto completion
323
00:12:24,080 --> 00:12:26,120
and a visual preview of what you are building.
324
00:12:26,120 --> 00:12:29,680
You can see your virtual network and your subnets rendered as a diagram before you deploy
325
00:12:29,680 --> 00:12:30,680
anything.
326
00:12:30,680 --> 00:12:33,920
That makes it much easier to understand what your code actually does.
327
00:12:33,920 --> 00:12:35,880
Use a separate subscription for testing.
328
00:12:35,880 --> 00:12:39,160
Most Azure subscriptions have spending limits and free credits.
329
00:12:39,160 --> 00:12:40,640
Create a test subscription.
330
00:12:40,640 --> 00:12:44,000
Deploy your IAC there, break things, fix them, learn.
331
00:12:44,000 --> 00:12:47,440
When you are confident, move to a non-production subscription.
332
00:12:47,440 --> 00:12:49,040
Production comes last.
333
00:12:49,040 --> 00:12:51,000
Here is the part that might surprise you.
334
00:12:51,000 --> 00:12:53,480
You do not need to be a software engineer to do this.
335
00:12:53,480 --> 00:12:55,240
The citizen developer angle is real.
336
00:12:55,240 --> 00:12:59,640
Bicep was designed for people who manage Azure infrastructure not for professional programmers.
337
00:12:59,640 --> 00:13:00,640
It is readable.
338
00:13:00,640 --> 00:13:03,080
It has less ceremony than traditional programming languages.
339
00:13:03,080 --> 00:13:04,840
It is focused on Azure and nothing else.
340
00:13:04,840 --> 00:13:08,880
If you can understand what a virtual machine is, you can learn to describe one in bicep.
341
00:13:08,880 --> 00:13:10,600
Your first practical project?
342
00:13:10,600 --> 00:13:13,040
Automate your dev environment, tear down and rebuild.
343
00:13:13,040 --> 00:13:15,560
Write a bicep file that creates your dev setup.
344
00:13:15,560 --> 00:13:18,360
Deploy it, use it, then tear it down and deploy it again.
345
00:13:18,360 --> 00:13:21,040
Do that a few times until the process feels routine.
346
00:13:21,040 --> 00:13:24,840
And exercise alone will teach you more about IAC than any tutorial.
347
00:13:24,840 --> 00:13:27,200
A few pieces of common beginner advice.
348
00:13:27,200 --> 00:13:28,880
Commit early and commit often.
349
00:13:28,880 --> 00:13:32,360
Every time you get a piece of your template working, save it to your repository that gives
350
00:13:32,360 --> 00:13:34,240
you checkpoints you can go back to.
351
00:13:34,240 --> 00:13:36,960
And always run the preview command before deploying.
352
00:13:36,960 --> 00:13:38,560
In bicep that is what if.
353
00:13:38,560 --> 00:13:41,680
It shows you exactly what will change before anything actually changes.
354
00:13:41,680 --> 00:13:43,200
No surprises.
355
00:13:43,200 --> 00:13:47,120
Even with the best intentions, there are a few traps beginners fall into.
356
00:13:47,120 --> 00:13:49,840
Let me save you some late night debugging sessions.
357
00:13:49,840 --> 00:13:51,400
Three mistakes that will haunt you.
358
00:13:51,400 --> 00:13:52,800
And how to avoid them.
359
00:13:52,800 --> 00:13:54,600
Mistake number one is the classic.
360
00:13:54,600 --> 00:13:55,600
Hard coding secrets.
361
00:13:55,600 --> 00:13:56,600
You are in a hurry.
362
00:13:56,600 --> 00:13:59,800
You need to get a template working so you drop the database password right there in the
363
00:13:59,800 --> 00:14:00,800
file.
364
00:14:00,800 --> 00:14:01,800
It works.
365
00:14:01,800 --> 00:14:02,800
You move on.
366
00:14:02,800 --> 00:14:06,080
And now your password is sitting in your IAC repository for anyone with access to see.
367
00:14:06,080 --> 00:14:07,160
Obviously in hindsight, right?
368
00:14:07,160 --> 00:14:10,760
But it is incredibly easy to do when you are focused on getting something to work.
369
00:14:10,760 --> 00:14:12,560
The solution is Azure Key Vault.
370
00:14:12,560 --> 00:14:17,640
Both bicep and ARM templates can pull secrets directly from Key Vault at deployment time.
371
00:14:17,640 --> 00:14:21,880
Your file says get the password from this vault instead of containing the actual password.
372
00:14:21,880 --> 00:14:24,000
The secret never touches your repository.
373
00:14:24,000 --> 00:14:27,800
Never put passwords, connection strings or API keys in your IAC files.
374
00:14:27,800 --> 00:14:30,560
Use Key Vault every single time.
375
00:14:30,560 --> 00:14:33,840
Mistake number two is treating IAC like a one time script.
376
00:14:33,840 --> 00:14:37,440
You write a template, deploy it, it works, and you never look at it again.
377
00:14:37,440 --> 00:14:39,000
Six months later, something breaks.
378
00:14:39,000 --> 00:14:42,040
You open the file and have no idea what half of it does.
379
00:14:42,040 --> 00:14:44,520
That parameter called Param1, no idea.
380
00:14:44,520 --> 00:14:47,840
It resorts with the cryptic name, no clue.
381
00:14:47,840 --> 00:14:51,600
Write your IAC as if someone else will maintain it six months from now because that someone
382
00:14:51,600 --> 00:14:54,720
else is probably you and you will have forgotten everything.
383
00:14:54,720 --> 00:14:57,880
Add comments, use descriptive names instead of abbreviations.
384
00:14:57,880 --> 00:14:59,800
Keep files small and focused on one thing.
385
00:14:59,800 --> 00:15:03,200
A bicep file that creates a virtual network should be about virtual networks, not about
386
00:15:03,200 --> 00:15:04,360
the whole data center.
387
00:15:04,360 --> 00:15:07,600
Mistake number three is bypassing the pipeline for quick fixes.
388
00:15:07,600 --> 00:15:09,120
The portal is always tempting.
389
00:15:09,120 --> 00:15:10,120
You need to change one setting.
390
00:15:10,120 --> 00:15:14,160
It would take five minutes to edit the template, commit and deploy through the pipeline.
391
00:15:14,160 --> 00:15:18,280
Or you can just log into the portal, click three times and be done in 30 seconds.
392
00:15:18,280 --> 00:15:20,200
That quick change creates drift.
393
00:15:20,200 --> 00:15:22,800
Your code says one thing, reality says another.
394
00:15:22,800 --> 00:15:26,520
Next time you deploy from your template, as you are trying to undo your manual change.
395
00:15:26,520 --> 00:15:31,040
Or worse, it does not notice the drift and your environment slowly diverge until production
396
00:15:31,040 --> 00:15:33,160
behaves completely differently from dev.
397
00:15:33,160 --> 00:15:34,400
The discipline is simple.
398
00:15:34,400 --> 00:15:37,120
Make the change in code, deploy through the pipeline.
399
00:15:37,120 --> 00:15:41,800
Even if it takes five extra minutes, that five minutes saves you hours of debugging later.
400
00:15:41,800 --> 00:15:45,200
One bonus tip, always run the preview command before applying changes.
401
00:15:45,200 --> 00:15:46,840
In bicep, that is what if?
402
00:15:46,840 --> 00:15:49,880
It shows you exactly what will be created, modified or destroyed.
403
00:15:49,880 --> 00:15:50,880
No surprises.
404
00:15:50,880 --> 00:15:52,280
You see the impact before it happens.
405
00:15:52,280 --> 00:15:56,680
That is, IAC in plain English, no jargon, no marketing fluff, just a practical tool that
406
00:15:56,680 --> 00:15:58,960
makes your Azure life easier.
407
00:15:58,960 --> 00:16:00,440
The one thing to try this week.
408
00:16:00,440 --> 00:16:01,440
So here is what we covered.
409
00:16:01,440 --> 00:16:06,800
IAC turns your Azure infrastructure into a version controlled, repeatable, secure blueprint.
410
00:16:06,800 --> 00:16:10,040
One file that describes everything, deployed the same way every time.
411
00:16:10,040 --> 00:16:11,360
Your challenge this week.
412
00:16:11,360 --> 00:16:14,200
One existing Azure resource as an ARM template.
413
00:16:14,200 --> 00:16:15,400
Open it in VS code.
414
00:16:15,400 --> 00:16:16,920
See if you can understand what it does.
415
00:16:16,920 --> 00:16:21,120
That single exercise will teach you more than any explanation I could give.
416
00:16:21,120 --> 00:16:25,000
Next up in this series, we walk through writing your first bicep file step by step.
417
00:16:25,000 --> 00:16:28,760
Subscribe on your favorite podcast platform and share this with a teammate who is still
418
00:16:28,760 --> 00:16:29,800
clicking through the portal.
