Azure Policy - Simply Explained

1
00:00:00,000 --> 00:00:04,000
Today we're talking about an Azure feature you've probably heard about but might not fully understand.

2
00:00:04,000 --> 00:00:07,800
Azure Policy is one of the most powerful governance tools in the whole platform

3
00:00:07,800 --> 00:00:11,800
yet most people either ignore it or think it's only for IT administrators.

4
00:00:11,800 --> 00:00:15,200
By the end of this episode, you'll know what Azure Policy actually is,

5
00:00:15,200 --> 00:00:17,400
how it works like an invisible rulebook,

6
00:00:17,400 --> 00:00:21,800
and why it's essential for keeping your Azure environment safe and under control.

7
00:00:21,800 --> 00:00:25,200
We'll break it down into clear building blocks starting with the problem it solves,

8
00:00:25,200 --> 00:00:27,500
grab your coffee, and let's dive in.

9
00:00:27,500 --> 00:00:28,500
The problem.

10
00:00:28,500 --> 00:00:30,300
Why Cloud needs guardrails?

11
00:00:30,300 --> 00:00:32,400
Think about the old way of doing things.

12
00:00:32,400 --> 00:00:34,600
On premises, when you needed a server,

13
00:00:34,600 --> 00:00:37,200
you'd submit a request to the operations team.

14
00:00:37,200 --> 00:00:40,700
They check the rules, company policies, security standards,

15
00:00:40,700 --> 00:00:42,700
maybe some regulatory requirements,

16
00:00:42,700 --> 00:00:44,200
and then provision the server for you.

17
00:00:44,200 --> 00:00:46,900
A human gatekeeper stood between you and the infrastructure.

18
00:00:46,900 --> 00:00:51,000
That person knew the rules and made sure nothing slipped through the cloud flips that completely.

19
00:00:51,000 --> 00:00:54,300
Now the app owner has direct access with no human in the middle.

20
00:00:54,300 --> 00:00:57,800
Click Create in the Azure portal and it happens instantly.

21
00:00:57,800 --> 00:01:02,600
You can also use the command line, an API, or infrastructure as code tools like Terraform.

22
00:01:02,600 --> 00:01:05,700
The point is nobody checks your work before the resource gets created.

23
00:01:05,700 --> 00:01:07,000
And that's where the problem starts.

24
00:01:07,000 --> 00:01:08,800
Most app owners don't know all the rules.

25
00:01:08,800 --> 00:01:12,800
Maybe they don't realize that company policy requires all data to stay in Europe.

26
00:01:12,800 --> 00:01:15,100
All that storage accounts must block public access.

27
00:01:15,100 --> 00:01:18,600
All that certain VM sizes are expensive and should only be used in production.

28
00:01:18,600 --> 00:01:21,800
So they go ahead and create resources and sometimes mistakes happen.

29
00:01:21,800 --> 00:01:25,500
A virtual machine gets deployed with a public IP and open ports to the internet.

30
00:01:25,500 --> 00:01:29,900
A storage account gets created with public blob access, exposing sensitive data.

31
00:01:29,900 --> 00:01:34,200
Someone spins up an expensive GPU instance for a quick test and forgets to delete it.

32
00:01:34,200 --> 00:01:35,800
These things happen all the time.

33
00:01:35,800 --> 00:01:39,300
What we need is an automatic enforcement system that works every time.

34
00:01:39,300 --> 00:01:41,700
No matter who creates the resource or how they do it,

35
00:01:41,700 --> 00:01:45,600
whether it's the portal, the CLI, an API call or a Terraform deployment,

36
00:01:45,600 --> 00:01:47,800
the rules should be checked automatically.

37
00:01:47,800 --> 00:01:50,800
And that's exactly what Azure Policy was built to provide.

38
00:01:50,800 --> 00:01:53,200
What is Azure Policy, the invisible rulebook?

39
00:01:53,200 --> 00:01:55,600
So what is Azure Policy? Here's the simplest definition.

40
00:01:55,600 --> 00:01:59,400
Azure Policy is a service that lets you define rules for your Azure resources

41
00:01:59,400 --> 00:02:00,900
and automatically enforces them.

42
00:02:00,900 --> 00:02:02,800
Think of it like the rulebook for a board game.

43
00:02:02,800 --> 00:02:06,900
The game has lots of possible moves, but the rulebook says which ones are actually allowed.

44
00:02:06,900 --> 00:02:09,200
You can't just move your piece anywhere you want.

45
00:02:09,200 --> 00:02:11,500
The rules tell you what's legal and what isn't.

46
00:02:11,500 --> 00:02:12,800
Now here's a critical distinction.

47
00:02:12,800 --> 00:02:16,000
Azure Policy is not the same as a role-based access control or R-back.

48
00:02:16,000 --> 00:02:17,900
R-back controls who can do something.

49
00:02:17,900 --> 00:02:21,700
It answers the question, who is allowed to create resources in this subscription?

50
00:02:21,700 --> 00:02:23,800
Azure Policy controls what can be done?

51
00:02:23,800 --> 00:02:26,100
Or more precisely what configurations are allowed.

52
00:02:26,100 --> 00:02:28,600
It answers the question, what kind of resources can be created?

53
00:02:28,600 --> 00:02:30,300
And how should they be configured?

54
00:02:30,300 --> 00:02:32,900
So R-back says, "Mirko can create storage accounts."

55
00:02:32,900 --> 00:02:36,800
And Azure Policy says, "Storage accounts must have HTTPS enabled."

56
00:02:36,800 --> 00:02:38,300
Two different things and you need both.

57
00:02:38,300 --> 00:02:39,200
Here's the key thing.

58
00:02:39,200 --> 00:02:42,000
Azure Policy is always on and it's always enforced.

59
00:02:42,000 --> 00:02:46,400
Every single request to create, update or delete a resource passes through Azure Policy

60
00:02:46,400 --> 00:02:48,100
and there is no way to bypass it.

61
00:02:48,100 --> 00:02:50,300
It sits between you and Azure Resource Manager.

62
00:02:50,300 --> 00:02:51,800
The control plane of Azure.

63
00:02:51,800 --> 00:02:53,400
Think of it as an automatic filter.

64
00:02:53,400 --> 00:02:56,700
Every request goes through this filter and if it doesn't match the rules,

65
00:02:56,700 --> 00:03:00,100
the request gets blocked or flagged and it doesn't just work for new resources.

66
00:03:00,100 --> 00:03:03,100
Azure Policy also evaluates existing resources

67
00:03:03,100 --> 00:03:05,500
so it catches configuration drift over time.

68
00:03:05,500 --> 00:03:09,000
If someone changes a setting on a resource that you've already deployed

69
00:03:09,000 --> 00:03:12,000
and that change violates a policy, Azure Policy will flag it.

70
00:03:12,000 --> 00:03:13,700
So how do you actually write these rules?

71
00:03:13,700 --> 00:03:15,600
That's where policy definitions come in.

72
00:03:15,600 --> 00:03:18,500
Policy definitions, writing the rules.

73
00:03:18,500 --> 00:03:20,300
So how do you actually write these rules?

74
00:03:20,300 --> 00:03:21,900
That's where policy definitions come in.

75
00:03:21,900 --> 00:03:25,500
A policy definition is the rule itself and it's written as a JSON document.

76
00:03:25,500 --> 00:03:28,700
JSON might sound technical but the structure is actually quite simple.

77
00:03:28,700 --> 00:03:30,200
It follows a basic pattern.

78
00:03:30,200 --> 00:03:33,200
If this condition is true, then apply this effect.

79
00:03:33,200 --> 00:03:34,600
Let me give you a real example.

80
00:03:34,600 --> 00:03:36,200
There's a built-in policy that says,

81
00:03:36,200 --> 00:03:39,500
"If a storage account doesn't have HTTPS enabled, deny it."

82
00:03:39,500 --> 00:03:40,200
That's it.

83
00:03:40,200 --> 00:03:43,500
When the condition is true, the effect kicks in and blocks the deployment.

84
00:03:43,500 --> 00:03:45,700
Every policy definition has three key parts.

85
00:03:45,700 --> 00:03:47,000
First, the conditions.

86
00:03:47,000 --> 00:03:47,900
That's the if part.

87
00:03:47,900 --> 00:03:48,900
What are you checking for?

88
00:03:48,900 --> 00:03:51,400
The resource type, the location, a specific setting.

89
00:03:51,400 --> 00:03:52,900
Second, the effects.

90
00:03:52,900 --> 00:03:53,900
That's the then part.

91
00:03:53,900 --> 00:03:55,400
What happens when the condition is met?

92
00:03:55,400 --> 00:03:57,400
Do you block the deployment or just flag it?

93
00:03:57,400 --> 00:03:58,900
Third, parameters.

94
00:03:58,900 --> 00:04:01,900
These are the fill-in-the-blanks that make the policy reusable.

95
00:04:01,900 --> 00:04:04,200
Parameters are where the real power comes in.

96
00:04:04,200 --> 00:04:08,900
Imagine you want to write a policy that only allows resources in certain regions.

97
00:04:08,900 --> 00:04:12,200
You don't want to write a separate policy for every possible combination of regions.

98
00:04:12,200 --> 00:04:15,200
Instead, you write one definition called "allowed locations."

99
00:04:15,200 --> 00:04:17,700
And you add a parameter for which regions are allowed.

100
00:04:17,700 --> 00:04:19,900
When you assign the policy, you fill in the blank.

101
00:04:19,900 --> 00:04:23,100
Maybe you say "west, Europe, and North Europe" for one subscription.

102
00:04:23,100 --> 00:04:25,100
And "east, US, and West, US for another."

103
00:04:25,100 --> 00:04:26,600
Same definition, different parameters.

104
00:04:26,600 --> 00:04:28,100
That's how you keep things manageable.

105
00:04:28,100 --> 00:04:29,000
Here's the good news.

106
00:04:29,000 --> 00:04:30,900
You don't have to write all of these from scratch.

107
00:04:30,900 --> 00:04:35,500
Microsoft provides hundreds of built-in policy definitions that you can start using immediately.

108
00:04:35,500 --> 00:04:40,500
They cover categories like "computer storage, networking, security center, tagging, cost management, and more."

109
00:04:40,500 --> 00:04:44,700
You can find them in the Azure portal, search for what you need, and assign them right away.

110
00:04:44,700 --> 00:04:46,900
No JSON required if you don't want to write it.

111
00:04:46,900 --> 00:04:49,300
But a definition sitting in a file doesn't do anything.

112
00:04:49,300 --> 00:04:51,100
You have to assign it to make it work.

113
00:04:51,100 --> 00:04:53,600
Policy assignments, putting rules to work.

114
00:04:53,600 --> 00:04:57,400
A policy assignment is where you take your definition and point it at a specific scope.

115
00:04:57,400 --> 00:04:59,700
The scope is just the boundary where that rule applies.

116
00:04:59,700 --> 00:05:02,500
You have three choices from the widest to the tightest.

117
00:05:02,500 --> 00:05:06,200
Assign at the management group level, and it covers a whole set of subscriptions.

118
00:05:06,200 --> 00:05:09,700
Drop it at the subscription level, and it covers everything inside that subscription.

119
00:05:09,700 --> 00:05:14,200
Or assign at the resource group level, and it only covers the resources inside that group.

120
00:05:14,200 --> 00:05:15,500
Now let's talk about inheritance.

121
00:05:15,500 --> 00:05:16,500
This is a key concept.

122
00:05:16,500 --> 00:05:18,900
When you assign a policy at the management group level,

123
00:05:18,900 --> 00:05:23,100
it automatically flows down to every subscription and resource group underneath.

124
00:05:23,100 --> 00:05:24,700
You don't need to assign it again and again.

125
00:05:24,700 --> 00:05:28,700
It's like posting a rule on the main bulletin board at the entrance of an office building.

126
00:05:28,700 --> 00:05:30,600
Everyone who passes through has to follow it.

127
00:05:30,600 --> 00:05:33,100
You wouldn't post the same rule on every floor.

128
00:05:33,100 --> 00:05:34,300
That's wasted effort.

129
00:05:34,300 --> 00:05:35,600
The rule just flows down.

130
00:05:35,600 --> 00:05:37,400
But what happens when you need an exception?

131
00:05:37,400 --> 00:05:39,800
Maybe your company says all data must stay in Europe,

132
00:05:39,800 --> 00:05:43,100
but one project has a legitimate reason to use a data center in Asia.

133
00:05:43,100 --> 00:05:46,300
You don't want to remove the whole policy that would leave everything exposed.

134
00:05:46,300 --> 00:05:47,800
So you create an exemption.

135
00:05:47,800 --> 00:05:51,400
Exemptions let you make carve-outs for specific resources or resource groups

136
00:05:51,400 --> 00:05:53,500
without killing the policy everywhere else.

137
00:05:53,500 --> 00:05:55,200
It's a clean way to handle edge cases.

138
00:05:55,200 --> 00:05:56,700
Here's the practical guidance.

139
00:05:56,700 --> 00:06:01,200
Assign your broad foundational policies at the management group level.

140
00:06:01,200 --> 00:06:04,900
Things like allowed locations or required tags should apply to everything.

141
00:06:04,900 --> 00:06:08,500
Then assign more specific policies at the subscription or resource group level.

142
00:06:08,500 --> 00:06:12,000
Maybe your dev subscription has looser rules than your production subscription.

143
00:06:12,000 --> 00:06:13,000
That's perfectly fine.

144
00:06:13,000 --> 00:06:15,400
The specific policies add on top of the broad ones.

145
00:06:15,400 --> 00:06:18,200
Now let's talk about what actually happens when someone breaks a rule.

146
00:06:18,200 --> 00:06:19,900
That's where effects come in.

147
00:06:19,900 --> 00:06:20,900
Effects.

148
00:06:20,900 --> 00:06:22,600
What happens when rules are broken?

149
00:06:22,600 --> 00:06:24,500
So you've written a rule and assigned it.

150
00:06:24,500 --> 00:06:26,000
What happens when someone breaks it?

151
00:06:26,000 --> 00:06:27,200
That's where effects come in.

152
00:06:27,200 --> 00:06:30,000
Effects are the then part of the policy.

153
00:06:30,000 --> 00:06:33,200
They decide what happens when a resource doesn't match the rule.

154
00:06:33,200 --> 00:06:34,600
There are four main ones you'll see.

155
00:06:34,600 --> 00:06:36,100
First up, deny.

156
00:06:36,100 --> 00:06:38,600
This is the most common effect for critical rules.

157
00:06:38,600 --> 00:06:41,900
When a deny policy is triggered, the deployment is blocked completely.

158
00:06:41,900 --> 00:06:45,200
The user gets a clear error message that says validation failed.

159
00:06:45,200 --> 00:06:47,300
And explains which policy stopped them.

160
00:06:47,300 --> 00:06:49,500
No resources created, no harm done.

161
00:06:49,500 --> 00:06:51,900
Use this for rules that must never be broken.

162
00:06:51,900 --> 00:06:57,600
Like no public blob access on storage accounts or no deployments outside approved regions.

163
00:06:57,600 --> 00:06:58,800
Second, audit.

164
00:06:58,800 --> 00:07:00,100
This one works differently.

165
00:07:00,100 --> 00:07:04,600
The deployment goes through, but the resource is marked as non-compliant in the compliance dashboard.

166
00:07:04,600 --> 00:07:08,600
Audit is incredibly useful when you're not sure how a new rule will affect your environment.

167
00:07:08,600 --> 00:07:11,000
You can see what's happening without breaking anything.

168
00:07:11,000 --> 00:07:14,000
It's like taking a measurement before you enforce a change.

169
00:07:14,000 --> 00:07:15,800
Third, modify and append.

170
00:07:15,800 --> 00:07:19,200
These effects automatically fix the problem instead of blocking it.

171
00:07:19,200 --> 00:07:21,800
Modify changes existing settings during deployment.

172
00:07:21,800 --> 00:07:23,800
Append adds something to an existing field.

173
00:07:23,800 --> 00:07:28,200
For example, you can create a policy that automatically adds a required tag with a default value.

174
00:07:28,200 --> 00:07:31,800
If someone forgets to add a cost center tag, the policy adds it for them,

175
00:07:31,800 --> 00:07:36,000
the deployment goes through and the resource is compliant without extra work.

176
00:07:36,000 --> 00:07:38,000
Fourth, deploy if not exists.

177
00:07:38,000 --> 00:07:40,800
This one handles situations where supporting resources missing.

178
00:07:40,800 --> 00:07:43,800
Say you want diagnostic logging enabled on every storage account.

179
00:07:43,800 --> 00:07:46,600
If someone creates a storage account without diagnostic settings,

180
00:07:46,600 --> 00:07:50,600
deploy if not exists kicks in and deploys the missing configuration automatically.

181
00:07:50,600 --> 00:07:52,600
It's like having a helper that cleans up behind you.

182
00:07:52,600 --> 00:07:53,800
Here's the best practice.

183
00:07:53,800 --> 00:07:54,800
Start with audit.

184
00:07:54,800 --> 00:07:57,000
See what's actually happening in your environment first.

185
00:07:57,000 --> 00:07:59,800
Find out how many resources would be affected by a new rule.

186
00:07:59,800 --> 00:08:00,800
Then move to deny.

187
00:08:00,800 --> 00:08:04,400
Once your confident the rule is correct and won't break legitimate deployments.

188
00:08:04,400 --> 00:08:09,600
Managing one policy is simple, but what if you need 50 of them all related to security or compliance?

189
00:08:09,600 --> 00:08:11,600
That's where initiatives come in.

190
00:08:11,600 --> 00:08:13,600
Initiatives bundling rules together.

191
00:08:13,600 --> 00:08:14,600
So what is an initiative?

192
00:08:14,600 --> 00:08:18,200
Think of it as a collection of policies all grouped around one common goal.

193
00:08:18,200 --> 00:08:21,200
Instead of assigning 50 individual policies one by one,

194
00:08:21,200 --> 00:08:24,400
you assign one single initiative that contains all of them.

195
00:08:24,400 --> 00:08:27,200
It's like a prepacked toolkit for a specific job.

196
00:08:27,200 --> 00:08:29,800
You don't pick up a hammer, a screwdriver and a wrench separately.

197
00:08:29,800 --> 00:08:31,200
You just grab the whole toolkit.

198
00:08:31,200 --> 00:08:32,600
Everything you need is in one place.

199
00:08:32,600 --> 00:08:34,600
The real advantage here is compliance reporting.

200
00:08:34,600 --> 00:08:38,200
When you assign an initiative, you get a single compliance view for the whole group.

201
00:08:38,200 --> 00:08:41,800
You can see at a glance whether your environment meets the overall standard.

202
00:08:41,800 --> 00:08:46,200
And if something is non-compliant, you can drill right into the specific policy that's failing.

203
00:08:46,200 --> 00:08:49,000
It's much cleaner than tracking 50 separate policies.

204
00:08:49,000 --> 00:08:52,800
Microsoft provides built-in initiatives that cover major compliance frameworks.

205
00:08:52,800 --> 00:08:59,800
Things like the Azure Security benchmark, CIS, NIST, PCI DSS, HIPAA, ISO 27001 and more.

206
00:08:59,800 --> 00:09:02,000
These are already created and ready to assign.

207
00:09:02,000 --> 00:09:05,800
You don't have to figure out which policies map to which compliance requirement.

208
00:09:05,800 --> 00:09:07,600
Microsoft has done that work for you.

209
00:09:07,600 --> 00:09:10,400
Some of these initiatives contain hundreds of individual policies.

210
00:09:10,400 --> 00:09:12,600
Imagine trying to assign all of those one by one.

211
00:09:12,600 --> 00:09:14,200
You wouldn't. You'd use the initiative.

212
00:09:14,200 --> 00:09:17,000
You can also create custom initiatives for your own standards.

213
00:09:17,000 --> 00:09:22,400
Maybe you have a production baseline that includes policies for encryption, logging and network security.

214
00:09:22,400 --> 00:09:27,000
Or a cost-control standards initiative that limits VM sizes and requires cost-center tags.

215
00:09:27,000 --> 00:09:28,000
Same idea.

216
00:09:28,000 --> 00:09:31,600
Bundle the policies, assign the bundle and track compliance as a single unit.

217
00:09:31,600 --> 00:09:36,000
Let's make this concrete with real-world examples of how people actually use Azure Policy.

218
00:09:36,000 --> 00:09:37,600
Real-world examples.

219
00:09:37,600 --> 00:09:38,800
Policy in action.

220
00:09:38,800 --> 00:09:40,200
Let's make this real.

221
00:09:40,200 --> 00:09:44,000
Here are five common scenarios where Azure Policy solves actual problems.

222
00:09:44,000 --> 00:09:46,400
First, region restrictions for data compliance.

223
00:09:46,400 --> 00:09:50,800
Imagine your company has a policy that all customer data must stay in Europe.

224
00:09:50,800 --> 00:09:55,200
You can assign the allowed locations built in policy at the root management group level

225
00:09:55,200 --> 00:09:58,400
and only allow EU regions like West Europe and North Europe.

226
00:09:58,400 --> 00:10:02,200
Now, when someone creates a new subscription, it automatically inherits that rule.

227
00:10:02,200 --> 00:10:05,400
They can't deploy resources in the US or Asia even if they try.

228
00:10:05,400 --> 00:10:06,400
The policy blocks it.

229
00:10:06,400 --> 00:10:08,200
No manual checks, no asking for permission.

230
00:10:08,200 --> 00:10:09,600
The rule is just enforced.

231
00:10:09,600 --> 00:10:11,800
Second, tag enforcement for cost allocation.

232
00:10:11,800 --> 00:10:18,000
Your finance team needs to track spending by department, but they can't do that if resources don't have the right tags.

233
00:10:18,000 --> 00:10:23,600
So you create a policy that requires a cost-center tag and an environment tag on every resource.

234
00:10:23,600 --> 00:10:24,800
But here's the smart part.

235
00:10:24,800 --> 00:10:26,200
You use the modify effect.

236
00:10:26,200 --> 00:10:30,000
If someone forgets to add the tag, the policy automatically adds it with a default value.

237
00:10:30,000 --> 00:10:32,800
The deployment goes through and the resource is compliant.

238
00:10:32,800 --> 00:10:36,400
Finance gets accurate cost data and developers don't get blocked by a missing tag.

239
00:10:36,400 --> 00:10:38,200
Third, cost-control in development.

240
00:10:38,200 --> 00:10:41,600
Development teams love to experiment, but experiments can get expensive fast.

241
00:10:41,600 --> 00:10:45,400
Someone might spin up a GPU instance with 24 cores just to test a simple script.

242
00:10:45,400 --> 00:10:50,000
So you create a policy that restricts VM sizes in dev subscriptions to smaller skews.

243
00:10:50,000 --> 00:10:52,600
Things like B-Series or D-Series with limited cores.

244
00:10:52,600 --> 00:10:56,400
If someone tries to deploy an expensive GPU or high memory VM,

245
00:10:56,400 --> 00:10:58,400
the deny effect kicks in and blocks it.

246
00:10:58,400 --> 00:11:01,400
Developers can still experiment, but they can't blow the budget.

247
00:11:01,400 --> 00:11:03,400
Fourth, security baseline for storage.

248
00:11:03,400 --> 00:11:07,200
Storage accounts are one of the most common places where security mistakes happen.

249
00:11:07,200 --> 00:11:10,000
Someone creates a storage account with public blob access.

250
00:11:10,000 --> 00:11:13,000
And suddenly, sensitive data is exposed to the internet.

251
00:11:13,000 --> 00:11:17,600
So you create a policy that requires HTTPS only traffic and blocks public blob access.

252
00:11:17,600 --> 00:11:21,400
And you use deploy if not exists to automatically enable diagnostic logging

253
00:11:21,400 --> 00:11:23,800
on every storage account that doesn't have it.

254
00:11:23,800 --> 00:11:26,400
The policy fixes the problem before it becomes a problem.

255
00:11:26,400 --> 00:11:28,400
Fifth, naming conventions.

256
00:11:28,400 --> 00:11:31,600
Your team wants all resources to start with prod or dev

257
00:11:31,600 --> 00:11:34,600
so they can easily tell which environment something belongs to.

258
00:11:35,600 --> 00:11:38,600
You create a policy that checks the resource name against the pattern.

259
00:11:38,600 --> 00:11:41,400
But instead of blocking the deployment, you use the audit effect.

260
00:11:41,400 --> 00:11:44,200
And the resource gets created, but it's flagged as non-compliant.

261
00:11:44,200 --> 00:11:47,400
Then you run a monthly compliance report and ask the team to fix the naming.

262
00:11:47,400 --> 00:11:50,400
It's a gentle way to enforce standards without breaking workflows.

263
00:11:50,400 --> 00:11:53,000
Every one of these examples follows the same pattern.

264
00:11:53,000 --> 00:11:54,400
Identify the problem.

265
00:11:54,400 --> 00:11:56,000
Choose or create the policy.

266
00:11:56,000 --> 00:11:59,600
Decide the effect, assign at the right scope, monitor compliance.

267
00:11:59,600 --> 00:12:00,600
That's the playbook.

268
00:12:00,600 --> 00:12:03,600
Now let's zoom out and see how all these pieces fit into the bigger

269
00:12:03,600 --> 00:12:05,000
as your governance picture.

270
00:12:05,000 --> 00:12:07,800
The big picture, how it all connects.

271
00:12:07,800 --> 00:12:10,200
So where does Azure Policy fit in the bigger picture?

272
00:12:10,200 --> 00:12:11,600
Let's think about it this way.

273
00:12:11,600 --> 00:12:13,600
Azure Policy works at the control plane level,

274
00:12:13,600 --> 00:12:16,200
sitting right on top of Azure Resource Manager.

275
00:12:16,200 --> 00:12:19,200
And it evaluates every single request that comes through.

276
00:12:19,200 --> 00:12:22,200
Every time someone creates updates or deletes a resource,

277
00:12:22,200 --> 00:12:23,800
Azure Policy checks the rules.

278
00:12:23,800 --> 00:12:25,600
It's the gatekeeper at the front door.

279
00:12:25,600 --> 00:12:28,400
Now, it's not the only tool in the governance toolbox.

280
00:12:28,400 --> 00:12:30,800
Azure Policy is just one piece of a bigger system.

281
00:12:30,800 --> 00:12:34,000
Management groups provide the hierarchy to organize your subscriptions

282
00:12:34,000 --> 00:12:35,800
and apply rules at scale.

283
00:12:35,800 --> 00:12:38,800
Roll-based access control decides who has access to what,

284
00:12:38,800 --> 00:12:41,800
while Azure Policy controls what configurations are allowed.

285
00:12:41,800 --> 00:12:44,200
Together, they form the foundation of cloud governance.

286
00:12:44,200 --> 00:12:45,400
Now, here's the thing.

287
00:12:45,400 --> 00:12:48,800
Azure Policy is also the engine behind other services you might already use.

288
00:12:48,800 --> 00:12:51,600
Microsoft Defender for Cloud uses Azure Policy

289
00:12:51,600 --> 00:12:53,400
to generate its compliance recommendations.

290
00:12:53,400 --> 00:12:56,000
When Defender tells you a storage account is non-compliant,

291
00:12:56,000 --> 00:12:58,200
it's actually running a policy evaluation.

292
00:12:58,200 --> 00:13:01,800
Azure Advisor pulls many of its cost and reliability recommendations

293
00:13:01,800 --> 00:13:03,800
from the same policy evaluations.

294
00:13:03,800 --> 00:13:06,200
And the compliance dashboard in the Azure Portal

295
00:13:06,200 --> 00:13:07,600
all built on policy data.

296
00:13:07,600 --> 00:13:09,600
So even if you've never created a policy yourself,

297
00:13:09,600 --> 00:13:11,800
you've probably been using them without knowing it.

298
00:13:11,800 --> 00:13:14,000
There's another practice called policy as code.

299
00:13:14,000 --> 00:13:16,200
Instead of creating policies through the portal,

300
00:13:16,200 --> 00:13:19,000
you store them as JSON files in a Git repository

301
00:13:19,000 --> 00:13:22,600
and deploy them through CI/CD pipelines just like application code.

302
00:13:22,600 --> 00:13:24,600
That gives you version control, code reviews,

303
00:13:24,600 --> 00:13:27,000
and automated testing for your governance rules.

304
00:13:27,000 --> 00:13:30,600
It's a more scalable way to manage policies across large organizations.

305
00:13:30,600 --> 00:13:32,400
Here's the most important thing to take away.

306
00:13:32,400 --> 00:13:34,400
Once you set up Azure Policy properly,

307
00:13:34,400 --> 00:13:36,200
it runs silently in the background.

308
00:13:36,200 --> 00:13:39,600
It's the automatic guardrail that prevents problems before they happen.

309
00:13:39,600 --> 00:13:41,200
Users may never know it's there,

310
00:13:41,200 --> 00:13:44,000
but they benefit from it every time they deploy a resource.

311
00:13:44,000 --> 00:13:46,200
You get consistent enforcement every single time

312
00:13:46,200 --> 00:13:49,600
without manual checks, approval tickets, or human error.

313
00:13:49,600 --> 00:13:52,200
So that's Azure Policy in plain English.

314
00:13:52,200 --> 00:13:55,600
It's an invisible rulebook that enforces your organizations,

315
00:13:55,600 --> 00:13:57,800
standards on every resource every time.

316
00:13:57,800 --> 00:14:01,000
If you want one single action from this episode, here it is.

317
00:14:01,000 --> 00:14:03,400
Go into the Azure portal, find policy,

318
00:14:03,400 --> 00:14:07,200
and assign the built-in allowed locations policy to a test subscription.

319
00:14:07,200 --> 00:14:09,000
Start with audit and see what happens.

320
00:14:09,000 --> 00:14:11,200
That's the fastest way to understand how this works.

321
00:14:11,200 --> 00:14:13,200
Subscribe for more Microsoft knowledge nuggets

322
00:14:13,200 --> 00:14:15,800
and share this with someone starting their Azure journey.

323
00:14:15,800 --> 00:14:18,200
Drop a comment with what you'd like me to explain next.