Instead of sending them to a form or another system, everything stays inside the conversation.

In this step, an Adaptive Card in Copilot Studio captures the user’s selection and input, turning a simple chat into a structured request that can be processed automatically.

I decided not to repeat the full tutorial here, since it’s already well covered in the Copilot Agent Academy documentation. In the previous post, I focused on the device lookup (Available Devices topic) because I adapted it to use Dataverse instead of SharePoint, which is what the official guide uses.

If you want to continue from the last step, here is the direct link to create the Request Device topic in Copilot Studio which is the next: Add adaptive cards and enhance topic capabilities

The topic is triggered and the Adaptive Card appears only if the user answers “yes” to the question from the Available Devices topic: “Would you like to request one of these laptops?” (The one we did in the previous blog post).

This is the final output from my environment, and it’s what you should see as well once the lab is completed.

And once the user clicks “Submit Request” button, they should get a message in the chat like this one:

If you have questions or want me to walk through this in a session, happy to discuss.

That’s all for today. See you in the next one, where we’ll look at sending an approval email to the manager for the device request using an agent flow.

Did I disappoint you by not making it Azure-related? 😄 Bear with me.

Instead of building a simple chatbot demo, I wanted to see how far an agent could go in handling a real internal IT scenario Thanks to the Copilot Agent Academy from Microsoft.

So I designed an end-to-end device request assistant.

Here is how it works.

An employee asks the agent about available devices.

The agent triggers the Available Devices topic, which queries Dataverse and filters devices that are currently available based on type and status.

The agent then shows the results and asks a simple question:

“Would you like to request one of these devices?”

If the answer is yes, the conversation moves to the Request Device topic.

At this point an Adaptive Card is generated dynamically, showing device details and allowing the user to submit a request with notes.

Once the user submits the card, an agent flow takes over.

In this post, I will walk through how the Available Devices topic that retrieves and filters enterprise data from Dataverse in real time was designed.

For this lab, I needed a table in Dataverse to store devices:

Step 1 — Creating a Topic to Handle the Request

The first step is defining how the agent understands the request.

In Copilot Studio, this is done using a Topic.

The topic acts as:

The entry point for the request

The logic container for handling it

In this case, I created a topic responsible for: Finding available devices based on user input

Step 2 — Capturing User Intent (Input Variable)

The agent needs to understand what the user is asking for.

For example:

Laptop

Desktop

Smartphone

To handle this, I defined an input variable:

Device Type (captured from user message)

This allows the agent to dynamically adapt its query based on what the user asks.

Step 3 — Defining the Expected Output

Next, I defined what the topic should return.

In this case:

A list of available devices

This is structured as a table output, which allows the agent to process and present multiple records cleanly.

Step 4 — Connecting the Agent to Dataverse

Now comes the key part.

The agent needs to retrieve real data.

This is done using a connector action:

Dataverse → List Rows

The important fields here are the Table name, as well as the filter rows. Here is the fx for the filter rows to ensure only available devices are returned.

We only want:

Devices that are Available

Devices that match the requested type ( Based on User’s input/answer in the chat)

Note the casting from string value to optionset value (required when dealing with Dataverse)

Concatenate(
    "cr42e_status eq 557910000 and cr42e_assettype eq ",
    If(
        Topic.VarDeviceType = "Laptop", 557910000,
        Topic.VarDeviceType = "Phone", 557910002,
        Topic.VarDeviceType = "Desktop", 557910003,
        Topic.VarDeviceType = "Tablet", 557910001,
        Blank()
    )
)

Step 5 — Preparing Data for the Agent Response

The filtered data is then mapped into a variable that the agent can use in its response by adding a node. Variable Management → set variable value

This step ensures:

Clean formatting

Reusability across the conversation

We are doing this because the output of “List rows “ is scoped to that node, and not guaranteed to be usable reliably across the whole conversation unless you explicitly store it. It also normalizes the data as the output Connector output is messy (metadata, paging, etc). By using .value, we ensure we’re extracting the actual records

Final Step — Guiding the Agent with Instructions

After building all of the components, the agent is then guided with instructions.

These instructions define:

When to trigger the topic

How to respond

What to ask next

For example:

Show available devices

Ask if the user wants to request one

This is what turns the solution from a query into a conversation.

Next up: Request Device.

The agent moves from just listing available devices to handling requests via an adaptive card.

That’s all for today. See you in the next one.

Before the holidays, I got a review copy of this book, and thanks to a few quiet days over the break, I finally had time to read it.

Azure is an exciting place to build right now. It is also an overwhelming one. New services, new patterns, new opinions. Most of us have felt that tension between moving fast and actually understanding what we are building.

This book meets you right in that space. What stands out immediately is the focus on fundamentals. Every chapter slows down just enough to explain the basics before going deeper.

The journey begins where it should. Explaining Azure CLI, PowerShell, and end-end environment setup, so you can get hands on without friction.

The new AI content is especially well done. The Azure OpenAI and Azure Machine Learning chapters do not jump straight into code. Kamil explains what OpenAI is, what Azure OpenAI is, how deployments work, what tokens really mean, and why prompts behave the way they do.

That same pattern shows up across the book. Storage. Messaging. Workflows. Containers. Each chapter resets context, explains the core ideas, then builds on them. This makes it easier to reason about trade offs instead of memorizing services. Monitoring and observability also get the attention they deserve. Application Insights is covered properly, including dependency tracking, environment separation, and practical configuration. This is an area many teams underinvest in, and the book does not gloss over it.

The book has twenty solid chapters, organized into five key parts:

Setting Up Your Environment

Web Applications and Workflows in Microsoft Azure

Containers in Microsoft Azure

Storage, Messaging, and Monitoring

AI, ML, and DevOps

You will find useful screenshots, code snippets and diagrams that provide clarity.

I can say confidently that this book is a solid choice for developers, backend engineers, DevOps-minded developers, and architects who want a practical, developer-focused view of Azure services.

Book link here: Azure for Developers: The definitive guide to creating secure, scalable Azure apps with GenAI, serverless, and DevOps pipelines

Let me know if you would be reading it.

That’s all for today. See you in the next one.

We can see this by taking a look at how components interact in a typical web request. So feel free to comment on this architecture.

Let’s take a simple basic web app:

A user visits a public site. The site runs on Azure App Service.

Traffic enters through Azure Front Door.

The app calls an API inside a virtual network.

The API writes data to an Azure SQL database.

Everything runs in one Azure region with zone level redundancy.

High level, it looks like this:

User → Public Internet → Azure Global Network → Regional Layer → VNet

Start with the user click

A click generates a packet. The packet travels across the public internet. Routers move it based on standard routing protocols. Azure is not involved yet.

Entry to Azure

The packet reaches the closest Azure edge location. Front Door performs global routing to the correct region.

Azure global network movement

Traffic moves entirely across private switches and routers controlled by the platform. This is the long-haul network that moves your traffic from the nearest Azure edge location to the region that hosts your app.

Region Arrival

A cluster of datacenters in one geographical location. If Application Gateway is present, it performs layer seven routing. It reads headers, paths and cookies. It examines headers and paths, then forwards the request to the App Service front end.

App Service

Your code runs inside a sandbox. The compute host assigns CPU, memory and network interfaces. Physical servers under the host run on Azure designed hardware. An internal load balancer picks a healthy worker for each request. Your app receives the request. It parses data, applies logic and prepares to call downstream services.

Move into the virtual network

When App Service calls the API, the packet moves into the VNet through the configured VNet Integration.

Inside the VNet:

Virtual switches control routing

Subnets isolate resources

NSGs apply rules only to resources inside those subnets

User-defined routes influence how traffic flows

The packet reaches the API.

API execution (Represented by an Azure function - premium plan here)

The API runs on its own compute hosts. It processes the request then sends a query to Azure SQL.

The API processes the request and sends a query to Azure SQL.

Storage and hardware

Azure SQL stores data on clusters of physical disks backed by distributed replicas. Writes land in durable storage protected by multiple failure domains.

Return path

The response flows back along the same connection:

SQL returns data to the API

API returns data to App Service

App Service generates the final response

The connection returns through App Gateway if present

Front Door sends it back across Azure’s backbone

The closest edge site returns it to the public internet

The browser renders the result.

That’s all for today, see you in the next one.

I had done most of the study plan but skipped Monitoring and Backup; two topics that I thought wouldn’t carry much weight. They did. And it showed in the score report.

So I took a step back, slowed down, and planned a proper second attempt.

This time I was studying while working, so progress came slowly, bit by bit.

I started with the Microsoft Learn Study Guide. Always check for the latest version close to the time you plan to take the exams because Microsoft update the content and objectives.

Then I went through each module and fixed the weak spots from my first try.

Every weekend I did labs and made sure everything I learned was something I could try out in the Azure Portal. I did not do much of CLI or PowerShell.

Finally, I passed this exam.

My Prep Stack That Worked

First let’s start with what you would need for the labs (non-negotiable component of prepping)

Azure Subscription

• An active Azure account (free tier, pay-as-you-go, or MSDN/Visual Studio subscription). About Azure Free Account

• Enough credits to deploy multiple VMs, VNets, and services for testing.

• If you’re doing labs and cleaning up resources daily, $50–$100/month should be sufficient.

• If you want to keep resources running for several weeks for experimentation, aim for $150–$200 to avoid hitting limits.

1. The Core Materials

If you already work with Azure Admin services daily, you don’t need to overcomplicate it.

Here’s what worked for most admin professionals I’ve seen clear it quickly:

• Microsoft Learn – Refresh the modules; don’t just read, do.

• John Savill’s AZ-104 Study Cram (v2) – It’s concise and solid.

• Practice Exam – Take one at least a week before your test; it highlights where you need to dig deeper.

But if, like me, you spend more time developing than administering, you’ll want a fuller approach:

• Microsoft Learn (complete paths) – Do every exercise, not just the theory.

• A full-length course video – Avoid short cram content. Recommendations: CloudLee, Any good rated Az-104 course in Online, Scott Duffy.

• AI (Copilot or ChatGPT) – Use it to simplify hard topics. I’d often ask, “Explain like I’m new to networking,” and it worked wonders.

• Practice Exam. Again, one week before the real thing.

The Labs That Made the Difference

Here are the ones that genuinely improved my understanding and confidence in the portal as a non-admin Azure person:

Virtual Machines

• Create a simple web server on a virtual machine. Practice resizing and redeploying it, attaching and encrypting additional disks, changing IP settings, and setting up a virtual machine scale set to handle increased traffic

I learned that most tricky AZ-104 questions are based on real configuration behavior, not definitions.

Virtual Networks

• Create a virtual network with two subnets. Deploy a virtual machine in each subnet. Add a NAT gateway to enable secure outbound internet traffic, and apply a network security group to control inbound and outbound rules. Test connectivity between the VMs using private IPs and confirm outbound internet access through the NAT gateway.

That’s where I finally understood how Azure handles routing and isolation.

Storage

• Set up a storage account and create containers for blobs and file shares. Upload sample data, generate shared access signatures for controlled access, change access tiers between hot and cool, and add a lifecycle management rule to automatically move or delete old files.

Once I practiced setting up access policies, questions about permissions became easy points.

Other Important Lab Ideas:

Load Balancing:

• Deploy a web application on a virtual machine and configure an Azure Load Balancer to distribute traffic across multiple VMs. Set up an Application Gateway with Azure Container Instances as the backend, and test that incoming requests are properly balanced and routed to the correct instances.

Monitoring:

• Create a Log Analytics workspace and connect virtual machines to it using agents and data collection rules. Use Network Watcher and KQL queries to visualize metrics, configure alerts for critical events, and test that notifications trigger correctly

Backup & Recovery:

• Configure Azure Backup to protect virtual machines and other resources, and set up Azure Site Recovery for disaster recovery. Test recovery scenarios to ensure that data and VMs can be restored quickly and reliably.

Governance & Cost Control:

• Set up budgets to monitor spending, apply resource locks to protect critical resources, and enforce policies for compliance. Deploy sample resources using ARM or Bicep templates to practice automated, policy-compliant provisioning.

Final Take

After two tries, here’s what I’d tell anyone studying for it:

Don’t skip any module.

The labs are where things actually start to click. Every lab taught me something that a video couldn’t.

Talking about Labs. Here are some tips to minimize costs

• Stop/deallocate VMs when not in use to avoid compute charges.

• Delete unused resources after completing labs.

• Use Azure Free Tier: 12 months of free services and $200 credit for the first month.

Practice exams aren’t only about the score. They show you what you still don’t get. Try to take or refresh them close to the exam date.

The skillset is quite robust & large but if you can study a bit every day, even for an hour, you’ll keep making progress.

When I finally passed in October, it wasn’t because I memorized things. It was because it all finally made sense and I could join the pieces together.

Some people are requesting for a live session to discuss this, if it is something you would be interested in, simply like this post and I would send you an invite.

That’s all for today and see you in the next one.

No one needs the entire Azure catalog, but a focused set of services gives them superpowers without overwhelming complexity.

If you are interested in a deep dive into these service including practical use cases, please like this post and I will provide you with more details.

These are 7 Azure services every Power Platform developer should know:

Managed Identity

Azure App Registration

Azure Functions.

Azure Logic Apps.

Azure Storage.

Azure App Insights.

Azure Key Vaults.

1. Managed Identity

Why: Eliminates hardcoded secrets and credentials when connecting Power Platform to Azure resources.

Example: A Power Automate flow calling an Azure Function authenticates seamlessly using Managed Identity.

2. Azure App Registrations (Entra ID)

Why: Enable secure authentication for apps, APIs, and custom connectors by registering them in Azure AD.

Example: Register a custom API or third party application so it can be consumed securely inside Power Platform.

3. Azure Functions

Why: Run custom logic beyond what Power Automate or Power Fx or even Plugins can handle efficiently.

Example: Perform complex operations, call external APIs, process files — without sacrificing performance within Dataverse.

4. Azure Storage

Why: Cost effective, scalable way to handle files, images, logs, or datasets too big for Dataverse.

Example: Power App uploads receipts to Blob Storage → flows process them.

5. Azure Logic Apps

Why: Like Power Automate's "big sibling" — same connectors, but with enterprise scale, control, and integration flexibility.

Example: Long-running B2B integrations that interact with other Azure services and solutions.

6. Azure Application Insights

Why: True observability — track errors, performance, and usage across apps, flows, and connectors.

Example: Trace a failures in plugins, custom APIs or c and see where the error originated.

7. Azure Key Vault

Why: Secure storage for API keys, secrets, and certificates.

Example: Instead of embedding API keys in custom connectors, or anywhere makers reference Key Vault.

Many of this can be easily picked up on Microsoft Learn. Happy skills update, guys.

That’s all for today, see you in the next one.

If you are interested in a deep dive into these service including practical use cases, please like this post and I will provide you with more details.

An event is simply a fact that something has happened. Event Grid takes those facts from publishers, such as Azure Blob Storage, Service Bus, or even a custom application, and delivers them to subscribers like Logic Apps, Azure Functions, or Event Hubs. The delivery is push-based, so there is no need for polling or constant checks.

Imagine a scenario where customer orders are sent into a Service Bus queue. Without Event Grid, a Logic App would need to keep checking for new messages.

Can you use direct integration with Service Bus? It works, but here's the catch: under the hood, Logic Apps are polling the queue. That means some added latency, and possible double processing of same message.

With Event Grid in place, the moment a new order arrives, an event is raised and pushed into your workflow. From there, you can automatically notify your operations team in Microsoft Teams, call an Azure Function to validate and enrich the order, or record the details in Microsoft Dataverse for business tracking.

It is straightforward to set up and can be applied across many scenarios, so let’s get started.

We will follow this official Documentation from Microsoft:

Tutorial: Respond to Azure Service Bus events received using Azure Event Grid by using Azure Logic Apps

1. Setup Service Bus (+ topic and subscription)

2. Send messages to the Service Bus topic

3. Create new Logic App to Receive messages

4. Add a step receive messages from Service Bus using Event Grid

The following two actions (5 & 6) are inside a foreach looping over the body of the messages received from the bus

5. Add a step to process received messages (Here, we send an email)

6. Add a step to complete received messages.

6. Test the app.

If you haven't already sent test messages to the topic, use the code in the step 2 to send test messages to the Topic.

Navigate to the Overview page of your logic app. Then select the Run history tab in the bottom pane. You see the logic app runs messages that were sent to the topic. It could take a few minutes before you see the logic app runs. Select Refresh on the toolbar to refresh the page.

Select a logic app run to see the details. Notice that it processed five messages in the for loop.

6. You should get an email for each message the logic app receives.

That’s all for today, see you in the next one.

OpenTelemetry provides a vendor-agnostic way to collect traces, metrics, and logs from your application. It is an industry standard for instrumenting applications and transmitting telemetry. Read more about this technology here: OpenTelemetry Explained

By default, Azure Functions emit telemetry from both the host process and the language-specific worker, and this data is typically sent to Application Insights via its SDK.

With this update, you can now export the same telemetry (structured traces and logs), to any OTLP-compatible backend in a few easy steps.

First, let us take a sample OLTP endpoint to send our telemetry data to. In this case, I am using an observability platform for the test: honeycomb.io. I first created an account with them and obtained some config details which you can find in their docs:

Pick your API key from the section shown below:

Now, we can begin to configure our sample azure function in order to be able to send telemetry data to the public endpoint obtained above.

1. Enable OpenTelemetry in the Functions host

2. Configure application settings

PS; Make sure you replace the <your-api-key> with the API key copied from honeycomb site.

3. Enable OpenTelemetry in your app

This involved installing the packages, I have more here because I planned to send to Application Insights as well. If you only want to send to the OLTP endpoint, then you don’t need to have as many. Check the Microsoft docs to confirm which packages you need.

4. In your program.cs:

Final step is to send logs from your function:

When you run and post to this function, you find telemetry data in your honeycomb’s dataset:

General trace:

Custom Data Sent:

Official Microsoft Documentation: Use OpenTelemetry with Azure Functions

That’s all for today.

See you in the next one.

See attached video: ⬇️

With that, I unlocked the following benefits:

⚡️ Automatic scaling (via KEDA)

🛠 Access to native ACA features: revision control, secrets, traffic routing, and more

Earlier, you could run Azure Functions on Container Apps by creating them through the regular Function App setup & selecting the hosting plan. It worked, but came with some extra complexity and didn’t give full access to all the features that Container Apps offer.

Some developers also tried running function images directly on ACA, but that approach wasn’t officially supported and missed out on key benefits like built-in autoscaling.

🔄 How to migrate to the new model

🆕 Create a new Function Container App (via Portal or CLI).

🔗 Provide your existing function image URL during setup.

🧾 Manually provision storage, App Insights, and replicate app settings as env variables/secrets.

✅ Your app will now use the new kind=functionapp property.

🔁 Test thoroughly — and if all goes well, decommission the old setup.

If you're already using containers or planning to, switching to the new native Functions hosting in Container Apps is the best way to get the full benefits.

Read the official announcement from Microsoft: Azure Functions – Build 2025

In this post, we'll break down:

How Azure RBAC works

How to use it to secure your resources

When to create custom roles for fine-grained control

What is Azure RBAC?

Azure RBAC allows you to control who can do what at which scope. Instead of assigning individual permissions one by one to every user (which is messy and error-prone), RBAC lets you define what a "role" can do, and then assign that role to the right identity.

Think of it like this:

Who: The identity to which the role is assigned.

What: The role, which defines the set of permissions granted.

Where (scope): The level at which access applies.

RBAC Components Explained:

1. Security Principal (Who?)

This is the identity that receives the permission. It could be:

A user

A group (e.g., security group)

A service principal (from App Registration)

A managed identity (for apps hosted in Azure)

2. Role Definition (What?)

A role definition is a set of permissions. instead of assigning permission individually, we assign roles instead. Azure operates across two distinct layers of operations:

• Management Plane

This layer covers actions that manage and configure Azure resources, such as creating a virtual machine or assigning roles.

Access is governed by RBAC roles like:

Owner – Full control, including assigning roles

Contributor – Full control, except assigning roles

Reader – View-only access to resources

These are management plane roles, focused on administrative control.

• Data Plane

This governs access to the data within a resource, such as reading blob contents or accessing secrets.

Examples of data plane roles include:

Storage Blob Data Reader – Can read blob data in Azure Storage

Key Vault Reader – Can view secrets, keys, and certificates in Key Vault (read-only)

3. Scope (Where?)

The level at which the access applies:

Management group – top level for multiple subscriptions

Subscription

Resource group

Resource (most granular). example: an azure function app, etc

NB: You can inherit permissions downwards (e.g., from subscription to a resource group).

Demo

Let’s walk through how to assign a data-plane role to a user so they can read and upload blobs in an Azure Storage Account.

In this example, we’ll grant the Storage Blob Data Contributor role at the resource scope (i.e., directly on the storage account). This role provides the necessary permissions to read, write, and delete blobs.

• Navigate to the Storage Account
  Go to the Azure portal and open the storage account where you want to assign permissions.

• Access the IAM Settings
  In the left-hand menu, select Access Control (IAM).

• Go to Role Assignments
  Select the Role assignments tab.

• Add a New Role Assignment
  Click + Add > Add role assignment.

• Choose the Right Role
  Use the search box to find Storage Blob Data Contributor, select it, and click Next.

• Select the Identity Type
  Under Assign access to, choose User, group, or service principal.

• Pick the Member
  Click + Select members, search for the Entra ID user (e.g. user@domain.com), and select them.

• Complete the Assignment
  Click Review + assign, then confirm again to finalize the assignment.

  

This can also be applied to any Azure resource/resource group/subscription/management group and you will be able to select roles related to that scope.

You can find a list of built-in roles here: Azure built-in roles

When should you consider custom roles?

Sometimes, the built-in roles may not be enough as your requirement grow or change, this is where custom role definitions come in.

You should consider creating custom roles when :

You need least privilege access not covered by built-ins

You want to allow specific actions (e.g., read-only + deploy, but no delete)

You need scoped control across multiple subscriptions or resource groups

In a future blog, we will take a look at how to define custom roles and then assign them to identities.

That’s all for today, see you in the next one.

In app-based authentication, what we typically need is a Service Principal in Entra ID: a security identity that represents an app.

When you use Managed Identity, Azure automatically creates and manages that Service Principal on your behalf.

This removes the need to manage:

Client secrets

Certificates

Identity lifecycle manually.

It's a clean solution, if you’re running in Azure.

How to setup one: Understanding Managed Identities

However, Managed Identity cannot be used when:

Your app is not hosted in Azure

You need to call third-party APIs that don’t support Entra ID tokens, or perform OAuth2/OpenID Connect flows

You require custom claims in tokens, or want to support user consent scenarios.

This is where app registration comes in.

I wrote about app registration, here's the link: Setup Azure App Registration

That’s all for today, see you in the next one.

One outdated runtime, and suddenly you're dealing with broken flows, unsupported features or worse, security issues.

Microsoft sends the following alerts, well, ahead of this expiry time:

• Azure Portal notifications

• Emails to subscription owners

• Warnings in client tools and Azure Portal UI when an app is running on a version that is either retired, or about to be retired in the next 6 months

• Official Azure Functions Supported Languages document

This might not be proactive enough in your setups spanning multiple subscriptions.

This is where these CLI scripts might help to:

✅ Scan across subscriptions

✅ Identify apps on outdated runtimes/language versions

✅ Stay compliant and secure with minimal effort

• List all Windows-based Function Apps:

az functionapp list --query '[?contains(kind, `functionapp`) && !contains(kind, `linux`)].{Name:name, ResourceGroup:resourceGroup, OS:`Windows`}' --output table

• List Windows-based Function Apps with their language stack versions:

az functionapp list --query "[? !contains(kind, 'linux')].{name:name, resourceGroup:resourceGroup}" -o json | ConvertFrom-Json | ForEach-Object {
  $appSettings = az functionapp config appsettings list `

        -n $_.name -g $_.resourceGroup `

        --query "[?name=='FUNCTIONS_WORKER_RUNTIME' || name=='WEBSITE_NODE_DEFAULT_VERSION']" -o json | ConvertFrom-Json

    $siteConfig = az functionapp config show `

        -n $_.name -g $_.resourceGroup `

        --query "{powerShellVersion: powerShellVersion, netFrameworkVersion: netFrameworkVersion, javaVersion: javaVersion}" -o json | ConvertFrom-Json

    $runtime = ($appSettings | Where-Object { $_.name -eq 'FUNCTIONS_WORKER_RUNTIME' }).value

    $version = switch ($runtime) {

        'node'      { ($appSettings | Where-Object { $_.name -eq 'WEBSITE_NODE_DEFAULT_VERSION' }).value }

        'powershell'{ $siteConfig.powerShellVersion }

        'dotnet'    { $siteConfig.netFrameworkVersion }

        'java'      { $siteConfig.javaVersion }

        default     { 'Unknown' }

    }

    [PSCustomObject]@{

        Name          = $_.name

        ResourceGroup = $_.resourceGroup

        OS            = 'Windows'

        Runtime       = $runtime

        Version       = $version

    }

} | Format-Table -AutoSize

• List Windows-based Function Apps running on unsupported language runtimes: (as of April 2025):

az functionapp list --query "[? !contains(kind, 'linux')].{name: name, resourceGroup: resourceGroup}" -o json | ConvertFrom-Json | ForEach-Object {

    $appSettings = az functionapp config appsettings list -n $_.name -g $_.resourceGroup `
        --query "[?name=='FUNCTIONS_WORKER_RUNTIME' || name=='WEBSITE_NODE_DEFAULT_VERSION']" -o json | ConvertFrom-Json

    $siteConfig = az functionapp config show -n $_.name -g $_.resourceGroup `
        --query "{powerShellVersion: powerShellVersion, netFrameworkVersion: netFrameworkVersion}" -o json | ConvertFrom-Json

    $runtime = ($appSettings | Where-Object { $_.name -eq 'FUNCTIONS_WORKER_RUNTIME' }).value

    $version = switch ($runtime) {
        'node' {
            $nodeVer = ($appSettings | Where-Object { $_.name -eq 'WEBSITE_NODE_DEFAULT_VERSION' }).value
            if ([string]::IsNullOrEmpty($nodeVer)) { 'Unknown' } else { $nodeVer }
        }
        'powershell' { $siteConfig.powerShellVersion }
        'dotnet'     { $siteConfig.netFrameworkVersion }
        default      { 'Unknown' }
    }

    $isUnsupported = switch ($runtime) {
        'node' {
            $ver = $version -replace '~', ''
            [double]$ver -le 16
        }
        'powershell' {
            $ver = $version -replace '~', ''
            [double]$ver -le 7.2
        }
        'dotnet' {
            $ver = $siteConfig.netFrameworkVersion
            $ver -notlike 'v7*' -and $ver -notlike 'v8*'
        }
        default { $false }
    }

    if ($isUnsupported) {
        [PSCustomObject]@{
            Name          = $_.name
            ResourceGroup = $_.resourceGroup
            OS            = 'Windows'
            Runtime       = $runtime
            Version       = $version
        }
    }

} | Format-Table -AutoSize

If result empty, this means: all your Windows-based Azure Function Apps are running supported versions of: Node.js, PowerShell or .NET.

• List Windows Function Apps running on a specific language version (Example: Node.js 18):

  az functionapp list --query "[?!contains(kind, 'linux')].{name: name, resourceGroup: resourceGroup}" -o json |
  ConvertFrom-Json | ForEach-Object {
  
      $appSettings = az functionapp config appsettings list `
          -n $_.name `
          -g $_.resourceGroup `
          --query "[?name=='FUNCTIONS_WORKER_RUNTIME' || name=='WEBSITE_NODE_DEFAULT_VERSION']" `
          -o json | ConvertFrom-Json
  
      $runtime = ($appSettings | Where-Object { $_.name -eq 'FUNCTIONS_WORKER_RUNTIME' }).value
      $nodeVersion = ($appSettings | Where-Object { $_.name -eq 'WEBSITE_NODE_DEFAULT_VERSION' }).value
  
      if ($runtime -eq 'node' -and $nodeVersion -eq '~18') {
          [PSCustomObject]@{
              Name           = $_.name
              ResourceGroup  = $_.resourceGroup
              OS             = 'Windows'
              Runtime        = $runtime
              Version        = $nodeVersion
          }
      }
  
  } | Format-Table -AutoSize
  

• List Windows Function Apps running on Node.js runtime:

az functionapp list `
  --query "[?!contains(kind, 'linux')].{name: name, resourceGroup: resourceGroup}" `
  -o json | ConvertFrom-Json | ForEach-Object {

    $appSettings = az functionapp config appsettings list `
      -n $_.name `
      -g $_.resourceGroup `
      --query "[?name=='FUNCTIONS_WORKER_RUNTIME' || name=='WEBSITE_NODE_DEFAULT_VERSION']" `
      -o json | ConvertFrom-Json

    $runtime = ($appSettings | Where-Object { $_.name -eq 'FUNCTIONS_WORKER_RUNTIME' }).value

    if ($runtime -eq 'node') {
        $version = ($appSettings | Where-Object { $_.name -eq 'WEBSITE_NODE_DEFAULT_VERSION' }).value

        [PSCustomObject]@{
            Name          = $_.name
            ResourceGroup = $_.resourceGroup
            OS            = 'Windows'
            Runtime       = $runtime
            Version       = $version
        }
    }
} | Format-Table -AutoSize

• List Linux* Function Apps with their language stack versions.

az functionapp list \
  --query "[?siteConfig.linuxFxVersion!=null && siteConfig.linuxFxVersion!=''].{
    Name: name,
    ResourceGroup: resourceGroup,
    OS: 'Linux',
    LinuxFxVersion: siteConfig.linuxFxVersion
  }" \
  --output table

• Linux* Function Apps on a specific language stack version (Ex: Node.js 18):

az functionapp list \
  --query "[?siteConfig.linuxFxVersion=='Node|18'].{
    Name: name,
    ResourceGroup: resourceGroup,
    OS: 'Linux',
    LinuxFxVersion: siteConfig.linuxFxVersion
  }" \
  --output table

*Running on Elastic Premium and App Service Plans

With just a few Azure CLI commands and PowerShell scripts, you can quickly identify outdated runtimes, prioritize upgrades, and stay ahead of upcoming retirements.

That’s all for today, see you in the next one.

A simple ASP.NET Core Web App built with .NET 8.0 that allows users to:

• 📂 Upload PDF documents

• 🧠 Index the content using Azure AI Document Intelligence

• 🔍 Perform full-text searches across uploaded documents using Azure Cognitive Search

🚀 Features

• Clean web interface for uploading and managing PDFs

• Automatic extraction of text using OCR

• Indexed and searchable content via Azure

• Full-text query support for retrieving relevant documents

🛠️ Tech Stack

• ASP.NET Core (.NET 8.0)

• Azure AI Document Intelligence

• Azure Cognitive Search

• Razor Pages / MVC

📦 Getting Started

1. Clone the repository:

2. Configure Azure services (Document Intelligence & Cognitive Search) in Azure Portal: https://blog.habeebyakubu.com/p/tutorial-converting-pdfs-into-searchable

3. Add your keys and endpoint URLs in appsettings.json

4. Run the app:

dotnet run

💡 Ideas for Enhancement

• Add authentication (e.g. Azure AD, Identity)

• Filter or categorize search results

• UI improvements (responsive layout, loading indicators, etc.)

• Logging and error handling

🛠 GitHub repo here: dotnetyatch/PdfSearchApp

Happy to get feedback or contributions from the community!

That’s all for today, see you in the next one.

Imagine as a business, you have thousands of reports, contracts, or research papers—how do you quickly find the information you need?

Azure AI changes that by enabling intelligent document processing and searchable knowledge bases.

By leveraging Azure AI, we can extract text from PDFs, index them, and make them fully searchable—just like searching for keywords in a database.

Here is the final solution:

Step by steps:

Scenario: We have a set of PDF invoices and reports. Let’s make them searchable and queryable using Azure AI!

Architecture of our solution:

How It Works

✅ PDFs are uploaded to Azure Blob Storage

✅ Azure Form Recognizer extracts text from PDFs

✅ Extracted text is indexed in Azure Cognitive Search

✅ Users can search and retrieve information instantly

What Azure Services do we need?

✅ Azure Blob Storage (for pdf storage)
✅ Azure Form Recognizer (for text extraction)
✅ Azure Cognitive Search (for indexing & querying)
✅ Azure Functions / Logic Apps/Web App (for automation)

1️⃣ Create an Azure Storage Account (For PDF Storage)

Azure Blob Storage will serve as the storage location for PDFs.

🔹 Steps:

1. Go to the Azure Portal → Search for Storage Accounts

2. Click Create → Choose a Subscription & Resource Group

3. Set a Storage Account Name

4. Select Standard/Hot tier

5. Click Review + Create → Deploy

🔹 Create a Blob Container:

1. Open the Storage Account

2. Go to Containers → Click + Container

3. Name it "pdf-docs" → Set Public Access Level to Private

4. Click Create

Once stored, PDFs need to be processed and extracted. Azure Form Recognizer uses AI to pull structured and unstructured text.

2️⃣ Set Up Azure Form Recognizer (For Text Extraction)

Azure Form Recognizer extracts structured and unstructured text from PDFs.

🔹 Steps:

1. Go to the Azure Portal → Search for Form Recognizer

2. Click Create → Choose a Subscription & Resource Group

3. Set a Resource Name

4. Choose a Pricing Tier → F0 (Free) for testing

5. Click Review + Create → Deploy

   

   Now that we have extracted data, we need fast search capabilities. That’s where Azure Cognitive Search comes in.

   3️⃣ Configure Azure Cognitive Search (For Indexing & Querying)

   Azure Cognitive Search enables full-text search capabilities.

   🔹 Steps:

   1. Go to the Azure Portal → Search for Cognitive Search

   2. Click Create → Choose a Subscription & Resource Group

   3. Set a Service Name (e.g., pdfsearchservice)

   4. Select Pricing Tier → Choose Basic or higher for production

   5. Click Review + Create → Deploy

      

   🔹 Create an Index:

   1. Open the Cognitive Search Service

   2. Go to Indexes → Click + Add Index

   3. Define Fields (e.g., id, content, title)

   4. Click Create

      

   What’s Next?

   With the search index ready, users need a way to query documents. A simple web app or API endpoint can expose search functionality.

   A possible automation flow could be using a Logic App:

   1️⃣ Trigger: Detect when a new PDF is uploaded to Azure Blob Storage.

   2️⃣ Extract Text: Call Azure Form Recognizer to analyze and extract text from the PDF.

   3️⃣ Store Extracted Data: Save the extracted text as a JSON/TXT file in another Blob Storage container.

   4️⃣ Index the Text: Push the extracted text into Azure Cognitive Search for indexing.

   Using a web app with a user interface like you saw in the first section is also another option.

   The next step is to write the code to automate everything!

   ➡ In the next post, I’ll walk through the implementation step-by-step. Stay tuned!

   Thanks for reading Azure For Developers Newsletter! Subscribe for free to receive new posts and support my work.

Thankfully, Logic Apps provides Secure Inputs and Secure Outputs options to help mask sensitive data in the run history.

Why does this matter?

By default, Logic App run history stores input and output details for every action. While this is useful for debugging while we are in dev, it can expose sensitive data like passwords, API keys, or secrets.

Imagine a Logic App that processes user payment details. It retrieves sensitive information like credit card numbers, expiration dates, or transaction tokens to complete a payment. Now, what if someone could open the workflow history and see every single one of those details?

With Secure Inputs, you can mask the input payload containing credit card information. With Secure Outputs, you can ensure the response, such as transaction IDs or tokens, remains hidden from the logs.

Enabling Secure Inputs and Secure Outputs ensures this sensitive data remains hidden, even in run logs.

Some considerations to know when using this feature:

• The secured data isn’t sent to Azure Log Analytics or included in the workflow history API responses.

• Tracked properties can’t be added to the secured trigger or action.

• To secure outputs from an action that obscures inputs or explicitly obscures outputs, manually turn on Secure Outputs in that action.

• Ensure Secure Inputs or Secure Outputs is enabled for downstream actions if you want to obscure sensitive data in the run history.

How to Enable Secure Inputs and Outputs from the Designer

1. Open your Logic App in the Azure portal.

2. Navigate to the specific action or trigger you want to secure.

3. Expand the Settings section of the action.

4. Toggle Secure Inputs and Secure Outputs to "On."

5. Click Done to save your settings.

When you run the workflow or when triggered, this is what you get in the Run History:

You can also do this in the code view:

Securing Inputs and Outputs offers additional benefits, particularly in ensuring compliance:

• Minimizes the risk of exposing confidential information during audits or troubleshooting.

• Supports adherence to data protection regulations such as GDPR and HIPAA.

By implementing this practice, you make your Logic App solutions both robust and secure!

That’s all for today. See you in the next one.

Let’s build a system for that using Azure Event Grid and WebHooks!

Here's how it will work:

✅ An e-commerce system generates an event "Order Shipped"

✅ This event is published to Azure Event Grid.

✅ Event Grid routes the event to web-hook subscribers in real time..

✅ Notification could be Email, SMS, or in-app Notifications.

In this tutorial, we’ll use Logic App to represent the business system that generates an order shipped event.

The webhook is an Azure Function which is going to receive the notification from Event Grid and dispatch the notifications appropriately to the right quarters (via email, sms or in-app)

What is Azure Event Grid?

Event Grid is an Azure service for building event-driven applications. It has a push delivery mechanism to send events to destinations like webhooks or Azure services. You can configure it to deliver events to a wide range of endpoints and automate workflows by receiving events from over 20 Azure services.

The pull delivery mode allows clients to connect to Event Grid to read events.

Event Grid supports two types of messaging: MTTQ (Message Throughput Queues) and Event Messaging (HTTP), enabling flexibility in how events are processed.

In this use case, we are using a push method. Event Grid pushes events to the subscribed webhook endpoints whenever an event occurs. This eliminates the need for the consumer to constantly poll for updates, making the system more efficient and responsive. Let’s get started:

Step 1: Set Up Event Grid Topic

Events published to Event Grid land on a topic, which is a resource that logically contains all events. We will create a system topic which typically represents one or more events published by Azure services.

• In Azure Portal, search for "Event Grid Topics" and create a new topic.

• Note the Topic Endpoint and Key for authentication. (found in Settings/Access Keys)

  

Step 2: Set Up Event Source

• Go to the Azure Portal, create a Logic App.

• Add a Recurrence Trigger to simulate order updates (e.g., every minute).

• Use an HTTP Action to send an event payload (JSON) to Event Grid.

• - Add a header for authentication:

  “aeg-sas-key: <your_topic_key>”

  

Step 3: Deploy a sample Web-hook endpoint

The webhook can be any http based service.

For instance, in the case of in-app notifications: The webhook will likely be a service which communicates with platforms like Firebase Cloud Messaging (FCM) or Apple Push Notification Service (APNs) to send real-time notifications to users’ devices.

In this demo, we will simulate this using an Azure Function that receives the event notification. If you like, you can take advantage of the native Event Grid trigger for Azure functions but here we make use of http trigger so as to simulate a typical external http service.

• Create an Azure Function (http trigger)

• Write appropriate code to handle the notification received.

Notice that the Azure Function contains extra code before handling the actual request. This is because of Event Grid web-hook validation.

Here is how the validation works:

The web-hook must listen for the Validation Event:

Event Grid will send a POST request with the SubscriptionValidationEvent to the webhook's endpoint.

The payload will include a validationCode inside the data property.

The webhook must reply with an HTTP 200 OK response.

The response body must include a JSON object with the validationResponse key containing the received validationCode.

Here is a Microsoft doc explaining this in details: Troubleshoot Azure Event Grid subscription validations

Step 4: Subscribe the WebHook to the Event Grid Topic

• In the Azure Portal, navigate to your Event Grid Topic.

• Add a new Event Subscription

• Set the Endpoint Type to "WebHook".

• Provide the WebHook URL (in this case, it is the Azure Function URL).

  

  

  Subscription created:

  

  Test:

• Trigger events using the Logic App.

  

• Verify the web-hook endpoint logs to confirm the event was received.

  

• Finally. Check that it Event Grid publishes this message to the web-hook URL (Azure function). We can easily confirm this from the Function App’s log stream:

  

In this post, we've demonstrated how to build an efficient, event-driven notification system using Azure Event Grid and Webhooks. We've also covered important considerations like webhook validation. By using Event Grid's push delivery, we can integrate Azure Functions and third-party services to automate real-time notifications, improving application responsiveness and ensuring instant delivery of critical updates.

That’s all for today, see you in the next one.

If you have a custom app hosted in App service that is currently being accessed via Managed Identities. How do you accept authenticated requests from the external world (outside Azure)?

Since Entra ID (formerly Azure AD) remains the core identity service used by Microsoft, you can configure Azure AD authentication to enable external authentication while keeping your internal security measures intact.

Here is how Managed Identities work:

1. When you assign a Managed Identity to an Azure resource (e.g., Virtual Machine, App Service), Azure creates a service principal in Entra ID for that resource. This service principal represents the managed identity in Entra ID and is used to authenticate the resource.

2. The source resource (with its managed identity) communicates with Entra ID to request an OAuth 2.0 token. The request specifies the target resource's identifier (resource URI), like Key Vault or Storage Account.

3. Entra ID then validates the managed identity’s request. If the managed identity is authorized for the target resource (via role assignments or access policies), Entra ID issues an access token.

   Fun fact: The image was generated by AI based on my prompt.

   How to make your custom app support Microsoft Entra ID?

   Ideally this app will be hosted in Azure App Service:

   1. Go to the Azure Portal and register your app in Azure Active Directory (Entra ID). Note the Application (Client) ID and Tenant ID.

   2. Configure Redirect URI

   3. Set the redirect URI for handling authentication responses (e.g., https://yourapp.com/signin).

   4. Add API Permissions. Specify the required Microsoft Graph or other API permissions. Grant Admin Consent if necessary.

   Next step is to:

   Enable Azure AD Authentication for Your App Service

   Now that your app is registered, you can configure your App Service to require Azure AD authentication for external clients.

   1. Navigate to your App Service:

      • In the Azure portal, go to App Services, then select your app.

   2. Enable Authentication / Authorization:

      • In the Authentication / Authorization section of your App Service, turn Authentication to On.

      • Select Azure Active Directory as the authentication provider.

   3. Configure Azure AD Authentication:

      • When you select Azure Active Directory, you’ll need to link your app to your Azure AD tenant and set up authentication details.

        • Choose Express (if you want default settings) or Advanced (if you want more granular control).

        • Select Azure Active Directory and either:

          • Use existing AD app: Use the app registration that you created earlier.

   Connecting to the custom app:

   Using managed identity: Using Managed Identities

   From the external world: External clients (users or apps outside Azure) will use OAuth2 authentication to obtain a Bearer token (JWT token) from Azure AD from code.

   The external client must include this Bearer token in the Authorization header when making requests to your app.

   That’s all for today.

They make authentication & authorization seamless between any two resources that support Microsoft Entra ID (Azure AD). The authorization side is enforced by the target resource based on the roles that you assign to the managed identity.

For instance, If you are working with Azure Logic Apps that needs to read from a blob storage. You don't need to use the storage account keys to authenticate. You can easily:

✅ Create a managed identity for the Azure Logic App

✅ Assign roles/permissions that are required to perform action on the Blob storage.

✅ Specify the managed identity as the authentication method in your Logic App.

Microsoft handles the rest. Same process applies for Azure Functions, you just need to use the managed identity in the code to authenticate against any resource. The Azure.Identity package provides everything required to implement this.

In this post, we will demonstrate Managed identities using Logic Apps.

There are two types of managed identity that can be created:

System-Assigned Managed Identity:

Automatically created and tied to an Azure resource (e.g., Azure function, Logic App).

Deleted when the resource is deleted.

User-Assigned Managed Identity:

Created independently and can be assigned to multiple resources.

Exists even if any of the resources it's attached to is deleted.

The choice between System-Assigned and User-Assigned Managed Identity depends on your use case, resource lifecycle, and sharing requirements. This table should help:

Let’s dive into a walkthrough to configure a Managed Identity for a Logic App to read files from Azure Blob Storage.

Step 1: Enable Managed Identity for the Logic App

1. Open the Azure Portal and navigate to the Logic App

2. In the left-hand menu, select Identity under the Settings section.

3. Toggle the System-assigned Managed Identity option to On

4. Click Save

Step 2: Grant Blob Storage Access to the Managed Identity

To allow the Logic App to read files from Blob Storage, we must assign the appropriate role to its Managed Identity.

We can do this by clicking on the “Azure role assignments” button as well but to explain clearly we will add the permissions from the target resource itself.

1. Navigate to the Blob Storage account in the Azure Portal.

2. Select Access Control (IAM) from the left-hand menu.

3. Click Add role assignment

4. Choose the following settings:

- Role: Storage Blob Data Reader

- Assign access to: Managed Identity

- Select members: Choose the Managed Identity that we created in the previous step.

5. Click Review & Assign

Step 3: Configure the Logic App to Use Managed Identity

Now, update the Logic App to use the Managed Identity for authentication.

1. Open the Logic App Designer and add the action that interacts with Blob Storage (in this case "Get Blob Content").

2. In the connection settings:

- Set Authentication Type to Logic Apps Managed Identity.

- Set Connection Name to any desired name.

3. Save the Logic App.

Configuring the Get blob content action. I just needed to provide the storage account name. I was able to navigate to the blob I wanted to read from.

If you are unable to browse the storage account, ensure that you yourself also have the role: Storage Blob Data Reader

Step 4: Test

We need to test to ensure it can access the Blob Storage account without errors.

In my case, I had uploaded a text file in the blob container.

Since I am using a recurrence trigger, I just waited for 1 minute to see that my workflow was triggered.

The content of the text file was displayed in the output body of the “Get blob content” action as shown below:

If the Logic App fails, ensure:

- The correct role (Storage Blob Data Reader) is assigned.

By enabling Managed Identity and configuring the appropriate role assignments, you can avoid the hassles and risks of keeping secrets or keys and focus on building robust business workflows & logic.

That’s all for today and see you in the next one!

If yes, you are safe! Otherwise, see just a glimpse of what you are missing below:

- Custom dependencies: Developers have full control over the dependencies and configurations of the function app. You can use many thing that you already use to make a good maintainable codebase in .NET. Dependency injection, Logging, Middleware etc. Cool, yeah?

- Improved Diagnostics: The isolated worker model offers enhanced diagnostics and better observability into function execution. Local debugging is easier, and more flexibility in how & what is logged in App insights.

- Future-Proof: The isolated worker model is part of Azure’s long-term strategy, supporting the latest .NET versions and future features, while Microsoft is gradually phasing out the default runtime model, making adoption essential for staying current. Support will end for the in-process model on November 10, 2026. This sounds good for the business.

But wait, we need some understanding. What exactly are these models?

There is nothing too technical here! Basically, Azure functions can execute/run in two modes or models.

For Azure functions to run, they rely on the Azure Function Host. (The Microsoft background managed service that handles things like orchestrating function invocations, managing resources, and monitoring and logging of function executions.)

The two modes:

- In-Process: The default or classic one which probably you are using. This means both your code & Azure Function Host share the same resources and are served from the same source. Meaning they are tightly coupled and would need to be in sync in many ways.

- Isolated Worker: Function code runs in its own separate .NET worker process separate from the one that the Host uses. You have full control over the .NET runtime and environment for your function because it's not being shared with the Host.

The isolated worker model for Azure Functions is available starting from .NET 5 and later versions, including .NET 6 and .NET 7. It is not available in the older .NET Framework (e.g., .NET Framework 4.x).

What is different in the development experience? I would say quite a lot. As somethings would need to be expressly setup and configured.

Creating a project it is easy from visual studios, we just need to select the functions worker:

Here is how the function class looks like:

Then you also have a program.cs file, this is where you configure your startup processes, register services if using DI, etc:

There are also a few new things in the .csproj files. You still have the regular host.json file that defines configuration shared by functions in your project and local.settings.json

For more details on building this: Microsoft Isolated Process Guide

For guide on migrating from in-process to isolated: Microsoft Migrate to Isolated

I encourage you to migrate and also choose the isolated worker model for new projects going forward.

Leave me a comment if you have got questions.

That's all for today. See you in the next one.

Azure continues to offer the possibilities to harness AI’s potential.

Now, lets take a look at some interesting developer related updates from #MicrosoftIgnite, codes & practical examples will come later:

Azure Container Apps introduced Serverless GPUs (currently in preview).

This feature allows developers to run AI workloads on serverless GPUs in Azure Container Apps. They automatically scale to handle your workload and only charge based on actual usage. This also allows devs to use NVIDIA A100 and T4 GPUs without complex infrastructure. Every AI developer will be happy with this. While traditional cloud services still involve provisioning fixed GPU instances (even though managed by the cloud), serverless GPUs provide on-demand GPU power without the need to manually configure or manage GPU environments.

Azure AI Foundry:

The whole idea here is to streamline AI adoption for businesses, reduce development costs, and support the scaling of AI solutions across industries, making it easier for developers and organizations to innovate responsibly and effectively. If you have ever used the Azure AI studio, this portal replaces it and offers management of AI apps, models, and services. Azure AI Agent Service is one of the capabilities of Azure AI Foundry for developers to create, deploy and scale intelligent AI agents that can automate complex business processes. I will use the SDK to build an agent in the coming days.

Azure Logic Apps on Azure DevOps:

Azure Logic Apps have supported integration with Azure DevOps for deployment automation for a while. However, Microsoft Ignite 2024 introduced enhancements that improve the DevOps experience. Two Updates: Dedicated Azure DevOps pipeline tasks for "Azure Logic Apps Standard Build" and "Azure Logic Apps Standard Release" were introduced. Zero Downtime Deployment: Deployment slots, now available in preview, allow updates without affecting running workflows.

AI workload now included in Azure Well-Architected Framework:

AI workload guidance has also been added to the popular Azure Well-Architected Framework that we all know. This ensures they align with the framework's pillars: Reliability, Cost Optimization, Security, Operational Excellence, and Performance Efficiency.

Very Important: Security Enhancements:

Microsoft Purview Updates: There are tools for data governance and protection, including malicious intent detection and prevention of risky AI usage​.

That’s all for today. See you in the next one!