Have you ever wanted to setup granular folder permissions in your Azure DevOps repos but couldn’t figure it out? I was working on a project where the customer wanted to setup their version of GitFlow and was trying to setup permissions in Git so that only certain groups of users could control writes to Main, Release, Develop and Feature branches at specific levels in the path of these branches. This post will walk you through how to do that in Azure DevOps.

I recently had a customer who wanted to authenticate user access to a basic website that was hosted in Azure Storage Accounts. The basic static website functionality that is bundled with Storage Accounts doesn’t provide this. There are a few ways we might have approached this, for instance we could have potentially used Static Web Apps, however what if we just used their existing App Service plan and the built in authentication for Web Apps.

Have you ever wanted to test out configuration of resources setup quickly in Azure using devops pipelines and been frustrated by how long it takes to get your project bootstrapped with a service principal, keystore, storage account and other goodies that are often required? If so, this is the post for you.

Do you want to enable Azure AD integration with your Azure Kubernetes Service (AKS) but struggle with 403 Forbidden error messages in the Azure portal when trying to view Kubernetes objects? If you’re having these issues this could be a good post for you. We’ll look at what causes this and 3 solutions to fix it.

In the last 2 posts we looked at building an Azure Automation that would shutdown VMs that were underutilized using runbooks, alerts and webhooks. There was quite a lot of information packed into those posts and in this post I want to unpack a few learnings I discovered along the way and explain them a bit better than perhaps the Microsoft documentation does.

In the second part of the post we’ll take the webhook and runbook we created in Part 1 and build on what we learned. This segment will focus on Azure Monitor Alerts and how to stitch together Signals with Action Groups to ultimately ensure that our VM is shutting down when it’s not in use or underutilized and like in Part 1 of the series we’ll do all this from the command line.

Sometimes it can be very beneficial to your budget to shutdown your VMs when they are idle or underutilized. In many cases there might be alternative strategies for processing workload like VM scalesets or Azure Functions that should be explored but in some situations shutting down an existing VM can make a lot of sense. In this part 1 of a 2 part series we’ll look at Azure Monitor and what Alerts are and we’ll even explore how to make REST API calls from the az command line. All this leading to part 2 where we put everything together to stop VMs based on a signal sent from Azure Monitor related to CPU usage.