<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>takebakker.dev</title><link>https://takebakker.nl/</link><description>Recent content on takebakker.dev</description><generator>Hugo -- gohugo.io</generator><language>en</language><copyright>© 2026 Take Bakker</copyright><lastBuildDate>Sun, 11 Oct 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://takebakker.nl/index.xml" rel="self" type="application/rss+xml"/><item><title>Reference: How-To Post</title><link>https://takebakker.nl/drafts/reference-howto/</link><pubDate>Sun, 11 Oct 2026 00:00:00 +0000</pubDate><guid>https://takebakker.nl/drafts/reference-howto/</guid><description>&lt;p&gt;Private Endpoint DNS is one of those things that looks straightforward until it isn&amp;rsquo;t. The Azure docs cover the happy&#10;path well enough. What they don&amp;rsquo;t cover is what happens in a hub-and-spoke environment where your DNS lives in the hub&#10;and your workloads are spread across spokes.&lt;/p&gt;&#10;&lt;p&gt;This is the setup I run into most often in practice, and it has a few non-obvious gotchas.&lt;/p&gt;&#10;&#10;&lt;h2 class="relative group"&gt;The problem&#10; &lt;div id="the-problem" class="anchor"&gt;&lt;/div&gt;&#10; &#10; &lt;span&#10; class="absolute top-0 w-6 transition-opacity opacity-0 -start-6 not-prose group-hover:opacity-100 select-none"&gt;&#10; &lt;a class="text-primary-300 dark:text-neutral-700 !no-underline" href="#the-problem" aria-label="Anchor"&gt;#&lt;/a&gt;&#10; &lt;/span&gt;&#10; &#10;&lt;/h2&gt;&#10;&lt;p&gt;When you create a Private Endpoint, Azure creates a private DNS zone and links it to the VNet the endpoint lives in. In&#10;a flat network, that&amp;rsquo;s fine. In hub-and-spoke, your workloads in the spoke VNets won&amp;rsquo;t resolve the private IP — they&amp;rsquo;re&#10;not linked to that zone, and your central DNS forwarder in the hub doesn&amp;rsquo;t know about it either.&lt;/p&gt;</description></item><item><title>Reference: Opinion/Experience Post</title><link>https://takebakker.nl/drafts/reference-opinion-post/</link><pubDate>Sun, 11 Oct 2026 00:00:00 +0000</pubDate><guid>https://takebakker.nl/drafts/reference-opinion-post/</guid><description>&lt;p&gt;Terraform state drift is treated as an edge case. In my experience it&amp;rsquo;s more like a regular occurrence that teams aren&amp;rsquo;t&#10;monitoring for.&lt;/p&gt;&#10;&lt;p&gt;The scenario is always some variation of: someone makes a manual change in the portal — usually under time pressure,&#10;usually with good intentions — and doesn&amp;rsquo;t update the Terraform code to match. The state file now reflects reality as&#10;Terraform last knew it, not reality as it actually is. Next &lt;code&gt;terraform plan&lt;/code&gt; shows unexpected changes. The team gets&#10;confused, makes it worse, or both.&lt;/p&gt;</description></item><item><title>Reference: Problem Post</title><link>https://takebakker.nl/drafts/reference-problem-post/</link><pubDate>Sun, 11 Oct 2026 00:00:00 +0000</pubDate><guid>https://takebakker.nl/drafts/reference-problem-post/</guid><description>&lt;p&gt;We had a policy assignment that looked fine in the portal. Compliance showed 98%. The remaining 2% was a handful of&#10;resources flagged for missing tags — known, accepted, moving to remediation next sprint. Nothing alarming.&lt;/p&gt;&#10;&lt;p&gt;Then someone asked why a storage account deployed three weeks ago was still publicly accessible. It wasn&amp;rsquo;t in the&#10;non-compliant list. The policy was supposed to deny it.&lt;/p&gt;&#10;&lt;p&gt;It took a while to figure out why.&lt;/p&gt;</description></item><item><title>Hello World</title><link>https://takebakker.nl/posts/hello-world/</link><pubDate>Sat, 13 Jun 2026 00:00:00 +0000</pubDate><guid>https://takebakker.nl/posts/hello-world/</guid><description>&lt;h1 class="relative group"&gt;The blog is live. More to come.&#10; &lt;div id="the-blog-is-live-more-to-come" class="anchor"&gt;&lt;/div&gt;&#10; &#10; &lt;span&#10; class="absolute top-0 w-6 transition-opacity opacity-0 -start-6 not-prose group-hover:opacity-100 select-none"&gt;&#10; &lt;a class="text-primary-300 dark:text-neutral-700 !no-underline" href="#the-blog-is-live-more-to-come" aria-label="Anchor"&gt;#&lt;/a&gt;&#10; &lt;/span&gt;&#10; &#10;&lt;/h1&gt;&#10;&lt;p&gt;Lorem ipsum dolor sit amet, consectetur adipiscing elit. Mauris volutpat erat nisl, sit amet finibus ipsum lobortis sed.&#10;Quisque a rhoncus orci. Phasellus at commodo dui. Duis venenatis faucibus dui sit amet rutrum. Nunc ut magna&#10;ullamcorper, tincidunt tellus eget, luctus sem. Duis sem odio, porta at purus vitae, iaculis elementum massa. Vivamus et&#10;orci interdum, blandit diam id, bibendum elit.&lt;/p&gt;</description><media:content xmlns:media="http://search.yahoo.com/mrss/" url="https://takebakker.nl/posts/hello-world/cover.jpg"/></item><item><title>Sample Album</title><link>https://takebakker.nl/gallery/sample-album/</link><pubDate>Sat, 13 Jun 2026 00:00:00 +0000</pubDate><guid>https://takebakker.nl/gallery/sample-album/</guid><description>&lt;p&gt;Sample gallery album using placeholder images. Replace with your own CDN URLs.&lt;/p&gt;</description></item><item><title>About</title><link>https://takebakker.nl/about/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://takebakker.nl/about/</guid><description>&lt;p&gt;I&amp;rsquo;m Take Bakker — solution architect at an MSP in the Netherlands, based in Drenthe.&lt;/p&gt;&#10;&lt;p&gt;18 years in IT, the last 10 focused on Microsoft Azure. I spent 8 of those as a consultant and moved into a solution&#10;architect role a couple of years ago. Day to day that means designing and building cloud environments — mostly Azure&#10;Landing Zones, networking, governance, and automation — for organisations that want to do it properly.&lt;/p&gt;</description></item></channel></rss>