Day 484. Continuing the shit from day 483, when you want to upgrade the version of your #Azure Database for PostgreSQL flexible server through #Terraform without wiping it, you have to set the 'create_mode' property to 'Upgrade' instead of 'Default'. However, you cannot set it to 'Upgrade' when creating the resource and changing it later forces a replacement of the resource, wiping all of your data.

Day 483. When managing an #Azure Database for PostgreSQL flexible server through #Terraform, upgrading your database's version by changing the 'version' property forces a recreation of the resource, wiping all of your data.

Day 482. In one of #Microsoft #SharePoint's recent security breaches, attackers were able to bypass API authentication by simply supplying a Referer header that indicates that the user just logged out.
This seems to be this multilayered defense-in-depth security Microsoft is always bragging about.

Day 481. The #Azure SDK for Golang allows you to retrieve paginated activity alerts for Azure resources, but there is no way to configure the page size.

Day 480. Even when disabling Azure Policies to allow an insecure public Storage Account to be restored, the restoration can fail and the Azure Portal won't give you any information. You will need to check the activity logs of the resource group you are deploying to for the failure reason.

Day 479. When restoring a deleted #Azure Storage account, it will always be restored with public network access enabled, even when it previously only had private access. Besides this being a security risk, when you have Azure Policies in place that deny public resources, there is no way to restore the Storage Account.

Day 478. Following up on #Azure Database for PostgreSQL flexible server being too stupid to recognize our new DNS server from day 477, in case you are wondering why the fuck a database even performs DNS requests: It is for some reason trying to resolve weird Traffic Manager hostnames.

Day 477. Following up the shit from day 476, we asked #Microsoft support how to get the #Azure Database for PostgreSQL flexible server to adopt the new DNS server and they told us to try to restart the instance or scale out and in again to force new nodes to get created. Both of these approaches did not work. Apparently even Azure engineers have no idea how to update the DNS server of this database.

Day 476. When deploying an #Azure Database for PostgreSQL flexible server in vnet integration mode, it will use the custom DNS server of your vnet. But when you change the DNS server of your vnet, there is seemingly no way to get the database to use the new DNS server. It will still send DNS requests to the DNS server that was configured for the vnet at deployment time, even when this DNS server no longer exists.

Day 475. What's weirder than the shit from day 474, our #Azure SQL Managed Instance is still performing DNS requests to our custom DNS server even though it has been stopped.