I've blogged and talked about Azure Developer CLI before, but this time, I will touch on a functionality as part of the azure.coding-agent extension.
This extension automates the deployment and configuration to allow the GitHub Copilot Coding Agent access to Azure resources directly through the use of the Azure MCP Server .
Recently Microsoft announced native Service Bus message publishing from Azure API Management, today we are going to take a look at this new feature and see how we can use it to publish messages AMQP (Advanced Message Queuing Protocol) to an Azure Service Bus queue or topic directly through an API Management endpoint, without needing middleware to do a transform for you - allowing external systems and mobile apps that lack native AMQP support can send messages to Service Bus by using standard HTTP/REST APIs via API Management.
Today, we are going to look at some of the practicalities of Spec Kit and use Spec-Driven Development to create a Platform Landing Zone aligned to the Microsoft Cloud Adoption Framework, using Bicep as the Infrastructure as Code.
I was recently working on a content discovery app and needed access to current Microsoft documentation, but I wasn't keen on scraping their site (and dealing with all that maintenance overhead).
Service Principal vs User‑Assigned Managed Identity? This came up again for me recently while deciding what to standardise on for Infrastructure as Code deployments.
Now that Workload Identity Federation (WIF) is broadly supported, it’s pretty simple to move a traditional service principal off a client secret and onto federated credentials – or create it that way from day one. So why bother with a user‑assigned managed identity (UAMI)?
Because I've formed a preference over the last couple of years: for most DevOps / platform automation scenarios, I'll reach for a User‑Assigned Managed Identity with WIF before I create (yet another) service principal. This post walks through the why, plus where a service principal still makes sense.