Agentic AI, or agents for short are all the rage these days. As I showed in my previous post, they can come in quite handy when it comes to quickly and easily analyzing and making sense of data and help generate the insights you are looking for.

With my wine cellar already imported, I began to wonder what else my little AI helper might do for me. Zurich hosts several sizeable wine fairs each year (see my article here for more info), but making the most of them can be surprisingly tricky. Sure it’s easy to wander in unprepared and leisurely drift from stall to stall (or wherever one happens to find free elbow-room) but if you’re actually interested in finding wines that are right up your nose or those that are complete novelties, you’ll need to carefully study the brochure and then plan a route, lest you be running around like a headless chicken looking for the 10th booth with something like wine or vino in the name. So what to do? Easy: Let AI do the heavy lifting.

Hello again! Today, I want to shine a light on a powerful but often overlooked Azure Policy mechanism: resource tags. While widely available, they’re rarely used to their full potential, especially when it comes to policy scoping. What do Azure resource tags have to do with policies you might ask – the short answer is that since tags can be described as both meta and child resources that are available on every Azure resource and service offering, this makes them a prime candidate for laser–focused policy scoping.

In the third edition to the series, I would like to explain how we can actually determine when a policy can or should be used to achieve our goal.

First, let’s recall how Azure Policy works: By interacting with the Azure Resource Manager (ARM) API. This already shows us the first limitation: We will not be able to use a policy to restrict the behavior of an Azure resource or service if the level that we want to restrict is not accessible via the ARM API. This includes for example:

In the second post of this series, I want to show you an example of using a function inside a policy definition to restrict the scope. Based on personal experience, policy functions are often somewhat neglected but have received significant development over the past few years. As you can see in the official documentation Azure policy supports a wide range of functions, including:

• copyIndex()
• dateTimeAdd()
• dateTimeFromEpoch
• dateTimeToEpoch
• deployment()
• environment()
• extensionResourceId()
• listKeys()
• listSecrets()
• reference()
• resourceId()

Many of these functions are also available for ARM templates, such as copyIndex(), listKeys(), and resourceId(), and are very practical for operations targeting complex deployments with multiple, interdependent resources. However, a function that is perhaps less well-known is requestContext().

Communication is one of the key skills of any good solution architect. Not only should you be able to create sound, secure and performant software designs but you also need to be able to communicate these to stakeholders.

To visualize these complex solutions, diagrams are a handy tool and there are a lot of different software offerings out there that help with this exact use case - most popular perhaps Microsoft Visio and Enterprise Architect.