Azure Bicep fail() function was introduced in Bicep CLI v0.33.93. In short this function allows you to fail your deployment when certain conditions are met. In this blog post we will look at how to use it in real world example.
Azure Monitor workbooks are great way to visualize Azure data for monitoring and analysis. Although there is a good documentation on how to built them I would say that examples for more advanced scenarios are lacking in there. Recently I was asked a question about such scenario: “How do I set KQL query in a way that the filter for optional parameter in Azure Monitor workbook is not applied if value is not provided for that parameter?”.
These days Azure Bicep has a lot of more functions that can be used for processing data. Most notably I am referring to the lambda Azure Bicep functions. Often times I use two or more of these functions all together in Bicep templates. When using several of these functions chained one after another it is easier to get lost how data will be processed. Also to test all the different input that will be passed to those functions will results in doing several different deployments. That is time consuming process as deployments takes time to run not to mention that along I have several other resources also deployed via those templates. Thankfully just to test if the data is processed according to how I have imagine it there is easier method by using Bicep parameters files.
Azure Customer Managed Key (CMK) Encryption is quite used feature across Azure resources in order to make sure you are compliant against various certifications and increase your security posture. I have been configuring this feature via IaC since there was only ARM Templates and Bicep was not available. If you have the same experience with me you will notice that the input required for this feature varies from one resource to another. If have to summarize what is required as information that would be:
With that said in this blog I would like to show you how I used to configured the feature when using ARM templates and how I think it is the better approach when using Bicep code.
Azure Resource Health is Azure Monitor feature to track the overall health of different Azure services. It is particularly handy for PaaS and SaaS type of services as those usually get at most metrics and diagnostic logs that you can use to monitor them. The feature is on by default and it is supported by many resource types. For each resource type there are certain checks that are made on intervals and if any of those checks fails resource health will mark the resource as unavailable. These changes in the resource health are logged as Azure Activity log events. In order to monitor for these changes you can use Resource Health alerts which underneath are alerts monitoring for activity log events scoped to Resource Health category events. Recently Azure Monitor introduced support for resource health on Log Alerts. Log alerts use Kusto query language to monitor based on data from Log Analytics workspace. Due to the rich Kusto query language capabilities there is the possibility of providing incorrect query and saving the alert rule without knowing that it will stop working. This is where Resource Health for Log alerts comes in as it will signal you that there is something wrong with your alert rule. There are of course other checks made related to permissions and networking that will also be signal by Resource Health for your Log Alerts. So enabling Resource Health alerts to notify you on problems with your Log Alerts is something you should do in your environment. The purpose of the blog post is to show you how resource health works and hopefully to enable resource health alerts for your Log Alerts. Overall I would strongly advise you to enable it for all supported resources as it does not introduce additional cost.
Cloud Administrator in Azure World 