Day 531. Once you have enabled a Web Application Firewall on your #Azure Application Gateway by associating a WAF policy, there is no way to disable the WAF again. The only way to get rid of the WAF is to delete the Application Gateway and recreate it again. That seems like a completely arbitrary limitation and will hit you hard once you decide you no longer want to use the WAF feature.

Day 530. When creating an #Azure Log Analytics Workspace data export rule through #Terraform and you use a name that does not comply with the naming constraints, the Azure provider will tell you that this name is not allowed, but won't tell you what's wrong.
Tip: The names are not allowed to have an underscore.

Day 529. When you click on this "Copy to clipboard" in the #Azure Portal in the Application Gateway overiew, it doesn't only copy the gatway's Public IP address but also the name in the brackets. How is that helpful?

Day 528. On day 425 we showed how #Azure finally introduced a workaround for a limitation in their Private Link DNS integration concept by allowing the Azure DNS resolver to fall back to Public DNS in case a Private Link DNS zone does not have a corresponding DNS record. This could be a really useful feature for Private DNS zones in general, but for some reason you are only allowed to use it for Private Link DNS zones.

Day 527. The only documentation you can find about supported log categories for the #Azure Application Gateway uses log table names which are for some reason different than the actual log category names. How do you find the names of these log categories to enable them using Terraform when there is no documentation? Easy, just look into the API requests the Azure Portal is doing when you enable them through the GUI.

Day 526. Following up on the shit from day 514 where the #Azure #Terraform provider tries to read registered Azure providers even though you tell it not to. #Microsoft's response: This is expected behavior and how about you disable enhanced provider validation for ALL of your Terraform providers by setting an environment variable?

Day 525. With 91 characters, the error "ThirdPartyPrivateLinkServiceProvidedDuringPrivateEndpointCreationDoesNotExistOrIsNotVisible" takes the record for the longest #Azure error name we have seen so far.

Day 524. Deleting this #Azure VM disk just failed with HTTP error code "undefined".

Day 523. Seemingly not even Storage accounts are exempt from the ongoing capacity shortages in many #Azure regions.

Day 522. The #Azure Portal reminds us to regularly rotate our App Configuration access keys. That's pretty funny since #Microsoft had not rotated their MSA identity keys in years which allowed attackers to use a signing key from 2016 (!) to issue forged identity tokens and to breach the email accounts of basically all Microsoft clients in the Exchange Online hack in 2023.

Day 521. When deploying an #Azure Database for MySQL flexible server with vnet integration, Azure validates whether the specified Private DNS zone for the database is actually linked to your database's vnet. This DNS zone link is completely pointless when configuring a custom DNS server located in a different vnet which could not resolve this linked Private DNS zone anyways.

Day 520. After years of daily gambling whether we can deploy our resources to #Azure West Europe and North Europe regions, capacity shortages have apparently spread to Azure France Central.

Day 519. When your #Azure Application Gateway can't connect to backends because it can't resolve their hostnames, the health probes have no idea what's wrong and only tell you that they can't reach the backend. But don't worry, Dr. Azure Advisor is here to help you. It somehow knows exactly what's wrong and tells you that your App Gateway can't resolve some service hostnames. Then why can't the probes tell us that?

Day 518. When you want to resolve the shit from day 517 and restart your #Azure Application Gateway, there is no way to do it through the Azure Portal. You have to do it via API or CLI (or PowerShell, but seriously, who voluntarily uses PowerShell?)

Restarting it took around 6 minutes for us, btw.

Day 517. When changing the DNS server of your #Azure vnet, you will need to restart your Application Gateway for it to adopt the new DNS server which will result in service downtime. This is the same behavior as we have seen for VMs (see day 508), but at least you can do rolling upgrades with VMs. How many productive Application Gateways do you have?

Day 516. The shit from day 515 completely breaks #Azure's own Private Link DNS resolution concept for hub and spoke topologies, where they tell you to link Private Link DNS zones to your central vnet which hosts your central DNS server (such as Private DNS resolver or Azure Firewall).

Day 515. An #Azure Application Gateway will always use the Azure default DNS server for resolution of so-called management FQDNs (for example domains ending in "windows.net" or "azure.net"). That also includes most Private Link domains. Because of that, regardless of your central DNS resolution setup, you will need to link all Private Link DNS zones to your gateway's vnet for it to be able to resolve Private Endpoint hostnames.

Day 514. When your #Azure principal you use for #Terraform does not have enough permission to register providers for the subscription, the docs tell you to set the resource provider registration flag to "none". However, Terraform will still look up registered providers and fail if your principal doesn't have permissions to do that.

Day 513. There are somehow two "Subscriptions" tiles in the #Azure Portal search bar.

Day 512. While the shit from day 511 somewhat makes sense (traffic from the #Azure VPN Gateway is forwarded traffic after all), the description in the Azure Portal is highly misleading and there is no documentation available for this behavior.
This will blow up in your face if you always only had Gateway Transit enabled on peerings and you decide to disable Gateway Transit. Now you're stuck troubleshooting why your indirectly peered VMs can no longer talk to each other.