Reference on takebakker.dev

Reference: How-To Post

Sun, 11 Oct 2026 00:00:00 +0000

Private Endpoint DNS is one of those things that looks straightforward until it isn’t. The Azure docs cover the happy path well enough. What they don’t cover is what happens in a hub-and-spoke environment where your DNS lives in the hub and your workloads are spread across spokes.

This is the setup I run into most often in practice, and it has a few non-obvious gotchas.

The problem
#

When you create a Private Endpoint, Azure creates a private DNS zone and links it to the VNet the endpoint lives in. In a flat network, that’s fine. In hub-and-spoke, your workloads in the spoke VNets won’t resolve the private IP — they’re not linked to that zone, and your central DNS forwarder in the hub doesn’t know about it either.

Reference: Opinion/Experience Post

Sun, 11 Oct 2026 00:00:00 +0000

Terraform state drift is treated as an edge case. In my experience it’s more like a regular occurrence that teams aren’t monitoring for.

The scenario is always some variation of: someone makes a manual change in the portal — usually under time pressure, usually with good intentions — and doesn’t update the Terraform code to match. The state file now reflects reality as Terraform last knew it, not reality as it actually is. Next terraform plan shows unexpected changes. The team gets confused, makes it worse, or both.

Reference: Problem Post

Sun, 11 Oct 2026 00:00:00 +0000

We had a policy assignment that looked fine in the portal. Compliance showed 98%. The remaining 2% was a handful of resources flagged for missing tags — known, accepted, moving to remediation next sprint. Nothing alarming.

Then someone asked why a storage account deployed three weeks ago was still publicly accessible. It wasn’t in the non-compliant list. The policy was supposed to deny it.

It took a while to figure out why.

Reference on takebakker.dev

Reference: How-To Post

The problem #

Reference: Opinion/Experience Post

Reference: Problem Post

The problem
#